In WPCD Version 4.9, we added a new feature to allow the admin to trigger update of themes, plugins and even WordPress, from inside the WP dashboard. And in Version 4.10 we improved it by adding a couple of other tweaks.
This feature will be useful for agencies to use on sites that are not critical and can handle some downtime. For many agencies, that’s 90% or more of the sites under management. So judicious use [of this feature] can help you to quickly power through updates.
You can find the update tools in the SITE UPDATES tab for your site.
This feature is not intended as a replacement for site management tools such as MAIN WP or for the built-in auto-updates in WP. But, if, for some reason you prefer not to use those types of site management tools, then these basic functions can be used to update your sites on demand, one at a time or in bulk.
However, probably the most powerful feature is the bulk updates.
Combined with automatic backups before updating and an automated visual check of the home page after updates, most of your non-critical sites can be updated with just a few clicks.
And, because we provide such flexible filters at the top of the site list you can do things such as:
Tip: If you have sites that you do not want to include in group updates, you can add them to a color-coded GROUP. Then when you apply your filter (or select all sites), you will instantly recognize those color-coded tagged sites and be able to unselect them.
We use the https://htmlcsstoimage.com/ service to take a screen shot before and after updates are complete. An image of the home page is taken before any updates and another is taken afterwards. If there are more than 1000 pixels that are different between the two images, the site is restored from the backup. You can change the threshold from 1000 pixels to a higher or lower value on the settings screen: WPCLOUDDEPLOY → APP:WordPress Settings → Theme & Plugin Updates.
To use this service you need to sign up for an account and fill in the API USER NAME and API KEY on the WPCLOUDDEPLOY → APP:WordPress Settings → Theme & Plugin Updates tab.
We attempt to create a backup before updating the site. If you’d like to make sure that your backups end up on your AWS bucket, then you should ensure that you configure backups for the entire server (or for each of your sites) prior to initiating update operations.
If you do not configure backups, there will be errors in the logs but we will not stop the update process. And any backup files created in this instance will remain on the disk only.
Additionally, please ensure that your RETENTION days value is NOT set to ‘-1’. The ‘-1’ value indicates that no backups should be left on the local disk. If ‘-1’ is used for your retention days and we have to restore a site, there will be no local backups to restore from.
We use our basic backup scripts, not our advanced backup scripts for these backups.
Bonus: If updraft-plus is installed we will attempt to trigger a backup using its wp-cli command as well.
We attempt to clear caches after updates. If certain well-known cache plugins are installed AND their corresponding wp-cli extensions are also installed, we’ll use wp-cli to invoke the plugin to clear their cache.
The cache plugins we’ll attempt to clear are:
We cannot always reliably detect when these plugins and their associated WPcli extensions are installed so you might sometimes see errors as we attempt to invoke them. If the plugin is not installed on the site you can ignore those errors.
The WPCD settings screen has two options that allow you to exclude themes and plugins from being updated.
If an exclusion list is supplied, updates will be slower.
If the comparison of the images taken before and after an update fails, we will try to restore the site from backup. If the backup failed for any reason then this might not be possible and you will have to manually restore the site from an older backup.
If you have a site where data is constantly being added, you might not want the automated restore to kick in. The automated restore might cause you to lose data that was created between the start of the backup and the end of the update. For these sites it’s better to handle the updates manually (or modify our update script to prevent restoring data on those sites.)
When doing bulk updates, your best troubleshooting tools are the COMMAND LOG and PENDING LOG screens.
If you’d like to force a failure for an update so you can see how a site is restored, we’ve got you covered. Set the variance pixel count to -1 on the WPCLOUDDEPLOY → APP:WordPress Settings → Theme & Plugin Updates tab to always force a restore after update.
This works because a negative number will always return a failed status when comparing the before and after images – even if zero pixels have changed it would still be greater than -1.
One of the biggest issues with SaaS systems is that you can’t easily customize the WP update process. So after an update you find yourself doing things like flushing various caches using the different cache plugins your clients have on each site. Maybe disabling and re-enabling plugins to force them to recognize new WP features and so on.
With WPCD you can modify the scripts directly to add these actions so that they get done for you automatically! It’s the ultimate in customization and is likely to save you a TON of time!
We are keeping this feature in permanent beta status because there are just way too many things that can go wrong. If you’re an agency that’s worked with WordPress for a while, you already know that when it comes to WP updates, nothing can be taken for granted. They generally work but can fail for odd and, sometimes, very silly reasons.
Therefore as with all computer systems you should make sure that you perform regular backups and especially do so before an update.
Some examples of things that can go wrong:
If you’re using this feature one site at a time, it’s not much of an issue because you can see the feedback on the screen. But if you’re using BULK ACTIONS to handle multiple sites that’s a whole lot more difficult to manage when automated recovery is necessary.
This does not mean that the feature isn’t usable in production. By keeping it as a permanent beta we’re just reminding you that you need to pay attention to the updates as they occur and that you can’t blame WPCD for everything that goes wrong with them.
If you have a site that you can update using the normal WordPress update screen but that is erroring out while updating using WPCD, we definitely want to know about it. Most of the time the issue is likely to be a plugin or theme on the site that is not compatible with wp-cli. But if that’s not the case we’d like to figure out what else is going wrong. So please contact support – we can log in and take a look at the logs.
This is a powerful tool that you should use – but use it judiciously. As with anything related to updating a WordPress site, when an update works it’s great; when it doesn’t you just have to take a breath, sigh a little then buckle down to find the culprit(s) and deal with them. Just because this tool makes it easy for you perform updates does not mean you can just rest easy. WP updates are always a PITA – our tools just make them a little less so!