Continuous integration and Wordpress development

Hung, Jonathan jhung at ocadu.ca
Thu Jul 13 19:27:56 UTC 2017


Hi everyone,


In addition to this email thread, there was a discussion in the #fluid-work IRC channel about this topic of theme modification and process. You can find that discussion archived here: https://botbot.me/freenode/fluid-work/2017-07-12/?msg=88477611&page=1


The core issue is that even if we have infrastructure with good continuous integration, it will always be a problem whenever someone chooses to edit Wordpress theme files directly through the WP dashboard. Disabling the Theme editor isn't really an option as there may be some valid reasons to use it.


It seems that the best we can do at this point is:

  1.  Document the ideal / best process of customizing child themes (i.e. use github, and continuous integration)
  2.  Document the less ideal situation of editing the child theme through the dashboard and the consequences of such actions.

For now this will have to be enough until we come across a better solution.

Please let me know if you have any other thoughts or comments.

- Jon.


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


________________________________
From: Justin Obara <obara.justin at gmail.com>
Sent: July 12, 2017 11:07:32 AM
To: Colin Clark; Hung, Jonathan
Cc: Fluid Work
Subject: Re: Continuous integration and Wordpress development

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<mailto: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<mailto:jhung at ocadu.ca>
OCAD University
Inclusive Design Research Centre

________________________________
From: Colin Clark <colinbdclark at gmail.com<mailto: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

_______________________________________________________
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/20170713/1a838877/attachment.html>


More information about the fluid-work mailing list