Tests and CI/CD in WordPress?

If you haven’t worked with WordPress for 10 years then yes, the landscape has changed dramatically. When I first started working with WordPress in 2011 it was still the case that your average newbie with a “For Dummies” book could write a better theme or plugin than you could get from ThemeForest… which was mostly full of themes written by *other* newbies with “For Dummies” books.

10 years ago you could basically had to be able to add hooks and filters to functions.php, or at least be able to cut and paste them from recipes in hundreds of knowledge bases and other websites.

10 years later things have gotten a lot more professional. Instead of searching for a theme with the right pre-baked colors, layouts, and widget areas, and styles you can use one of the lightweight, all-purpose themes and configure it the way you like through the Customizer. In the increasingly less-likely circumstance where you’d need to add more CSS the default WordPress Customizer has a realtime CSS editor.

WordPress standards for what can be uploaded to the theme and plugin directories has advanced to a point where you can’t just upload any junk you like and abandon it there. That means the plugins you can find have nearly all the code you used to have to write yourself. With the benefit that by the time you’re willing to add it to your own site it’ll have been effectively tested by thousands or hundreds of thousands of users.

Bottom line is that if you’re coming back to WordPress you’d be surprised and (if you’re a professional programmer) possibly disappointed by just how little additional code needs to be added compared to 10 years ago. (Note: some WordPress pros still haven’t reconciled themselves to this.)

That doesn’t mean there’s no role at all for professionals. For the last 10 years I’ve been doing what you have — basically adopting old, out of date, slow, malfunctioning, or outright broken WordPress sites that someone else built, and bringing them up to standards. That includes vetting and replacing bad plugins, optimizing images, cleaning up befouled databases, clearing out files and folders that don’t belong, cleaning up malware if necessary, and occasionally replacing code written by earlier programmers with clean plugins that do the same thing only faster, more securely, and compatible with current best practices. And then training their owners so they won’t let it fall to pieces again.

> So how do people test these kinds of low code WordPress sites? Currently there is no staging server, no pipeline, no version control, everything happens on production. If a plugin upgrade fails, or breaks something else, bad luck I guess? Not sure about backups. And the database is currently littered with test users and garbage data.

This is a great question. It depends a lot on how critical the site is to operations and what the consequences of downtime are. Also how much custom code there is.

These days almost all decent hosting companies offer staging servers with clean migration between. So you can run updates on a staging site, check to see what happens, and then either migrate from staging or just run the updates in production. If there’s custom code then you can use Git for version control and either push to production or, more sensibly, update on staging for testing and then push to production or just upload the new zipped code.

Note: nobody overwrites core anymore and with few exceptions people don’t overwrite base themes. Instead all customization should happen in custom plugins or child themes. That makes it easy to update new code either via Git to staging or by uploading zipped plugins or child themes. directly to production via the WordPress interface.

Most modern hosting also offers decent daily backups. There are a number of good backup plugins as well. So rolling back is pretty easy, and if your backup plugin creates full archives (files + database) you can always download it to a desktop server like Local by Flywheel for destructive testing.

Cleaning up the database is its own separate thing. Definitely something you want to do in staging or with a desktop instance.

5 Comments

JasontheWriter says:
August 18, 2023 at 6:09 pm
Staging sites. A lot of server companies allow you to set up a staging environment with a few clicks. Siteground is one I know of that for sure does this.
These server companies also offer backup services.
alx359 says:
August 18, 2023 at 7:11 pm
> it feels crazy to have no automated tests covering this stuff.
You’re right, and I’ve wondered the same myself. There are plugins that can mitigate this though.
> everything happens on production
That’s just a bad practice, not a WP issue. Need to deploy a staging server ASAP and do the cleansing, dev, and upgrade stuff in there first.
> Seems like there is basically no code involved and everything is done by configuring plugins and APIs.
That isn’t necessarily true. WP is a DIY framework and it can be a lot of dev work if the canned functionality from core & plugins isn’t matching requirements. There are approaches like headless WP and Custom Fields (ACF/Metabox) that have a lot of custom dev.
hippotwat says:
August 18, 2023 at 8:13 pm
We run CI/CD on our dev and prod servers, branch to dev then test, merge back to prod. This should be familiar to you, even updates to plugins are handled this way.
ciaran2016 says:
August 18, 2023 at 8:24 pm
It might be worth looking into using Bedrock. Simple to setup on local. Staging, dev and production supported
RealBasics says:
August 18, 2023 at 9:39 pm
If you haven’t worked with WordPress for 10 years then yes, the landscape has changed dramatically. When I first started working with WordPress in 2011 it was still the case that your average newbie with a “For Dummies” book could write a better theme or plugin than you could get from ThemeForest… which was mostly full of themes written by *other* newbies with “For Dummies” books.
10 years ago you could basically had to be able to add hooks and filters to functions.php, or at least be able to cut and paste them from recipes in hundreds of knowledge bases and other websites.
10 years later things have gotten a lot more professional. Instead of searching for a theme with the right pre-baked colors, layouts, and widget areas, and styles you can use one of the lightweight, all-purpose themes and configure it the way you like through the Customizer. In the increasingly less-likely circumstance where you’d need to add more CSS the default WordPress Customizer has a realtime CSS editor.
WordPress standards for what can be uploaded to the theme and plugin directories has advanced to a point where you can’t just upload any junk you like and abandon it there. That means the plugins you can find have nearly all the code you used to have to write yourself. With the benefit that by the time you’re willing to add it to your own site it’ll have been effectively tested by thousands or hundreds of thousands of users.
Bottom line is that if you’re coming back to WordPress you’d be surprised and (if you’re a professional programmer) possibly disappointed by just how little additional code needs to be added compared to 10 years ago. (Note: some WordPress pros still haven’t reconciled themselves to this.)
That doesn’t mean there’s no role at all for professionals. For the last 10 years I’ve been doing what you have — basically adopting old, out of date, slow, malfunctioning, or outright broken WordPress sites that someone else built, and bringing them up to standards. That includes vetting and replacing bad plugins, optimizing images, cleaning up befouled databases, clearing out files and folders that don’t belong, cleaning up malware if necessary, and occasionally replacing code written by earlier programmers with clean plugins that do the same thing only faster, more securely, and compatible with current best practices. And then training their owners so they won’t let it fall to pieces again.
> So how do people test these kinds of low code WordPress sites? Currently there is no staging server, no pipeline, no version control, everything happens on production. If a plugin upgrade fails, or breaks something else, bad luck I guess? Not sure about backups. And the database is currently littered with test users and garbage data.
This is a great question. It depends a lot on how critical the site is to operations and what the consequences of downtime are. Also how much custom code there is.
These days almost all decent hosting companies offer staging servers with clean migration between. So you can run updates on a staging site, check to see what happens, and then either migrate from staging or just run the updates in production. If there’s custom code then you can use Git for version control and either push to production or, more sensibly, update on staging for testing and then push to production or just upload the new zipped code.
Note: nobody overwrites core anymore and with few exceptions people don’t overwrite base themes. Instead all customization should happen in custom plugins or child themes. That makes it easy to update new code either via Git to staging or by uploading zipped plugins or child themes. directly to production via the WordPress interface.
Most modern hosting also offers decent daily backups. There are a number of good backup plugins as well. So rolling back is pretty easy, and if your backup plugin creates full archives (files + database) you can always download it to a desktop server like Local by Flywheel for destructive testing.
Cleaning up the database is its own separate thing. Definitely something you want to do in staging or with a desktop instance.

Lost please help me...

eID & Memberpress