Spinning up white label WordPress CMS for businesses faster -Part 1

Join us in the journey of how we provision a new Content Management Systems (CMS) faster for our newsrooms. In this 2 part series, we will walk through the techniques that helped us to set up CMS’s faster and also address some of the pain points that we had faced over the years.

Content Platforms

At News UK the Content Platforms team is accountable for developing and maintaining digital tooling that enables our newsrooms to publish content as easily as possible.

We are aligned with News Corp CMS strategy to use WordPress across our newsrooms and build common capabilities that can be reused by different newsrooms. We operate WordPress as headless CMS and expose content in the form of REST APIs so other teams can render the websites for our readers.

The Problem

Alongside managing existing CMS’s, we started getting requests to spin up new CMS’s. The new requests included new features which we didn’t have in our existing toolbox.

Also, there was no clear data available to identify the duration it takes to set up a baseline WordPress CMS. This uncertainty along with new business requirements created an opportunity for defining the OKRs to address these issues and achieve better results:

1. Reduce the time-to-market for new propositions
2. Reduce the cost of building, enhancing and maintaining propositions
3. Enable innovation and experimentation with WordPress features and functionality

This series focuses on how we achieved our first OKR. However, all the above OKRs are inter-related as we consider cost, reusability, maintenance, and innovation throughout the process.

Reduce the time-to-market for new propositions

Planning is everything, isn’t it? To achieve this OKR we decided to build a standard template to set up a white label CMS. The goal here is to use the same template to build any future requests as well. The following outlines what we aimed to create as reusable building blocks:

• Local Development setup
• Building generic capabilities
• Composer as Dependency Manager
• Plugin activator

Note: The below topics will be covered in detail in Part 2 of the series.

• Repository Management
• Unified deployment workflow
• Content Schema
• Standard CI/CD pipeline

Local Development Setup

If you’ve ever worked with WordPress, you would have come across their famous five-minute install to set up a website. Similarly, we wanted to create a simple local setup for our engineers. Our goal is to create a setup that can be reused to spin up multiple WordPress projects using the same process.

Since we host our CMS’s with WordPress VIP we also had to consider WordPress VIP standards for the local development setup.

We created a docker based local environment that automatically sets up a WordPress multi-site based on config and installs necessary mu-plugins. With git and docker installed, an engineer can spin up a local development environment with a single command.

Building generic capabilities

One of our key objectives is to build generic capabilities that can be reused across multiple projects. The new plugins and themes are developed and maintained in separate repositories which are heavily tested in isolation. The new capabilities are also tested to ensure its compatibility with the latest PHP and WordPress versions. Every new feature from the plugin and theme are tagged with a semantic version to be used by CMS’s.

The plugins are built in a generic manner and exclude any title-specific customization. However, they provide actions and filters to hook in to for accomplishing the title-specific needs. The customizations are applied from the site theme by using the exposed actions and filters from the plugins.

This is an example of how we customize plugin functionality from a theme level.

Composer as Dependency Manager

Composer is a tool for dependency management in PHP. It allows us to declare the libraries our project depends on and it will manage (install/update) them for us. We use composer to install plugins and themes that are hosted within NewsUK Github for a given WordPress CMS.

We value `config as code` philosophy where all necessary capabilities like plugins and themes are required via the `composer.json` file using the semantic versioned tags.

This is an example of how plugins and themes are added to a CMS as composer dependency.

Plugin activator

We went one step further to create a plugin that expects a config file to hold necessary plugins, themes and automatically enables them in a given environment. It also accepts some additional settings that enable any plugin to load after a particular point in the WordPress actions execution order. It also adheres to the `config as code` philosophy and avoids any manual intervention to manage plugins in production environments.

Here is an example of a config file that is responsible for enabling plugin at different levels.

Thank you for reading through our journey so far. More details on repository management, deployment workflow, CI/CD setup on Part 2.