I am looking for a modern, reliable, solid rock development workflow for Wordpress, but most articles only explain individual parts. Some talk about very specific aspects like the way of deployment, but neglecting basic concepts. In the following, I outline what I have so far. Two questions are included, but if you have remarks regarding other aspects, I am very happy to hear them.

Scenario:

Wordpress installation with plugins and theme that include custom business logic. We want to ensure high quality in maintaining (e.g. updating) and developing the wordpress-based website. For drafting and publishing content, the single production environment seems enough.

Requirements:

• update regularly core and plugins
• changes are version controlled
• deployed to multiple environments, e.g. locally, staging, production
• the site behaves in the same way in each environment

Wordpress aspects to consider for each requirement:

• uploaded content files
• plugins, themes, wordpress core
• configuration, stored in files and database
• the database scheme

My current draft and questions:

Seeding

Given a running wordpress installation, the following helped in providing the initial environments:

• check all files into version control, except for uploaded content files
• mirror the production database for other environments; adapt hardcoded URLs in the database, e.g. via wp-cli, because they will differ per environment
• put Wordpress\' uploaded content files onto a NFS; mirror this location for other environments

From this point on, the goal is to keep environments reliable.

Update regularly core and plugins

Done via the admin webinterface, only in local environment. The local environment allows us to spot incompatibilities right away. The updating of other environments will propagte through a CI/CD pipeline. For example, once everything is fine locally, we commit to a staging branch in git, and if that is fine as well, we merge into production branch. See below for details.

uploaded content files

Not affected.

plugins, themes, wordpress core

Can all be updated via the webinterface.

configuration, stored in files and database

Changed or new configuration propagtes via files just fine into other environments. Regarding configuration in database: new configuration like default values, should propagte fine. Others are problematic.

Question 1: How do you make sure, new configuration stored in database propagtes into all environments? Ideas that come up are manual configuration in each environment, or programmatically via scripts.

Mark Kuplun suggests to make such changes via API calls or defining filters.

the database schema

The core updates the schema fine by using update routines and the database version number. I hope plugins do the same. This means, by having the up-to-date file versions, database schema changes will propagte fine to other environments.

Question 2: is it safe to assume plugins work this way?

Is database safe after merging a branch of a more recent version over an older one? relates to this, but only covers the Wordpress core. Plugins are not covered. Also, the answer does not give any sources.

Changes are version controlled

Keep the entire wordpress installation with its files in git. Exclude uploaded content (see below). Although this will keep alot of files under version control, which could easily be built from source files (e.g. minified css files, or composer dependencies from plugins), I do not see a viable alternative as Wordpress simply does not provide means to built it with themes and plugins from scratch.

uploaded content files

Ignored, because not considered critical. We do not want to test and develop content by using different environments, but business logic.

plugins, themes, wordpress core

Files are checked in. This is covered.

configuration, stored in files and database

Configuration in files is stored in version control. When configuration changes in database are propagated manually across environments, this cannot be version controlled. So it asks for a progammatic approach to make these changes (see above).

the database scheme

The wordpress core has update routines for this, so it is version controlled via the checked in source code. I assume, plugins do something similar.

Deployment to multiple environments

The way of deployment is not so important; via ftp upload, git checkouts, or docker images. But docker images have a big advantage, see below.

Multiple environments can be achieved in an automated fashion e.g. via provisioning and configuration tools, a CI/CD tool, version control and branches. Since this is not wordpress-specific, I will not go into details here.

By making sure everything can be updated and version controlled, the deployability is also ensured.

Site behaves in the same way in each environment

By using container images, all dependencies like php and webserver are the same in each environment. This is not different to any other php application.

The important part is to avoid that environments are drifting apart, e.g. by updating the production environment via admin webinterface manually. Therefore, we apply the policy that updates and changes are only done in local environment, added to version control and then propagated to later stages/environments automatically.

The production environment will drift apart regarding the content, because our content managers are working in that environment. Such a drift might be irritating, because pages will start to look very different across environments. Also, some issues might only arise on certain content pages in combination with plugins and theme. To cover this, we can mirror the production environment\'s uploaded-content NFS and database just as we did during seeding, best automated, in regular intervals or on demand. They are not version controlled, because they are not risky. Conceptually, this is the only time where data flows from a higher environment (production) to a lower environment (staging, or local).

Setting apart from other questions

There are numerous questions on this platform, that have slight differences. Let me try to set the current one apart from these.

• Efficient Wordpress Development Workflow Help? Tackles the question, how to migrate one environment database to another while replacing URLs in the database. This is not something I want to tackle currently. Instead, I only want to ensure that the database schema gets updated properly.

• Trouble with Wordpress local development and deployments This is about differences in local and production environment, causing trouble in deployments. Since I am using the same docker images locally as well as live, this is not an issue. It is just important that all file-system related changes (e.g. updates) are made locally, otherwise a new deployment would overwrite file-system related changes in production, and all database related changes (e.g. relevant configuration) are made in both environments, e.g. programmatically or by syncing back the production database to a local version regularly.