WordPress 4.9.4 Release – The technical details

Today we’ve released WordPress 4.9.4, the day following WordPress 4.9.3.

WordPress 4.9.4 is the first minor release of WordPress in over four years since WordPress 3.7 was released where not all users will be receiving an automatic update.

This isn’t by choice – a bug went undetected during the 4.9.3 development cycle, and was only discovered hours after 4.9.3’s release. The bug causes a PHP Fatal error to be triggered when WordPress attempts to update itself.

Unfortunately this means that WordPress Administrators will need to proceed with a WordPress update themselves, through the WordPress Administration panel (Just hit Update Now under Updates), using WP-CLI, or via FTP. Hosts who apply updates automatically on their customers behalf will also be able to continue to update sites as normal.

What Happened? #43103-core aimed to reduce the number of API calls which get made when the autoupdate cron task is run. Unfortunately due to human error, the final commit didn’t have the intended effect, and instead triggers a fatal error as not all of the dependancies of find_core_auto_update() are met. For whatever reason, the fatal error wasn’t discovered before 4.9.3’s release – it was a few hours after release when discovered.

Ways to update:

  • Through the WordPress Administration area: Simply visit your WordPress Dashboard → Updates and click “Update Now.”
  • With WP-CLI: If you have command line access to WordPress, and WP-CLI installed, wp core update will update your site just as quickly as before.
  • Manually by FTP: If you prefer, you can update by Downloading the latest ZIP, and using FTP to upload it to your site. The only changed files expected are wp-includes/update.php & wp-includes/version.php.
  • With PHP: If you have command line access, you can also update WordPress simply by running wp_maybe_auto_update() inside of WordPress, for example: php -r 'include "wp-load.php"; wp_maybe_auto_update();'. This is also how we suggest hosts who don’t have WP-CLI installed proceed with automated updates for their customers.

As noted above, only two files changed in this release – wp-includes/update.php & wp-includes/version.php.

Are there any security implications? WordPress 4.9.3 and 4.9.4 do not include any security fixes, however, in order for WordPress to receive future security updates automatically sites will first need to be updated to 4.9.4.

What we’re doing to prevent this happening again We’ll be making a follow up post after we’ve been able to determine how to ensure that this never happens again. We don’t like bugs in WordPress any more than you do, and we’ll be taking steps to both increase automated coverage of our updates and improve tools to aid in the detection of similar bugs before they become an issue in the future.

#4-9-4, #43103-core

Plugin Automatic Security Updates

Just a quick note that I’ve published an overview of the background updates for plugins over on the Plugin Announcements blog – https://make.wordpress.org/plugins/2015/03/14/plugin-automatic-security-updates/

If you’re a plugin author, and not following that blog, now would be a good time to head on over and subscribe 🙂

Automatic Core Updates, an update

Over the last few weeks I’ve been working on bringing Automatic Core Updates to WordPress 3.7 through #22704, Up until now it’s been disabled in trunk while development in progress – today however, that all changes.

As of [25598] WordPress 3.7+ installs will begin updating themselves without the need of user input every time a new security release has been released, or in the case of all us development users, it’ll update daily to the latest nightly if possible.

Automatic Updates are unattended, and by default, will only update WordPress to security releases (for example, from 3.7 to 3.7.1, but not from 3.7.1 to 3.8). Great lengths will be taken to ensure that no site will break as the result of an Automatic update.

Note: Filter and constant names may change pending feedback and discussion.

Edit, October 18: WordPress 3.7 RC1 changed some filter names. This post now reflects the latest names. AUTOMATIC_UPDATER_DISABLED does not work in RC1. This is fixed in 3.7-RC1-25851.

In order for Automatic Updates to be enabled, there are a few simple requirements:

  1. If the install uses FTP for updates (and prompts for credentials), automatic updates are disabled
  2. If the install is running as a SVN or GIT checkout, automatic updates are disabled
  3. If the constants DISALLOW_FILE_MODS or AUTOMATIC_UPDATER_DISABLED are defined, automatic updates are disabled
  4. If the constant WP_AUTO_UPDATE_CORE is defined as false, automatic updates are disabled
  5. Your WordPress install also needs to be able to contact WordPress.org over HTTPS connections, so your PHP install also needs OpenSSL installed and working
  6. Wp-Cron needs to be operational, if for some reason cron fails to work for your install, Automatic Updates will also be unavailable

We’ve also been working on a bunch of related features to make updates even more bulletproof than before, including HTTP, Filesystem, and File verification enhancements, amongst many other things.

How do I test it?

If you’d like to test this out, the simplest way is to simply create a new non-svn checkout of trunk and visit the site regularly to make the cron task run.
If you’d like to test this out, and you’re running SVN/GIT, you can use add_filter( 'auto_upgrade_ignore_checkout_status', '__return_true' ); in a mu-plugin to make it ignore the checkout status, note, that you’ll lose any modifications you’ve made to core files.

After each update, you’ll receive an email with a summary of the actions taken, which will let you know if the upgrade completed, or encountered any problems – the emails are still a work in progress, the email currently in trunk is designed for developers, and may not be the same in the final release.

I don’t like the sound of this, How do I turn it off?

  1. If you’re using a deployment system that uses SVN or GIT, it’s disabled by default
  2. The simplest way to disable it is to add define( 'AUTOMATIC_UPDATER_DISABLED', true ); to your wp-config.php file
  3. You can also make use of the auto_upgrader_disabled automatic_updater_disabled, or, auto_upgrade_core auto_update_core filters

Are there any more hidden features?

This is WordPress we’re talking about, of course there’s a bunch more that it can do!

  1. If you’re using a non-English install, this will also automatically update any plugin/theme Language Packs which are installed, hopefully resulting in a better i18n experience, See #18200 for more information on Language packs, there’ll be a follow up post in the near future explaining how and when Language packs will work
  2. Plugin & Theme Updates! – You can hook into the 'auto_upgrade_plugin' or 'auto_upgrade_theme' 'auto_update_plugin' and 'auto_update_theme' filters to enable auto-updates of one, or many plugins/themes note: Plugin/Theme updates will not be enabled by default in WordPress 3.7
  3. By default, Core Auto-Updates will only apply to WordPress Security & nightly releases, that is, from 3.7.0 to 3.7.1, 3.7.1 will not automatically update to 3.8.0 – This can however be changed,  you can simply add define( 'WP_AUTO_UPDATE_CORE', true ); to your wp-config.php file and it’ll happen automatically!

What can I do to help?

Please test it out and report any bugs you find! Triggering automatic updates can be a little bit difficult since it currently relies upon a twice daily cron job, so the easiest way is to just create a new nightly install and visit the site once a day to cause the cron to be initiated, If you’re game to run it on a production site, please be aware that WordPress will go into Maintenance mode during the upgrade.

You can also head over to Trac and check out report/48, which is a temporary 3.7 report containing anything related to automatic updates and Language packs (more on that in a few days)

#3-7, #updates