Wordpress Sites Plan for Early 2018

Current state

Original on Google Drawings

Rough Roadmap

1. Create a Wordpress child theme template - ideally, we would create a base theme repository that represents the "starting point" for any new IDRC Wordpress site:
   • this would involve some work paring back the big-idea-theme snow-theme to remove its  branding, etc.
     • e.g. remove background images
     • replace BI branding with placeholder images such as masthead, logo, etc. (which are designed to prompt users of the theme to replace them with their own?)
     • need to refactor the big idea stuff from the parent theme
     • anything common across big idea and snow should stay
     • anything not common should be moved into either the big idea or the snow theme
       • Example: https://github.com/jhung/wp-a11y-theme/tree/foundation/images
       • also some PHP code, but Jon will need to crawl the code and find it
   • gut feel estimate is probably about 3 weeks to do so
2. Code repositories
   • a lot of these themes are in personal github spaces, and should be moved to the inclusive-design (or maybe fluid-project) org
     • wp-a11y-theme (lives in jhung right now?) -> move to fluid-project org IDI
     • big-idea-theme (lives in jhung) -> move to inclusive-design org
     • snow-theme (lives in grrrerro) -> move to inclusive-design org
     • big idea feedback plugin (lives in jhung) -> needs to be generalized before it can be used in other sites, then migrated to inclusive-design
     • UIO wordpress plugin lives in fluid-project already (yay!)
       • might need some updates to work with the very latest UIO, but it's relatively up to date
       • should come up with a simple release process -> upgrading version numbers, tagging
       • we don't currently publish this plugin to the larger wordpress.org repository -> should consider if we want to do this, or if it should be more informal
     • there are some code quality issues with some of these repositories, but can we move them anyway?
       • Document issues and todos, file Jiras as needed
       • and then let's just move 'em!
       • question of governance: who gets to review, who's allowed to push directly?
         • for now, let's keep it super informal:
           • every change gets submitted as a PR
           • contributors ask for review whenever they can
           • submitters can push directly if needed
       • everything except the uio-plugin will move to the inclusive-design org
3. wp-a11y-theme improvements
   • we have A BRANCH—the Foundation branch
     • it should be merged into master and users should start to use it (LET'S DO IT!)

Next Steps

1. Jon will plan #1.
2. will be done soon->let's pick a free afternoon and just do it
3. we will form a team for the IDRC site
   • another design iteration emphasizing resources and learning about inclusive design
   • improving themes and workflows for our WP sites prior to starting full implementation
   • colin will talk to vera about lisa's availability
   • team of (hopefully) lisa, jon, eloisa to do the idrc site redesign-build

Websites

Project	Dev Site	Uses wp-a11y theme	UIO Plugin	Continuous Integration Status	Who	Notes
BIG IDeA	dev.bigidea.one			Pushes to wp-a11y theme automatically deploys to production site using CI-Travis. CI has now been disabled to prevent unintended overwriting of changes.  External users have made direct modifications to site theme. Next update to wp-a11y will overwrite these changes. The remote changes will need to be refactored and put into either a new branch or Big Idea repo. This way changes can be done to the wp-a11y theme and BI theme without any unintended overwriting. wp-a11y should be set up as a parent-child configuration and BIG IDeA theme changes on production site should be put into a child theme that is also version controlled.	Jon (theme and tools development, and infrastructure) Erica (theming) Lucian (badging design) Vera (project coordination) David (project coordination) Lisa (site design) Giovanni (infrastructure)
Our Doors are Open				No continuous integration. Theme was manually installed External users have made direct modifications to site theme. Updates to the wp-a11y theme will need to be applied manually to preserve existing customizations. wp-a11y should be set up as a parent-child configuration and Our Doors are Open theme changes on production site should be put into a child theme that is also version controlled.	Jon (theme and tools development, and infrastructure) Francisco (theming) Vera (project coordination) David (project coordination) Lisa (site design) Giovanni (infrastructure)
DEEP				No continuous integration or versioning.	Jess (admin and content) Vera (content) Jutta (content) Jon (admin) Giovanni (infrastructure)
Inclusive Design				Pushes to idi-theme automatically deploys to production site using CI-Travis. Unknown at this point if production theme has been modified by the theme editor.	Jon (admin and content) Jess (admin and content) Giovanni (infrastructure)
SNOW	snow-dev.idrc.ocadu.ca			Pushes to wp-a11y parent theme automatically deploys to production site using CI-Travis. Pushes to snow child theme automatically deploys to production site using CI-Travis	Julia (content and project coordination) Pat (admin and content) Jon (admin, theme and tools development) Lisa (site design) Giovanni (infrastructure)	This is the only site at the moment configured with the parent-child theme relationship.
IDRC				Rough mockups have been done. No dev work has started.	Lisa (site design)	Currently MediaWiki. New site will be WP

Wordpress Code Projects Maintained by IDRC

Ongoing Wordpress Project Issues

Areas to improve upon:

• Make it easier and safer to develop Wordpress sites (versioning and continuous integration)
• Make it easier to maintain and fix problems (versioning and continuous integration)
• Make it easier to collaborate and coordinate (project coordination)
• Resources:
  • Currently limited in-house resources for PHP / Wordpress projects
  • Developing in-house knowledge takes time - needs to be built into deliverable timelines and budgets (which hasn't been the case thus far, or hasn't been clear).

Versioning and Backups of User Modifications

Currently there is no tracking of changes done through the Wordpress theme editor. Lack of tracking causes many problems for maintenance

• Looking into gitium as a possible tool to track changes to plugins and themes.
  • gitium needs to be manually triggered after any changes - so not ideal for our use case as we would like something automatic.
  • gitium also requires proc_open to be enabled to function.
• incron can be used to monitor changes to Wordpress directories and a script can be run to generate git commits based on the changes.
  • git can be called from outside a repository directory by using git -C ./<repo_directory>/ add <filename>
  • incron requires inotify to function
  • todo: is it possible to create git commits where the author is the wordpress username?
• cron
  
  • cron can be used to periodically generate git commits.
  • todo: is it possible to create git commits where the author is the wordpress username?
• versionpress
  • currently in developer preview
• Revisr
  • Requires PHP exec()
• Github Sync
  • https://github.com/mAAdhaTTah/wordpress-github-sync

Continuous Integration

• Todo: Generalize the wp-a11y theme as a parent theme, and create child themes for individual sites.
  • Each production site will CI both wp-a11y theme and site's child theme (containing its customizations).

Project Coordination

• Currently there is no central way of coordinating and communicating WP project designs, documentation, bugs, etc.
  • Should we use a wiki? If so, where should this be?
  • Bugs and task tracking? Maybe use JIRA?
  • What about a communication channel. Currently mostly done via emails and Skype calls.
• How do we on-ramp non-IDRC collaborators on projects? How do we ensure their contributions are done the right way?
  • What is the "right way"? We need a strategy / resource for this kind of engagement on WP projects.
• There isn't a strict policy on Admin-level user access which has caused problems in the past.
• Also there currently isn't a clear process of defining scope, specs, or requesting features. This makes it difficult to estimate work and allocate resources.