Continuous integration and Wordpress development
colinbdclark at gmail.com
Mon Jul 10 20:40:30 UTC 2017
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 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 <mailto:jhung at ocadu.ca>
> OCAD University
> Inclusive Design Research Centre
> fluid-work mailing list - fluid-work at lists.idrc.ocad.ca <mailto:fluid-work at lists.idrc.ocad.ca>
> To unsubscribe, change settings or access archives,
> see http://lists.idrc.ocad.ca/mailman/listinfo/fluid-work <http://lists.idrc.ocad.ca/mailman/listinfo/fluid-work>
-------------- next part --------------
An HTML attachment was scrubbed...
More information about the fluid-work