Server Setup

Performance-friendly WordPress updates

by , , revisited on


We have by far the largest RPM repository with NGINX module packages and VMODs for Varnish. If you want to install NGINX, Varnish, and lots of useful performance/security software with smooth yum upgrades for production use, this is the repository for you.
Active subscription is required.

Updating your WordPress core and plugins with themes is very important to retain security, as well as brings new features.
What is the ideal way to perform such updates? Let’s review from worst to the best.

Manually updating your WordPress from admin

Manually updating your WordPress site from the administration area is the worst you can do.
It is subject to many errors, prone to timeouts, should your webserver be misconfigured.

One of the symptoms of such misconfiguration is “Another update in progress” error.

Another update in progress error
Another update in progress error

How to fix “Another update in progress” error

A failed upgrade due to timeouts will result in “Another update in progress” error when trying to complete the upgrade.

To fix this, use WP-CLI:

wp option delete core_updater.lock

Built-in WordPress automatic updates

WordPress automatic plugin updates were introduced in WordPress 5.5.
It is a great way for securing your website.

What’s the problem with WordPress automatic plugin updates?

When you use Varnish or another type of full page cache, each and every plugin’s update will result in a complete cache purge!
A typical WordPress installation has more than a dozen of plugins, which are regularly updated by their authors.
That means your cache is unexpectedly flushed every now and then. And it takes hours, if not days, to rebuild it.
Until yet another update clears the cache again. Your website never reaches its full performance potential… Yuck!

DYI Automatic Updates

Thanks to WP-CLI, there’s a way to create your own updates schedule, that will neither interfere with your cache, nor bug you with having to update manually.

First, ensure that any automatic updates in WordPress are disabled. In wp-config.php, add at the top:

define( 'AUTOMATIC_UPDATER_DISABLED', true );

Further, don’t let yourself be disturbed by plugin updates, and disable updating from the browser:

wp plugin install hide-updates --activate

Add this to your theme’s functions.php in order to hide the updates from website creator user as well:

function site_hide_updates_allowed_users() {
    return [];
}
add_filter( 'hide_updates_allowed_users', 'site_hide_updates_allowed_users' );

To see updates manually, you can use wp plugin list in Terminal.

Setting up cron for updates.

Now the key of automatic updates. Set up a cron job for updating everything one time a month.

MAILTO=user@example.com
@monthly wp plugin update --quiet --all 2>&1 && wp --quiet theme update --all 2>&1 && wp --quiet core update 2>&1

This uses output redirection for stderr. Should there be any errors, they will be included in the output. Subsequently, we use the standard cron feature of emailing the output to our specified email.
Now, in this way, you are up-to-date on everything and your cache does not suffer rebuild issues.

Users of WooCommerce may want to add && wp --quiet wc update 2>&1 to the bunch of commands in order to update its database.

Following that, you can improve this by:

  • Setting up consistent cron and CLI jobs environment. Your cron jobs will not be memory limited and will be faster by using file-based OPcache
  • Installing cachetool utility and set up opcache-reset WordPress plugin. This will automatically prune OPcache even when updates are performed via CLI/cron. This is required in case you run PHP with opcache.validate_timestamps=0, for performance reasons.

And of course, you can improve your updates further, by automatically running a cache warmup after the update the cron job.
See a minimalistic cache warmer example.

Updates’ safety

Sure enough, updates can bring your website down. So you may want to combine this with a “shadow” website. And running the updates at the live site conditionally, only when some tests succeeded after updating the shadow/clone website.

However, if you keep the server software up-to-date and use a careful selection of quality plugins, the necessity of setting up a shadow website is minimal.

Leave a Reply

This site uses Akismet to reduce spam. Learn how your comment data is processed.

%d bloggers like this: