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.


23 responses to “Proposal to Auto-Update Old Versions of WordPress to 4.7 Sparks Heated Debate”

  1. Completely agree with the statement of David Anderson. Simply put, it’s not the call for to make. Existing installs should be left alone by anyone except for the site administrator and/or it’s hosting provider, without any explicit consent. Yes, unmaintained WordPress installations are bad. But interfering in this manner is far worse.

      • The entire auto-update infrastructure is a standing security risk as it allows a third party to inherently install or upgrade software on your system. The risk isn’t limited to the fact WordPress has the capability to roll out a major upgrade to what could be considered an abandonware website.

  2. I hope this happens.

    I understand the resistance, but this attitude is what will kill WordPress in the long run. The resistance to updating WordPress, updating PHP versions, Gutenberg, etc. is a problem.

    I get it, WordPress is 15 years old and not exactly a community of early adopters, but we have to be smart enough to see around corners and understand what we need to do to continue moving forward. Believe me, WordPress failing to progress and move forward will cause much more disruption in the long run.

    The status quo is comfortable, but stasis always is. It’s also deadly in the long run.

  3. I’m a proponent for security and the principle behind this action (one of my comments is featured in this article) but what I don’t like is the approach and seemingly “forced”-ness of this action. I personally run things on the bleeding edge wherever possible. I also want to highlight I am a big fan of the recent movements the core team (and the rest of WP) have taken and the direction in which WP is going! But this isn’t right.

    I can’t help but feel that this is pathing the way for something else… this definitely lays the foundation for giving WordPress a LOT of power on the internet. There was a thread where it was mentioned that plugin and theme auto-updates could follow this… really?!

    The distinction between .com and .org needs to be managed here. Just because WP can, doesn’t mean WP should.

    Not doing this in no way kills WordPress, as suggested by “PP”. Why is it WP’s fault if a user remains on an old version? Why is it WP’s vault if a user uses an old PHP version? What next… they define our themes for us? Why can the rest of the internet/world manage this in a more suitable manner, but WP has to take this approach? How is WP going to manage the support for all of the sites/user workflows they break?

    This should 100% be opt-in, NOT opt-out. Simple. Implied consent is not consent.

  4. This will make it worse in the community.

    Admins will get lazy, why bother to do anything when will do it for you?, Matt Mullenweg, The plugins authors of all my sites, the theme authors……….STAY OUT OF MY SERVER.

    The hundreds or even thousands of people around the world that help fix hacked sites….might lose some jobs if will do it automatically.

    Part of my maintenance packages, I provide updating.

    Updates can break things from time to time. What if I am on vacation? What if I am at a conference somewhere in a different continent without access to wifi/internet, to fix things.

      • @Ryan – This won’t just apply to the current situation. It does now, but it’s simply pathing the way for a future process. This will come forwards to all releases and those won’t come with the same warning window/grace period. It has already been stated in the comments by multiple core contributors!! Not only that, but they’re pushing for it to be implemented on plugins and themes in the future… you can’t think that this is ideal surely?

      • @Ryan What if I am on vacation from September 1-10 and an update comes on September 3. I won’t be doing the updates during vacation. But for a week any of my sites could be broken. Hence I don’t want auto-updates. I want to do manual updates. That way if there are issues with the update, I can fix them, instead of (in the example above) wait a week.

  5. Who wants to have a website should take care of it. Point! If I don’t update my PC for 6+ years, don’t be surprised if the apps/software don’t work anymore. I do not understand the whole discussion…

    • Basically you are right. Meaning as in, it’s the responsibility of the owner so it should be his or her choice to run the updates or not… and so suffer the consequences of that choice. If that means EOL so it shall be.

      Updates should never be forced other than direct stakeholders in the process (hosting partner e.g.) isn’t one in my opinion. This is where the discussion seems to be about.

      To me a non stakeholder interfering with your installation without an explicit opt-in consent is just wrong.

  6. I wholeheartedly understand and support Dunn’s proposal to auto-update the older versions of WordPress since legacy versions could have serious security issues which could prove damaging to the entire WordPress ecosystem.

    In addition, if a site gets attacked or hacked simply because of a backdoor entry through outdated WordPress installs, it gives WordPress for no fault of the developers.

  7. should not force to upgrade to the newer versions. it is upto the admin of the WordPress website whether to upgrade or not.

    I totally agree with this

    “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.”

  8. Considering what goes on with the user’s privacy and other rights that EU and some other parts of the world try to protect (with more or less success), I think that auto-updates (even minor version) are currently completely illegal, and are done using implied consent, which is known to be illegal when gathering user data or doing something on users behalf.

    If core team working on updates need something to do, I would suggest making changes to WP installation to ask the user to agree to the updates (select between minor and major), store that in the database and have the option to change it in the plugin settings. That can be considered legal explicit consent to do something on the user’s behalf.

    Sending major updates to outdated WordPress websites is totally unacceptable for so many reasons, and in most cases I am sure, it will end up on the broken website. As few people pointed out already, outdated websites are outdated for a reason: the owner doesn’t care anymore or is stuck with the outdated plugin/theme/customization that will break with the new WP version.

    And the fact that can do this doesn’t give anyone right to do it, we all should be scared with the implications, especially, since updates are even now done without any consent.

  9. What is the problem that we’re trying to solve?

    It’s a PITA to support all old versions of WP. Ok, I get it. So why not simply drop the support, period? Microsoft does that, PHP does that… and so should WordPress.

    I have Windows XP (SP 1) with Netscape Navigator and guess what… I got hacked. My problem.

    At SatelliteWP, we do maintenance so we understand exactly the “why” of this. It saddens us to see people not take care of their site. But, at the end of the day, we can’t save people that don’t want to be saved. We simply have to move on.

    Here is the thing that bothers me the most:

    How will you update these old versions to the latest version as the process does not exist now ?

    The answer: adding a “new feature” in a security release. Exactly what was done in WordPress 4.9.6 and explained in the article: Warning: WordPress 4.9.6 Really is a Major Update.

    My take: keep developing this great software and provide patch. Let people and web hosts manage the “when”.

  10. I don’t think this is an all or nothing issue. The beauty of WordPress is that it allows a great degree of freedom in how people build websites using their platform. However, freedom is and can never be unlimited.

    Automattic is not making everyone adopt blocks and the major changes of version 5.0 yet. They are gradually making, what I feel are reasonable requirements on people who use their platform and that is to make sure their websites are compatible with a version that came out in 2016. I think this is a good balance.

    • There is a difference between and of which I feel not everyone grasps.

      Automattic is not making everyone adopt blocks and the major changes of version 5.0 yet.

      …on people who use their platform…. may be owned by Automattic, .org isn’t. Although they contribute a lot to .org as well, the software on .org is open source(GPL).

      And because of this software being open source no one other than the site owner (or server owner) of that particular installation (configuration) is supposed to make this kind of changes to it.

      One of the freedoms is to adapt it and make into whatever you like. If you want to change the core, (although not wise) go ahead. I’ve actually seen developers do this, changing the core. Wise? No! In theirright? Yes! That’s the whole philosophy behind the idea of open source, opposed to proprietary software.

      I think no one is questioning the intention behind the idea of building a safer internet, but stay on track who is the one that makes the shots on existing installations.


Subscribe Via Email

Enter your email address to subscribe to this blog and receive notifications of new posts by email.

%d bloggers like this: