Continuous integration and Wordpress development

Justin Obara obara.justin at gmail.com
Wed Jul 12 15:07:32 UTC 2017


Hi Jon,

I’m not sure I know enough about Wordrpress to accurately way in, but I
think you’d still want to use GitHub for the sites we maintain. I think
it’s just easier to keep track of what is there and for
deploying/redeploying. I’m not sure that we have to go through the same
procedure of pr and code review, that can probably be determined on a site
by site basis.

Hope that helps.

Thanks
Justin


On July 12, 2017 at 10:48:07 AM, Hung, Jonathan (jhung at ocadu.ca) wrote:

I was thinking about this workflow a little more and have a question:


Would we require child theme development be done through github and follow
our community procedures for submitting pull requests, code review, etc?


I have concerns as not everyone who is asked to work on these Wordpress
sites are developers.


On one hand, doing everything through Github and following the community
procedure has many benefits, but it also creates a burden on the reviewer
and the author, and adds overhead to the website operation.


For example, I'm not entirely sure if a website like BIG IDeA will benefit
from the standard community process. Would it be reasonable for the
Wordpress admins (who may not be technical) to modify the child theme
directly through the WP built-in theme editor? This would also mean that
whenever changes are pushed to the parent theme, the admins will need to
ensure the child theme still functions properly. Is that ideal?


Thoughts?


- Jon.


---
Jonathan Hung, Inclusive Designer
Email: jhung at ocadu.ca
OCAD University
Inclusive Design Research Centre

------------------------------
*From:* Colin Clark <colinbdclark at gmail.com>
*Sent:* July 10, 2017 4:40:30 PM
*To:* Hung, Jonathan
*Cc:* Fluid Work
*Subject:* Re: Continuous integration and Wordpress development

Hi Jon,

Great explanation of the issues involved! It doesn't sound like the two
approaches are mutually exclusive, which is good.

For sites that we host within our community, I think it's very reasonable
to work with Gio and others to create a standard container that includes
our supported version of WordPress, the UIO plugin, our parent theme, and a
"blank" or "stub" child theme all set up for people to edit. Then it's
(hopefully) as simple as spinning up the container for a new site and
regenerating it when upgrades to the theme or plugin are required. As you
say, a simple tutorial for people who aren't WordPress or Git experts will
be crucial so that people understand where to put their changes and
enhancements so that they won't get replaced when upgrades occur.

When the theme gets to the point where it's ready for broad use by people
who aren't within our community or aren't quite WP-savvy, then we can
publish to the official theme repository.

Colin

On Jul 10, 2017, at 4:12 PM, Hung, Jonathan <jhung at ocadu.ca> wrote:

Hi everyone,

We've been designing, developing, and deploying more and more Wordpress
sites for various IDRC projects. Many of these sites are using two common
components:


   - Floe UI Options Wordpress Plugin
   <https://github.com/fluid-project/uio-wordpress-plugin>
   - Floe wp-a11y theme
   <https://github.com/jhung/wp-a11y-theme/tree/foundation>(in development)


Since many of these production sites are using their own customizations on
the wp-a11y theme, there needs to be a good way to propagate changes to the
wp-a11y theme to these sites without affecting the customizations.

*Approach 1: Core features + Continuous Integration*

A possible approach to this would be to create a standard WP configuration
with the following features:


   - UIO Plugin + Continuous Integration configured to get changes from
   github
   - wp-a11y theme configured to get changes from github
   - a wp-a11y child theme stub for the customizations
   - documentation explaining how child theme development would work


This would give us the ability to push changes to the UIO Plugin and the
wp-a11y theme without clobbering any changes (assuming the site authors did
not directly edit the theme files).

*Approach 2: Register with Wordpress.org <http://wordpress.org/>*

Another approach is to register both the UIO Plugin and the wp-a11y theme
with Wordpress.org <http://wordpress.org/> and have changes pushed out
using the WP update process. Ultimately I think this would be ideal for end
users outside of the IDRC, but the wp-a11y theme has a way to go before
it's ready.


Does anyone have any thoughts on how we might do this? Does Approach #1
seem reasonable?

- Jon.


---
Jonathan Hung, Inclusive Designer
Email: jhung at ocadu.ca
OCAD University
Inclusive Design Research Centre

_______________________________________________________
fluid-work mailing list - fluid-work at lists.idrc.ocad.ca
To unsubscribe, change settings or access archives,
see http://lists.idrc.ocad.ca/mailman/listinfo/fluid-work


_______________________________________________________
fluid-work mailing list - fluid-work at lists.idrc.ocad.ca
To unsubscribe, change settings or access archives,
see http://lists.idrc.ocad.ca/mailman/listinfo/fluid-work
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.idrc.ocad.ca/pipermail/fluid-work/attachments/20170712/761775c3/attachment.html>


More information about the fluid-work mailing list