Proposal to Auto-Update Old Versions of WordPress to 4.7 Sparks Heated Debate

WordPress contributors, developers, and community members are currently debating a proposal to would implement a new policy regarding security support for older versions. The discussion began last week when security team lead Jake Spurlock asked for feedback on different approaches to backporting security fixes to older versions. Following up on this discussion, Ian Dunn, a full-time contributor to WordPress core, sponsored by Automattic, has published a proposal for moving forward with a new policy:

Support the latest 6 versions, and auto-update unsupported sites to the oldest supported version.

That would mean that the currently supported versions would be 4.7 – 5.2, and the 3.7 – 4.6 branches would eventually be auto-updated to 4.7.

In practice, that’d provide roughly 2 years of support for each branch, and roughly 10% of current sites would eventually be auto-updated to 4.7. Once 5.3 is released, the oldest supported version would be become 4.8.

Dunn outlined a detailed plan for implementing the new policy that involves testing a small subset of sites to identify problems before gradually updating older sites from one major version to the next (not all at once). Site administrators would be notified at least 30 days prior to the automatic updates with emails and notices in the admin that would also offer the opportunity to opt out.

The proposal has received dozens of comments, with some contributors in support, some in favor of modifications to the rollout, and others who are unequivocally opposed to the idea of auto-updating old sites to major versions.

One of the prevailing concerns is that many admins will not receive any notice due to non-functioning email addresses or not logging into their admin dashboards frequently enough. Opponents also contend that even though there are fallbacks for sites that fail to upgrade, some sites may be broken in a way that WordPress cannot detect, due to problems with plugins or themes.

“A back-end notice will not even begin to make up for the lack of reliable email communication,” Glenn Messersmith said. “There are tons of site owners who never venture into the back-end once their site has been developed. These are the very people who will not get email notifications either because the email address is that of some long gone developer.

“There is no way any sort of error detection can act as a safety net for those who never saw any notifications. There are all sorts of ways that a site owner might consider their site to be ‘broken’ which an update script could not possibly detect.”

In response to concerns about abandoned sites breaking or administrators relying heavily on a plugin that has been abandoned, Dunn agreed that these types of situations may be unavoidable under the current proposal.

“I can definitely sympathize with that situation, but we have to draw the line somewhere,” Dunn said. “We don’t have unlimited resources, and the current policy has damaging effects for the entire WordPress ecosystem.

“In reality, choices are never between a purely good thing and a purely bad thing; they’re always between competing tradeoffs.

“I definitely agree that it’s bad if a small number of site owner have to do extra work to upgrade their site, but in the grand scheme of things, that’s much, much better than having our security team be hindered by an extremely onerous support policy.”

Proposal Author Claims “Nobody Would be Forced to Update;” Opponents Argue that Requiring Users to Opt Out is Not Consent

In addition to the problem of possibly breaking sites, those opposed to the proposal are not on board with WordPress forcing an update without getting explicit consent from site administrators. Providing users a way to opt into automatic updates for major core releases is one of the nine projects that Matt Mullenweg had identified for working on in 2019. However, the plan for this proposal is more aggressive in that it would require site owners on the 3.7 – 4.6 branches to opt out if they do not want to be incrementally auto-updated to 4.7.

“They still retain agency no matter what, nobody would be forced to update, everybody retains control over their site and can opt-out if they want to,” Dunn said. “Something being on by default is very different from forcing somebody to do something. We would make it very easy to opt out — just install a plugin, no config required — and the instructions for opting out would be included in every email and admin notice.”

Dunn further clarified in a comment regarding who would receive these updates:

Nobody would be forced, it would instead be an opt-out process. If someone has already disabled auto-updates to major versions, that would be respected and their site would not be updated.

If someone clicked the opt-out link in the email, or if they clicked the opt-out button in the admin notice, then the updates would also be disabled.

The only people who would receive the updates are the ones who:

1) Want the update
2) Don’t care
3) Have abandoned their sites or email accounts

Several participants in the discussion asked why the process of getting these sites on 4.7 cannot be opt-in for consent, instead of forcing the update on those who don’t opt out. No matter how convenient the opt-out mechanism is, having one in place doesn’t constitute consent. Many site owners who will be forced into this process thought they would be safe in opting for maintenance and security updates and leaving their sites to perform “updates while you sleep,” as the 3.7 release post described the feature.

“Insecure sites are bad, but arguably, retrospectively enlarging the power granted to oneself by this mechanism is worse,” UpdraftPlus creator David Anderson said. “Potentially it could damage trust + reputation more than insecurity. I’d argue that huge dashboard ugly, irremovable notices on older versions warning of upcoming abandonment + the need to update would be better. Let the site owner take responsibility. Don’t play nanny, abuse trust, break sites and then write blog posts about how it was necessary collateral damage. Nobody who wakes up to a broken site will be happy with that.”

Andrew Nacin, WordPress 3.7 release lead and co-author of WordPress’ automatic background updates feature, encouraged those behind the proposal to clarify that WordPress only supports the latest major version and has never officially supported older versions.

“It takes a lot of work, for sure, to backport,” Nacin said. “But we should still stick to our north star, which is that WordPress is backwards compatible from version to version, that WordPress users shouldn’t need to worry about what version they are running, and that we should just keep sites up to date if we are able.”

Nacin offered more context on the original strategy for introducing automatic updates, which included gradually moving to having major releases as auto updates so all sites would eventually be on the latest version:

First, when we first released automatic background updates, we thought that our next big push would be to get to major release auto updates in the next few years. In practice, we can do this at any time, and, indeed, 3.7 supported this as a flag. But the idea was we would invest energy in sandboxing, whitescreen protection, improving our rollback functionality, etc., so our success rate was as high for major versions as it was for minor versions. (The failure rate scales somewhat linearly with the number of files that need to be copied over, and also gets more complex when files need to be added, rather than just changed.) Once we did this, we’d simply start updating all sites to the latest version and stop backporting. Obviously we still haven’t gotten here.

He commented that overall the proposal is “a great plan” but emphasized the benefits of communicating to users that it is safe to update and that WordPress only intends to support the latest version.

Most participants in the discussion are in favor of the security team discontinuing backporting fixes to older versions of WordPress. The question that remains unanswered for opponents is why is it WordPress’ responsibility to force older sites to update.

“I don’t think it should be WordPress’ decision to update sites that they don’t manage to major/breaking versions, but I think maintaining those branches should be stopped,” Will Stocks said. “You (WordPress) don’t own the infrastructure or business processes, or understand the support in place to manage those sites. There is also a reason those sites are still on that version today and have not upgraded past.”

There are other approaches that can still draw a line to respect the security team’s limited resources without forcing any non-consensual updates to major versions. Rachel Cherry, director of WPCampus, commented on the proposal, strongly urging WordPress to establish consent before updating these sites:

We are getting into the weeds of whether or not forced updates will cause tech issues and missing the real problem altogether.

We are discussing force updating people’s software when they have not given consent.

And for what end? What is the real problem here? Because we don’t want to worry about updating old versions?

There are other ways to solve this problem.

We can make a clear policy regarding EOL support for releases.

We can add a setting to core that lets the user choose whether or not they want auto updates and going forward that is the decision maker. Then we have consent.

We can work on education and communication regarding updates.

We can email people that their site is outdated and insecure and they should update ASAP, along with links to education and best practices. If they still need help, encourage them to reach out to a professional.

We can fix this problem for going forward, but we do not have implied retroactive consent just because we never put a permission mechanism in place.

If someone didn’t update their site, they did so for a reason. Or indifference. Either way, we have no right to go in like this and modify people’s websites.

Participants in the discussion are still wrestling with the potential implications of the proposed policy change. Minor updates have proven to be very reliable as auto-updates. Dunn reported that the 3.7.29 auto-update had only one failure that had to be rolled back to 3.7.28. Using the auto update system to push major updates to sites as old as these has not yet been thoroughly tested.

“Whether or not we do auto-update the 3.7 -> 5.x releases, I fully support making it clear that this is something we expect to start doing for the future (5.x -> x.x+),” Jeremy Felt commented on the proposal. “The work on testing infrastructure and code to support this should absolutely be done either way.” Felt also said he appreciated the staggered rollout scheduling for the proposed releases as well as the plan to provide an officially supported plugin for disabling auto-updates.

Discussion is still open on the proposal, but so far there seems to be a fundamental disagreement among participants about whether WordPress has the right to force major version updates without explicit consent, even if it is with the intention of saving site owners from potentially getting hacked.

“One thing is for sure, it appears to be a majority concern so far, while many of us are fond of these noble intentions, I’m just not so sure being the benevolent overlord of the Internet is a good image for WP moving forward,” plugin developer Philip Ingram said.