Continuous integration and Wordpress development

Justin Obara obara.justin at
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.


On July 12, 2017 at 10:48:07 AM, Hung, Jonathan (jhung at 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?


- Jon.

Jonathan Hung, Inclusive Designer
Email: jhung at
OCAD University
Inclusive Design Research Centre

*From:* Colin Clark <colinbdclark at>
*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.


On Jul 10, 2017, at 4:12 PM, Hung, Jonathan <jhung at> 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

   - Floe UI Options Wordpress Plugin
   - Floe wp-a11y theme
   <>(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
   - 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 <>*

Another approach is to register both the UIO Plugin and the wp-a11y theme
with <> 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
OCAD University
Inclusive Design Research Centre

fluid-work mailing list - fluid-work at
To unsubscribe, change settings or access archives,

fluid-work mailing list - fluid-work at
To unsubscribe, change settings or access archives,
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <>

More information about the fluid-work mailing list