Continuous integration and Wordpress development

Hung, Jonathan jhung at ocadu.ca
Wed Jul 12 14:47:29 UTC 2017


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<mailto: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

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.idrc.ocad.ca/pipermail/fluid-work/attachments/20170712/8bc44925/attachment.html>


More information about the fluid-work mailing list