Core Team Explores Idea to Automatically Upgrade Sites Running WordPress 3.7 to 3.8

WordPress 3.7 ‘Basie’ was released on October 24, 2013 and introduced automatic updates for minor releases to the masses. Although it’s not labeled as such, WordPress 3.7 has effectively acted as a LTS version or Long-term support. Security updates and crucial bug fixes have been ported back to previous branches up to 3.7.

In this week’s WordPress developer chat, Aaron Jorbin, WordPress core developer, asked if it’s time to stop back porting fixes to 3.7-4.0 and instead, update those sites directly to 4.1.

According to version statistics on, 0.4% of tracked sites are using WordPress 3.7. “I would like to see a published proposal outlining reasons, usage data, and any tradeoffs/considerations and leave a bit of time for feedback before definitely doing this,” Joe McGill, Core contributor said.

“It’s unclear to me what are the things that must happen and what are the things that should happen before we take this step.”

Developers noted that WordPress automatically updates minor versions and that if protections are not built-in to automatically upgrading major versions, it could cause users to lose trust in the system.

“We need to make sure all users with outdated installs get warned one way or the other. Then if they decide to turn updates off…,” Andrew Ozz, Core developer said.

After further discussion, the team agreed that upgrading sites from 3.7 to 3.8 would be a good stepping stone towards getting those sites up to 4.1. “It can also be done in the API so that we only do a small percentage at first and then stop and analyze and then increase the percentage,” Jorbin said.

A proposal will be crafted by members of the core team and published on the Make WordPress Core site for further discussion.


27 responses to “Core Team Explores Idea to Automatically Upgrade Sites Running WordPress 3.7 to 3.8”

  1. This Big Brother attitude bothers me. I don’t want anyone force updating my sites. No one has the right to change my website – warnings or not. I fired WPEngine for altering my database without my consent and, the Core Team certainly doesn’t have the right to change anyone’s site. Just advertise that support for those versions will end.

    • Hear, hear. Ending support for a major version that’s quite a number of years old may be understandable, though there should always be at least one version that’s properly LTS and gets support for a minimum of 5 years (which is far from the case even for 3.7 now), and preferably longer, even if some others released after it do not. But in that case there should be plenty of advance warning, an end-of-support timetable published a long time, I’d say years, in advance and obvious notifications when the date approaches, yet the decision to update or not must remain solely with the webmasters. Don’t go the way of Microsoft people!

  2. I am completely against anyone touching my site. I disabled automatic updates on ALL my sites.

    What if I am doing some custom coding on one of the files, working for hours then all of a sudden an update comes and either screws my site or just gets rid of the changes with the updated files?

    Before I update I test the update on a private domain that has WordPress on it, I use it to test things, install themes and plugins BEFORE they go up onto a live site.

    I have this big issue with allowing third parties or even connecting to their parties, like Akismet and JetPack. Nothing against A & J, just not my thing.

    Also, if websites are updated automatically then many site owners are going to get lazy. I like doing the polishing, fixing and so forth on all my sites.

    • What if I am doing some custom coding on one of the files, working for hours then all of a sudden an update comes and either screws my site or just gets rid of the changes with the updated files?

      Any custom coding should be done outside of WordPress core files. Automatic updates only affect core files that should never be edited.

      • In theory, this is right. However, in practice, it may happen that we need to hack WordPress core files to satisfy an extravagant, exceptional requirement, which was never considered in core, that no plug-in will handle, and that it’s so exceptional that it makes no sense asking the WP community to add that feature in core (more, if it will take months to do, and we need to satisfy that requirement immediately). It may be wrong, but there may be no way around it.

        I fully agree that it should be our decision to automatically upgrade our WordPress installations or not. The WordPress ecosystem is so big, that you can’t really expect a one-size-fits-all kind of solution. The ocasional outliers must be allowed too.

    • If you’re updating core files it sounds like you don’t want / are not expecting incoming updates from core anyway so you could just remove the files attached to updating core. I’m an advocate for keeping things up to date and core files being untouched but if you’re not, just remove that functionality.

  3. One of the gotcha’s that needs to be solved is the change in WP 3.9, where some hosts use the mysqli extension for database access.
    If there are plugins that directly use mysql functions, and not $wpdb, then they will stop working.

    If this proposal is about upgrading Core, but not plugins (which sounds even more impossible), this can be a big problem for some sites. Especially sites that are unmonitored, and haven’t seen a login in a few years, they will just break and nobody knows how to fix them.

  4. Last month we were hired to bring a website from 2011 up to date with current version of WP.

    The site was running WP 3.8 (current 4.8.1) and WPML 2.3.4 (current 3.7.1).

    Think it was possible to simply update the lot?

    Of course not! Why else would they hire someone to do it for them?

    The ONLY way to update a site like that is by using incremental updates.

    Is Jorbin planning on doing these updates incremental?
    Didn’t think so!

    • 3.7.x to 3.8.x is actually an incremental update, as opposed to 3.7.x to 4.1.x, for example.

      I definitely share the concerns though. Currently we tell people on support forums that automatic updates are relatively safe and only happen within minor versions. Auto-updating between major branches would cause a lot more breakage and could make people trust the updates less.

      This could be addressed with better communication, we need to make sure all users with outdated installs get warned one way or the other.

  5. I think the core devs should make reasonable attempts to notify owners in advance and then cut to the last major version.

    At the same time notify everyone of a policy/commitment to support only X number of versions and shift the effort/resources to forward-thinking development – REST API, consuming services, static site generation.

    All signs are reading that the headless CMS + static site generation paradigm will rise and displace the baked-in admin + frontend UI/UX model. I for one would be very happy if core devs efforts were focused on future tech not supporting abandoned sites and owners who have backed themselves in a version.

  6. I can understand those who say that they prefer not to be forced to update.

    But on the other hand, I also would like less insecure versions of wordpress and other net / web capable software running.

    Maybe have the “no update” command be something that is not newbie friendly. Maybe a complex command which is slightly different depending on the domain name, so that there isn’t a copy / paste command in the wp-config.php or a single tick in the admin section to disable updates.

    This will at least “proof” that those who stop the updates probably have some skills and maybe even know what they are doing.

  7. I can defiantly understand why they want to auto-update older sites. Safer net and all…

    But, as previously mentioned, I prefer to update my site by myself. To control to update process and monitor the issues/bugs.

    And also, some agencies get payed to update sites for their client. This auto-upgrade can potentially break sites and many client will blame those agencies instead of the auto-update process or bad plugins.

    Updating major version is a process involving backups, staging environments, testing and more… I’m not sure WordPress will do it in core.

  8. +1 to updating them. It’s bordering on insane to backport security fixes to 11 previous versions released up to 4 years ago. That’s not sustainable and takes time that would be better spent on the more recent releases.

    • This is open source software. Nobody gets paid for this. You might not
      agree with every decision this project makes, but you should show gratitude for effort that gets done for you for free.

  9. I have a mixed reaction here, and I suppose it depends on the agreement/expectations (implicit or explicit) that someone building a site – based on WordPress – has when they start.

    I certainly don’t like the idea of code changing under my feet, which might very well break something. (If they ever force auto-update when a site is only a point revision behind… then we’ll have words!) But, I also don’t think there should be a website/CMS out there that isn’t being properly maintained.

    Unfortunately, the reality (in my experience) is that a lot of websites on the ‘Net aren’t being properly maintained. And, that sad state of affairs is primarily due to how websites have been ‘sold’ to end clients for so long. You know…. ‘$995 and you too can be the proud owner of a website.’

    The expectation of ongoing support or expertise needed to keep a CMS or any web-entity actually functioning and even remotely up-to-date with current technology was never part of the deal to begin with.

    I suppose most basic WordPress sites would take updates like this without too much trouble. And, more advanced or custom sites (most likely to break) are also more likely to be maintained.

    In my opinion, there shouldn’t be support for versions beyond a certain reasonable age (and 4 years is crazy gracious!)… but the problem is that it’s hard to just let them sit there out of date as well. I almost wish if they got too far out of date, they’d just auto-shut down…. like a web & user-safety kill-switch or something.

  10. A preferable course of action would be to just stop providing security fixes to version 3.7, even though the infrastructure is in place for these fixes to be distributed.

    This will absolutely result in more old sites getting hacked over time. But between web hosts suspending hacked sites, Google/Bing showing warnings on search results for hacked sites, and Chrome/Firefox showing browser warnings when sites are compromised, I think the external ecosystem is advanced enough at this point that shouldn’t feel like the burden is theirs to bear alone.

    Maybe just make it policy that security fixes are backported 10 minor versions and be done with it.

  11. As a Linux user I take Open Source seriously, not as seriously as Dr. Stallman, but seriously enough never to permit any changes on my machines not authorized by myself — the same goes for websites and this thing, together with the relentless snivelling of change advocates, is the main reason I never used WordPress for new sites after half a decade ago.


Subscribe Via Email

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