Automatic Updates in WordPress

This week, the topic of automatic updates in WordPress came up. Here’s a bit of a guide on how it all works, how to disable them, and so forth.

Automatic Updates?

First, “automatic” is a very problematic term given the history, so let’s define terms a bit.

In The Beginning…

When WordPress first came out, whenever you wanted to update to the next version of things, you had to manually download and install the update. This changed in WordPress 2.5 (March 2008) with, what was often referred to as, “automatic updates”. This post isn’t talking about these “one-click updates“.

The Humanless Era Begins For Minor Updates & Developers

The era of “background updates“, those updates that are possible without human interaction, began in WordPress 3.7.

WordPress 3.7 (October 2013) was billed as a very developer-heavy release. There weren’t really any splashy features—background updates, improved password meter, improved search. Under the hood, this release laid the groundwork for a ton of stuff.

The most visible impact of 3.7, at the time, in regards to updates was that now WordPress could update itself in the background and would start doing so for maintenance releases (e.g. 3.7 to 3.7.1 to 3.7.2).

In addition to the ability to update Core itself, the underlying guts for themes or plugins to background update were in place. There was no user interface for this—had to add a bit of code to activate.

The guts that allowed for plugin background updates also allowed for “background security updates” or “forced updates”. More on this in a bit.

Humanless Reaches The Masses

By WordPress 5.6 (December 2020), the underlying guts had seen various improvements over the years and now the ability to modify background updates expanded to everyone.

WordPress 5.6 included the user interface to enable site owners to indicate individual plugins could background update or even WordPress itself with major updates.

Generally speaking, this was adding UI to the existing framework, but the actual process is the same.

Summary of Terms

In short, “automatic” updates could refer a few different things:

  • One-Click Updates, with the wp-admin ability to upgrade, added in WP 2.5.
  • Background Updates added in WP 3.7 with expanded UI added in 5.6.
  • Forced Updates also added in 3.7 with no UI.

A Special Note About Forced Updates

What Is A Forced Update?

Forced Updates aren’t really a different thing than Background Updates. When a site checks for updates, it informs the API of the current version, the version of WordPress, and the version of PHP running on the site. The API then responds with what upgrade that site is being offered. If you’re running a modern version of WP and PHP, usually, it is the latest stable version of the plugin.

If you’re running an older version of PHP or WordPress that is older than the minimum supported version for the latest version of the plugin, it won’t offer you an upgrade at all.

For a Forced Update, the API responds a little differently. First, if you’re on an older version, it will only offer you the immediate patch for the security issue. For example, if Cool Plugin 2.0 is the latest version and you’re running Cool Plugin 1.5, the API will see that and respond with Cool Plugin 1.5.1 for your update (as opposed to 2.0) and mark it as a forced update (or autoupdate in the response). The overall mechanism is the same for regular upgrade offerings and a forced upgrade offering.

How Does An Update Become Forced?

Jetpack is one of the most installed plugin in the WordPress ecosystem and, as such, anytime there is a potential security issue discovered, it’s a Big Deal™ by way of the number of sites potentially impacted. We take that responsibility seriously, so we’ve had three “Forced Updates” since this became possible in 2013.

The process has been we discover an issue. This is often from our internal security folks trying to find issues or from a responsible person disclosing to us via our HackerOne bounty program (yes, we pay people who find security issues and report them directly to us).

Once we validate the proof of concept and confirm there is an issue, we determine the severity and the scope of the issue. How bad is it and how many people could it impact? At the same time, we determine the smallest possible solution to mitigate the issue. Generally, this is not the time to do a whole-hog refactor or something.

With all that information in place, if we think the issue is potentially serious, we will contact the WordPress Plugins Team. These folks, none of whom work for Automattic, can help advise us on next steps.

If they concur the issue is serious, they advise on if the fix should be backported to older versions or not. In such a case, there are some very important and firm guidelines:

  • To the extent feasible, we need to fix everyone possible. If the problem exists in five versions (e.g. 1.1, 1.2, 1.3, 1.4, 1.5), then we should provide patched versions for each of those versions.
  • The updated versions can only contain the smallest change possible to mitigate the issue. This is not a time to fix other bugs, add features, or anything. It is exclusively to fix the issue discussed.

After that, we go back and fix everything and prepare releases.

When everything is ready, we check-in the new versions to the plugins repo and the WordPress Meta Team updates the API to give the modified response for these versions.

Disclaimer: I suppose I could be considered on the Meta team since I help maintain parts of WordPress.org. I don’t have the authorization nor the access rights to modify the API.

How To Control These Updates?

One-Click Updates

If you want to really lock down your site and disallow, basically, everything, you can do that with a single line in your wp-config.php file:

define( 'DISALLOW_FILE_MODS', true );

This will disable all updates—background, one-click, or manual. You will not be able to install new plugins or themes. It’ll actually disable the Upgrader completely to the point that you won’t be able to see pending upgrades.

I do not suggest using this unless you have extremely specific needs and have the resources to ensure your site is up to date manually.

A common use of this, though, is to mark your production site with DISALLOW_FILE_MODS while running a staging site without it. You can make changes to the staging site, then deploy them to production when you’re ready.

Background Updates

There are a few different ways to control Background Updates.

Via UI

Via the wp-admin user interface, you can control WordPress Core updates via the Dashboard->Updates page.

For plugins, visit Plugins->Installed Plugins and select “Enable auto-updates” option for each individual plugin you’d like to background update.

For themes, visit Appearance->Themes, then choose “Theme Details” for each theme you’d like to background update. On the details page that opens, you’ll see an option to enable updates under the title and author.

The UI options have no effect on Forced Updates.

The UI options have no effect on Forced Updates. You can think of this as replacing the need for One-Click Updates.

Via Code

The DISALLOW_FILE_MODS constant mentioned above will still work, but you have a lot more granular control too.

For the sake of being complete, if your server’s user does not have permission to access the file system or you’re on a version-controlled setup, background updates won’t work. For Core updates, you’ll get an e-mail about them.

SegmentMethodPossible ValuesNotes
AllConstant: AUTOMATIC_UPDATER_DISABLEDbooleanFalse also disables update notification e-mails for Core.
AllFilter:
automatic_updater_disabled
boolean

Default: Value of AUTOMATIC_UPDATER_DISABLED
False will disable notifications too. Overrides the constant above. The below values do not override this. This would still allow UI updates without allowing any background updates. See below the table, though, for an alternative.
CoreConstant: WP_AUTO_UPDATE_COREfalse (bool) – No background updates for Core
minor – Only security/maintenance updates for Core
true (bool) or beta, rc, development, branch-development – All updates allowed.
Filters can still override this behavior.
CoreFilter: allow_dev_auto_core_updatesboolean

Default: False unless WP_AUTO_UPDATE_CORE is set to allow all updates.
If the site is currently on a dev version (alpha/beta), should it background update Core.

3.7-alpha-2500->3.7-alpha-25678->3.7-beta1, etc.
CoreFilter:
allow_minor_auto_core_updates
boolean

Default: True unless WP_AUTO_UPDATE_CORE is false.
3.7.0->3.7.1->3.7.2
CoreFilter:
allow_major_auto_core_updates
boolean

Default: False, unless WP_AUTO_UPDATE is set to allow all updates.
3.7.0->3.8.0->3.9.1
ThemesFilter:
themes_auto_updates_enabled
boolean

Default: Generally true, unless the automatic_updater_disabled constant/filter are false.
This is more the themes system being enabled. This doesn’t mean it will upgrade individual plugins. This can be overridden by Forced Updates.
PluginsFilter:
plugins_auto_updates_enabled
boolean

Default: Default: Generally true, unless the automatic_updater_disabled constant/filter are false.
This is more the plugins system being enabled. This doesn’t mean it will upgrade individual plugins. This can be overridden by Forced Updates.
Plugins/ThemesFilters against the auto_update_themes and auto_update_plugins optionsIndividual plugin and theme background update settings are stored in these options. If you wanted a confusing experience, you could filter these options. I wouldn’t personally.
This can be overridden by Forced Updates.
———–Important Note!Everything above allowing a background update can be overridden by the the API to disable a background update.I’m not sure how/if this has been used, but it is possible. I would guess this is a way that WordPress.org can throttle the rate of downloads by marking something as disable_autoupdate for a percentage of sites. Just a guess.
AllFilters:
auto_update_core
auto_update_plugin
auto_update_theme
auto_update_translation
booleanThese filters also pass $item which is the upgrade object response from the API. You can use these filters to more selectively control updates via code. Want to allow only plugins whose slug begins with a, this is your filter. Or a more realistic setup would be to allow background updates only from a select allow list.

As you can see, there is a lot of flexibility for site owners who wish to have a very specific background update solution. While Forced Updates are given a lot of preference, you can still disable them via the auto_update_{$type} filters.

One idea, if you’re concerned about an autoupdate, but want to be aware, is to hook into those filters and if $item->autoupdate is true, send you an e-mail, before returning false. That way you’d know you’re missing the update but you can completely control when your site’s code is modified.

When do these updates happen?

Generally, every 12 hours. There are wp_update_plugins, wp_version_check and wp_update_themes cron events that are set to run twice daily. There’s not a set time—on every page load, WordPress checks to see if the check is scheduled. If it isn’t, it schedules it for immediately and then every 12 hours thereafter.

One more note about Jetpack

While I’m here, before Core added the UI for background updates, Jetpack had one that was accessible via WordPress.com for connected sites. For while there, this system did not use the same filters as above. With WordPress 5.6 bring a renewed focus to background updates, we modified our system to use the same options and filters as Core’s. The above should all still work the same for any autoupdates selected via the WordPress.com interface for connected Jetpack sites.

I hope this help explains things a bit more with a bit more specificity than a lot of the conversations around “automatic updates” .

Adoption by Stealth

Colin Walker mentioned my earlier piece on the Open Web and tied back to an earlier piece on “Adoption by Stealth“.

In the end, I think technology adoption by stealth is the only way to make an idea dominant. With the open web (I use that term intentionally since “Indie Web” is much more of a community I don’t know well), people weren’t excited to adopt http. They were excited about websites. Older open web technologies, like trackbacks and pingbacks, weren’t successful because of the technology, per se, but instead of the ease in which regular end users could use it to their end.

In adoption in WordPress Core or Jetpack, the technology would need to not seem like technology, but only a feature. “Automatically notify sites you’re linking to about your post” is the feature, which exists in WordPress already through now-antiquated tech, so for webmentions to have a life in Core, they would need to augment that feature. “WordPress now features rich notifications”, for example.

I do fear that the dependence on microformats will be a detriment to widescale adoption, at least via the WordPress vector. For better or worse, markup is theme territory. Genesis already adopted Schema.org, mainly due to the SEO benefits given schema.org is Google-backed. _s has been hesitant to pick sides. If either method is going to get traction, building it into a default theme and, possibly, a theme_support declaration would be the way it happens. If that happened, then other theme authors may opt to build support and the snowball would begin to roll.

I don’t know the webmention spec at all so ignore me if this is ignorant. Instead of webmentions relying so much on microformats and scraping, what if it could use either microformats or a reference to an API. WordPress now has a REST API, so what if the webmention allowed an alternative data location for structured data? When available, if the receiving site could verify the mention and then pull from the API, then it would likely be more reliable and not markup dependent, thus more likely that Jetpack or WordPress core, etc could add support for it.

In short and to the point, for something like this to gain traction, it would need to just work in a way that reduces fragility and developer error.

The Open Web

The most powerful aspect of the Internet is the open web. From the very beginning, there has been a conflict with on one side walled gardens and closed networks with open standards and interoperability on the other.

My first experience with an online world was dial-up into AOL and exploring their internal experiences. Only rarely did I click the button to go into the unknown and wild internet. AOL controlled everything within their experiences.

For awhile, we had a golden age of blogging. People would comment on each other’s blogs. If you wanted to write a novel in response to someone, you did–on your site. When you did, a trackback or, later on, a pingback would automatically alert the original post and a little ad-hoc social network between two sites was created.

Feed readers provided a place for people to aggregate their blogging experience. From there, easy publishing and content aggregation fell in love and gave birth to social networks. This path wasn’t intended or necessarily in mind when Facebook or Twitter started, but nevertheless.

Advertisements

In all of this, having your home belong to you is important. A business whose online presence is their social media page is placing all of their eggs in one basket hoping that it isn’t in the platform’s business interests to change the system to your detriment. Even on site-builder platforms, which do give you your own website, do not give you any means to take that content with you whenever their platform or your needs change.

Having a home that you control is important, but now you have to maintain your main online presence and your Facebook page and your Instagram account and your Twitter feed and maybe blog on Medium too and so on and so on. The open web is being lost.

I want to see the WordPress ecosystem do more toward building up the new open web. Whether it is directly in Core or experimented with via Jetpack, there is a large user base who would benefit by modern and advanced open web technologies. There is a solid group of folks who believe in an open and independent web who have helped create standards and systems to interoperate, but it’s hard to gain adoption without the baking of something with the heft of Facebook or Twitter.

micro.blog is what turned me on to the modern standards. Micro.blog aims to be, more or less, an open Twitter. You can pay them to run your microblog or it’ll pull in your WordPress site (a special site just for your microblog or, in my case, just a category). Reading more about the tech behind it, such as webmentions–which I had heard of before but never took the time to read up on it–gave me a new excitement for the future of the web that I haven’t had in awhile.

What can we do to help continue this excitement? WordPress has considerable pull. When it supports something, it gets noticed. If we can figure out how many make webmentions work well, would Facebook or Twitter begin to support them in some way?

To this end, I would like to dedicate some of my free time toward exploring this more. Specifically:

  1. Update the PuSHPress plugin. It is currently on WP.com and available for self-hosted sites using an older version of the now-called WebSub W3C candidate recommendation. Automattic already has that much and it gives me a good place to start.
  2. Find small places in Jetpack that we can work toward supporting these efforts in a frictionless way. One example is storing Publicize URLs locally so plugins like Syndicated Links can use that information. In this case, with a Facebook or Twitter link stored in Syndicated Links, a service like brid.gy can better get webmentions sent to your site. It isn’t required, since they’ll likely have links back to your site already, but again, small things to close the gap.
  3. Determine what could webmentions support in WordPress naively look like. What makes sense to be added to Core and how to make it expandable in a way that doesn’t tie our hands down the road. (Post formats, anyone? Pretty soon after they launched, the issue of not enough structure on how they worked ended up resulting in a pretty random experience. 3.6 tried to fix it, but, in many respects, it was too late.)
  4. More broadly, think through how else we can positively include ripe standards. Like a recent Jetpack fix to make our recipe shortcode compatible with Schema.org.

The hard part is keeping the end user in mind. I’ve recently setup a few pieces of indieweb concepts on my site, but it isn’t something that I would expect my wife or a random end user to do. It isn’t obvious why one would do this, it is a bit clunky, the workflows aren’t straight-forward yet. I think they can get there.

The dream isn’t to return to the past before social media, but help make social media part of the web in an organic way. For this post, you can like it or comment it on via this site, WordPress.com, Twitter, or Facebook, but all of the comments will appear here using Webmentions. The closed gardens will still exist, but it’ll make it easier for people to reach out between them.

I know I’m very late to the party after a tiny bit of research I’ve done so far. I’ve seen the same names pop up all over the place. These folks have worked very hard to get where it is now and I’m sure they know of dozens of roadblocks I couldn’t imagine today. But, I hope that, even if I’m late, there’s still room at the table.

How about you? What would you like to see move forward in the evolving open web?

Stats in the Open

John James Jacoby had the idea for an open stats platform. A Google Analytics that was open for anyone to see any site’s stats.

Experimenting with opening things up and transparency is interesting to me, so after he floated the idea and then tweeted this:

https://twitter.com/JJJ/status/792096310862184452

What the hell, let’s give it a go. I don’t have a ton of traffic (and most of it is still about the Genesis eNews Extended plugin I wrote four years ago), so it might not be the most interesting data to anyone else.

That said, browse around the site some, then check out my stats via Flox common stats dashboard.

Initially, the tracker also counted admin page views, but I’m uneasy about that so I restricted it to front-end and login page tracking. I might change my opinion or include only content editing admin pages (while leaving true administrative pages hidden).

What do y’all think of this type of transparency?

Let’s Encrypt!

Traditionally, getting an SSL certificate isn’t easy or cheap. SSL, or more accurately, SSL’s successor, TLS, is the underlying technology that encrypts web traffic. You’ve seen this as the https scheme on a URL and the padlock in your browser to let you know you’re securely browsing a website.

To set this up for your website, you used to (and still do on some hosts) need a dedicated IP address for the website, a fair amount of money, and jump through of hoops with the certificate authority (CA) issuing the certificate. There was, also, a lot of back and forth needing a certificate signing request (CSR) to send to the CA, then installing the real certificate when it was issued.

Let’s Encrypt aims to change that. The goal is a fully automated process where someone could type in a command on a server, wait a few seconds, and have a certificate issued and installed on their system.

It’s been in development for a while now and I’m proud to say that my employer, Automattic, is a Silver sponsor of the project. Yesterday, the opened for a public beta period. So, of course, I gave it a spin.

This site has had a certificate for some time, but I never pulled the trigger on enabling HTTPS on any of my other domains. I opted to try this on, perhaps, my greatest domain— kraft.beer.

Let’s jump in and get some HTTPS going. Read More