...
The Development team is responsible for maintaining both the infrastructure, and the themes and plugins. The infrastructure is maintained and deployed via a CI/CD pipeline that is controlled by Kustomize (COMING SOON: and ArgoCD). This pipeline (will) automatically check for updates of WordPress and any used plugins, and update deployments on OpenShift.
OpenShift
The OpenShift space contains 4 3 instances of WordPress.
...
, but more can be deployed by following DevOps Operations guide.
digital-uat: Once a new feature is ready for testing, we can perform a back migration from production and combine it with new theme and plugin changes here to do some initial testing. This is a public site that may be unstable. Content work that is dependent on new features can be done here (only if necessary - to avoid synchronicity issues, production editing must be locked down while this is occurring, and we must do a forward-migration of content)
digital-stage: Used as a stable environment for a pre-production release. Should contain an exact or near-exact copy of production, with any changes that are ready to be migrated to production. Used as a final QA environment.test: Primary testing of plugins, themes and WordPress version upgrades as well as infrastructure updates is done here. In case content team needs to do a batch of major content development that cannot be done on production, use digital-test for this as well (if development work needs to happen in parallel during this time, developers should switch to digital-dev for that time).digital-prod: The live site. Theme and plugin specific development work should not occur here, and should be used for content development only.
...
digital-dev: This is an auxiliary instance of WordPress that can be used in case digital-test is occupied by the content team doing content development off-production (production should be not available for editing at that time).
Custom Plugins
Custom plugins have been developed in the wordpress-digimod repository. To read more about deploying custom plugins, refer to DevOps Operations and digital.gov.bc.ca WordPress Maintenance Guide pages.
digimod-disable-updates (DIGIMOD - Disable Automatic Updates)
This plugin disables automatic updates done by WordPress. This is done to prevent rollbacks associated with divergence between OpenShift image and the running version of WordPress in case of pod restart.
digimod-filter-app
Deprecated - this plugin contained code for the filtering Vue app used for WCAG pages. The code has since been merged into digimod-theme-assets plugin in an attempt to resolve conflicting JavaScript issues arising from the complication process of these two plugins.
digimod-hide-edit-site-button (DIGIMOD - hide "Edit Site" button)
This plugin hides the “Edit Site” button from the top bar when navigating through the site while logged in as administrator.
digimod-misc (DIGIMOD - miscellaneous)
This plugin contains miscellaneous functionality that is too minor for it’s own plugin. Currently contains taxonomy for WCAG tags that couldn’t have been created through the user interface as well as WP CLI command that is used by the Reconfigure SSO GitHub action.
digimod-qa (DIGIMOD - QA functionality)
This plugin provides QA capability for the site for selected pages. For more information on the QA plugin, refer to the Processes OneNote document.
digimod-security (DIGIMOD - Security)
This plugin disables the /users API endpoint as well as prevents form logins for any users with “@” in their username. This mitigates concerns around brute force attacks on the site.
Note: It is still possible to create a user with elevated privileges and a simple password that would be allowed to login into the website. It is recommended to disable this functionality entirely on production to prevent unauthorized access using manually created users.
digimod-theme-assets (DIGIMOD - Block Theme Frontend Enhancements)
This plugin contains custom assets that override BCGov Block Theme behavior. Contains CSS rules specific to digital.gov.bc.ca as well as JavaScript scripts that manipulate DOM into correct form on custom pages, such as cards on Common Components page.
editor-rbac-plugin (Role-based Page Restriction)
The purpose of this plugin is to give users with selected roles to be able to edit specific pages in the “Pages” category. To adjust settings for this plugin, navigate to Settings → Role-based Page Restriction. Note that users will still be able to create and publish new pages that belong to them.
extendpreviewexpiry (Extend Preview Link Lifespan)
This plugin extends the expiry of preview links generated with the “Public Preview” plugin.
restrictcontentplugin (Restrict Content Plugin)
This plugin provides an ability to IDIR restrict specific content areas on the site, as seen on the https://digital.gov.bc.ca/cloud/saas/directory/ for the SaaS catalogue.
restrictpagesplugin (Role-based Page Restriction)
This plugin is used to restrict access to selected pages by redirecting users to the login screen. To adjust settings for this plugin, navigate to Settings → Restricted URLs
Content Team Workflow
The content team will primarily work within the production instance of WordPress. The workflow needs to be determined by the content team, and will inherently be complex due to the inclusion of third-party contributors.
...
It should be noted that these features and workflows only work in production. If the content team needs to make changes that are dependant on a new feature (and do that development in UAT), then we would need to pause third-party contributions, or otherwise redirect them to UAT to also perform their changes there. The author workflow would also be reflected there. Pipeline plugin? Content Blackout while changing in UAT?
Another request from the content team was to have a tree-style view of the pages in the admin dashboard. This can be accomplished with a plugin. Nested Pages - consider disabling drag + drop?
Lastly, it may be desirable to restrict the pages which a third-party contributor can edit/see on our wordpress instance. This could be accomplished with a paid plugin such as Role-Editor Pro, or using the free version in combination with some custom development. We should check to see if the paid role editor pro does everything we need with no custom development, and look into the procurement of that. If it requires any additional development, we can use the free version for role management, and add custom code for page restrictions based on rolesContent editing is restricted by the digimod-developed editor-rbac-plugin. The documentation on how to use this plugin is in the content team’s oneNote.