The WordPress Site Editor vs a modern deployment process

Profile picture for user Silas
Silas Albrecht
Senior Developer

The big news yesterday, January 25, 2022, in the WordPress world was the release of WordPress 5.9 and the inclusion of the Site Editor. The Site Editor essentially allows a site builder to modify the theme templates using Gutenberg to place and move blocks around. You can modify all parts of the homepage and also templates like the page template. The modified version will then be used as the template for all pages on your site. This functionality is very similar in ways to other site theming tools, such as Elementor Pro’s theme builder.

I loaded version 5.9 locally and played around a bit with it. One interesting thing that immediately came to mind, aside from how powerful the editor is, was how this type of site building complicates implementing many of the best practices I’ve come to cherish as a professional developer.

Now, using the Site Editor or even a theme that supports it is completely optional. “No code” development has always been an option for WordPress sites. I do think it’s important to point out, however, that by using the Site Editor and getting all the benefits out of it, you’re also putting a large amount of your app’s theming into the database. For actively developed sites, this complicates any process of sharing these changes across multiple sites or across multiple environments for the same site (think deploying a ton of changes you’re testing on dev to production).

My experience of late

I’ve been working on a number of WordPress sites and, increasingly, I’ve been working to find ways to understand other developers’ expectations and how I can adapt or suggest improvements to our shared workflows.

My suggestions revolve around generally accepted best practices for enterprise applications I’ve worked on in the past, which include some enterprise WordPress sites. However, while some WordPress sites follow these best practices, there’s a vast middle ground of WordPress applications that aren’t hobby sites, but also don’t have advanced development teams in place, and these sites often have different processes in place than I would expect.

The common WordPress workflow I’ve seen consists of making file changes on a local machine and uploading them via FTP. Often, significant changes are done directly in the production environment through WordPress’s admin interface. This process allows a single developer to make changes while only using a few simple tools.

So what’s wrong with this? In some ways, nothing. It depends on your goals, your team size and ability and your budget.

Below I’ll explain some positive attributes I try to bring to all my software development engagements, and how these tie into the workflow described above.

Automation

A key element of DevOps is automation. There are great benefits to automating as much as possible. We can gain speed and reliability. If a deployment happens at the push of a button, rather than needing to upload a few directories and change various settings in a web browser, we can reduce room for human error. If testing is automated, we can save time by finding bugs earlier in the process and avoid fixing them in production. If deployments alway happen the same way, and we run them first in a non-production environment, we can be nearly certain nothing will break when we deploy to production.

The generally recommended path for automating deployments is to build a continuous integration (CI) flow that builds, tests and deploys a Git-based project. This includes at least the following steps:

  1. Load project code onto CI platform
  2. Download required third-party plugins and libraries and build javascript and CSS assets
  3. Run linting and tests to assure quality
  4. Deploy all files to specific environments

Oddly, in the WordPress world, what’s generally automated is deploying updated plugins. However, automating only plugin deployments, and having no testing in place, leads to the risk of breaking your site. Instead of this, I’d recommend setting library and plugin versions in code (for example with a tool like composer). This allows for the CI process above to be run consistently first in testing environments and then, when the team has ensured nothing breaks, in production.

Moving towards continuous integration

The first step toward moving our WordPress sites to a reliable CI workflow, is to find ways to stop making changes through the admin interface. This means putting configuration into code, which is exactly where we run into problems with a tool like Site Editor. Templates need to be coded as PHP files, or, if you’re using a tool like Site Editor or Elementor, you’d need to find a way to export and import changes so they can be saved to Git and loaded into each environment’s database. (If anybody has a recommended way to do this I’d love to know! Ideally it would work for multisites or separate maintained sites and across different environments).

Second, once everything is in Git, we can take the next step toward developer Utopia: local development. The development team can easily, with tools like Lando and Docker, create identical local development environments by pulling down the Git code and a database from one of the hosted environments. Code can then be developed easily locally and new team members can safely and easily set up the project. Code changes, including adding plugins, adding or changing fields (either with a plugin like ACF, or in a custom plugin), changing code-based templates, adding blocks etc. can be done locally, pushed to Git for review and then merged into the main branch. This process ensures the team member’s changes are peer-reviewed and, on merge, don’t conflict with other changes.

Lastly, by having all the important bits of the application in code, we can track changes over time, and revert changes that cause problems. The repository becomes the source of truth and also a comprehensive history of our project.

Reality

Many teams or individual developers may bristle at the changes required to move so much into code. Training may be necessary, and at first it may seem challenging. The organization may be used to asking non-developers to make changes via the admin interface using tools like Site Editor. The group might decide that twenty minutes of downtime, or a weird-looking page here and there from the occasional human error, might be OK. If the project is developed by a single person, some benefits like reducing the likelihood of overwriting another’s code won’t have any value. However, if the goal is reliable, quality, enterprise-level development and the application we’re working on is important for the organization, the best practices above should generally be followed.

 

comments powered by Disqus