How does the WordPress Automatic Updates system actually work?

There is not much in the way of explanation about this feature from WordPress.org. You really only get a handle on it if you're coding with it, and after much trial and error, here are the ultimate basics of how WordPress automatic updates works.

How does the WordPress Automatic Updates work?

Below is a basic run-down of how the automatic updates system works.  It's not complete, and there may be mistakes, but if you're a developer, or you just want to understand how it works and why perhaps it's not working on your site, this is a good place to start.

1) WP Cron Runs the Automatic Updates action

At a set time each day (twice daily), WordPress will run the automatic updates process through the WP Cron system.  Currently it is scheduled for 7am and 7pm local time - i.e. according to your WordPress time settings.

  • The cron job name that is run is wp_version_check
  • Note: In the interests of developers, the action run is: wp_maybe_auto_update  andit's fired from within the wp_version_check  action/function
  • Note: This does not perform any update checking! It runs off the currently "known" available updates for the site. Update checking is run on a separate schedule.

2) Check whether it's disabled or permitted

First, the automatic updater checks whether the whole automatic updates system has been disabled. There are 3 ways to completely disable it:

  1. Set the define: DISALLOW_FILE_MODS to true.
  2. Set the define: AUTOMATIC_UPDATER_DISABLED to true.
  3. use the WordPress filter: 'automatic_updater_disabled' and return true from it.
  • Note: Automatic updates are not available if WordPress is currently being installed.
  • Note: The WordPress filter takes priority over the "AUTOMATIC_UPDATER_DISABLED" define so that even though the define might explicitly disable the updates system, any plugin can re-enable it using the filter. In my opinion, this is not ideal design
  • Note: If the automatic updates is running the cron under Multisite (WPMS) as the main network site or primary site, automatic updates are not permitted to run ever.

3) A database lock is attempted

It attempts to create a lock to ensure it only runs once. If it fails and the current lock is valid (if it exists), it stops processing.

4) Check for plugin updates and get list of available updates

Previously we stated that it doesn't check for updates.  It doesn't, but it will check if the time between "now" and the previous check is large enough.

5) For each available plugin update, run the update for that plugin

This is now where the processes gets a little convoluted.

For each update attempt, it again checks for whether automatic updates are disabled, also checks that filesystem credentials are valid (i.e. the site has permission to even write to disk to perform the update).

Then it applies a very powerful filter based on the plugin name.  This filter allows you to specify whether automatic updates are available for plugins of a very specific name.  That is to say, you can disable, for example, plugin updates for all plugins except for a specific plugin.

  • Note: The filter name is 'auto_update_plugin' and you can apply a custom filter here with 2 parameters: 1) boolean: update; 2) string: plugin file name.  And if the plugin file name matches the one you want to modify, you can return true or false specifically for the plugin.

6) For each available theme update, run the update for that theme

Exactly the same as for plugins is run for themes.

7) Run the update for Core updates

The process for updating the WordPress core is a little more complex and has more filters and defines available to modify the default behaviour.

For better understanding on the WordPress Automatic Updates system, read the blog article here.