How exactly do automatic updates work?

3 comments

1. PHP isn’t a permanently-running process: it only runs when requested.
   So as far as I can tell, WordPress can only update itself when someone
   loads a web page. But the update process is not instantaneous, so
   surely a user visiting the site would have a really slow page load.

   Is there a different trick they use for automatic updates? I’ve
   searched all over the place but haven’t found any explanation.

   The system you’re looking for here is called “WP Cron”. It’s a background process system in WordPress that allows events to occur outside of normal processing. They still need a trigger to kick them off, but they don’t interfere with page loads because of the background process.

   So yes, somebody must load your page. Off in the default-filters.php file, you’ll find this line of code:

   add_action( 'init', 'wp_cron' );

   So, on every page load, the wp_cron function runs. This function is over in wp-includes/cron.php and what it does is to check the scheduled events in the database. If there are any processes it needs to run in the background, then it calls the function spawn_cron.

   Spawn cron has two possible methods of operation, but the first and most common one is to call the wp_remote_post function to make a connection back to itself, on the URL of wp-cron.php. By making this extra HTTP request, it starts another PHP process to do all the actual work. The request it makes here is non-blocking, with a timeout of 0.01 seconds. So, it doesn’t actually get any results here. The purpose of the request is simply to start a new process in the background. After this is done, it simply returns, so the viewing user never has any delays.

   The wp-cron.php process is what does the actual work, and the update, and everything else. Lots of processes in WordPress are handled by the cron system. Scheduled post publishing, processing pings, update checks, anything which needs to happen outside the normal flow can be scheduled and then run on an as-needed basis.

   But yes, a normal hit to the site must indeed happen to kick off the process. And no, WordPress.org does not contact your site directly to kick things off, your site has to receive some form of traffic to start it up. Any form of traffic will do.

2. Actually, the automatic update is pushed from wp.org. The update process still runs on your site, but in the background via wp-cron.

   When a new minor update is released, the guys at WordPress start to roll out the update. The actual update process is started after your site checked wp.org for updates, an update is theoretically available, and your site is chosen by random to be updated.

   ---

   (Thank you @otto for pointing out my wrong wording 🙂 )

   ---

   As every site checks with wp.org for new versions (usually twice dayily using wp-cron), the rolloutserver knows how many sites need an update.

   Then the rollout begins, starting slowly – 1 out of 128 sites gets updated automatically. This is being monitored, and if the successrate indicates no problems with the rollout, more of the sites get the automatic update (usually the next step would be 1 out of 64, and continuing to increase that way) until all automatic updates are delivered.

   This enables the developers to stop the rollout if any problems occur, but the last update from 3.8 to 3.8.1 has had a 100% success rate.

   The sites selected by the 1 out of 128 is actually random. Well, not really, but if you want to know, it works like this:

   The Url of the site needing an update gets hashed using MD5. Using just the first three characters of this hash and converting it to base10, this results in 4096 possibilities. The update started for sites having a calculated number between 0 and 31 (4096 / 32 = 128).

   Okay, i guess it’s pretty random after all 😉

   In my case, as I run a lot of WordPress sites, the updates took 1 day – was pretty funny to see when all the pages were updated.

   Just in case you were wondering 😀

   btw, here is an article on make.wordpress.org describing the process, as it happened.

3. In very broad terms, when a user visits the site wordpress checks for timer expiry and if an expiry is detected another request is sent to the server to “run” the actions associated with the expired event. This is why the user doesn’t feel any noticeable delay in page load, as the server is running the actual action (upgrade in this case) in a separate process.

   This works but the timing is not very accurate. The more traffic your site has the more accurate it will be.

   People that want to get better performance and more accurate timing can block the internal cron “process” wordpress has, and use the OS cron process to trigger the checking of timers.

Comments are closed.