Cancel

Jeff Chandler

It’s Time For WordPress to Automatically Update Themes, Plugins, and Core by Default

Over the weekend, the WordPress plugin directory implemented a major change that better reflects how popular a plugin is. The number of total downloads has been replaced with the number of active installs. While the numbers are not exact, they’re close enough to give people insight into usage.

Active Sites
Active Sites

When it comes to reporting WordPress plugin security vulnerabilities, this is a welcome change. The active install numbers give the media a better idea on how many sites are potentially at risk. In addition to knowing the active installs for a given plugin, we can also see a breakdown of which versions are used.

Using Outdated Versions of Plugins

With Jetpack, we see that nearly 40% of sites use the latest version while the other 60% use an older version.

Active Plugin Versions
Active Plugin Versions

Yoast SEO is split down the middle with 50% of sites using the latest version and the other combined 50% using an older version.

YoastSEO Plugin Version Breakdbown
YoastSEO Plugin Version Breakdbown

 

Only a quarter of the sites using Contact Form 7 are using the most recent version, while nearly 75% combined are using an outdated version.

For other plugins, the trend is the same. A majority of sites are using older versions of plugins. For all of the effort that goes into informing users to keep sites up to date as a bare essential security practice, these are sobering statistics.

Time to Auto Update All The Things

While I realize there isn’t always an immediate need to update a plugin unless it’s a security release, it’s a good idea to keep them updated regardless. These statistics indicate that the only way to keep as many sites as possible updated is to forcefully turn on automatic updates for major releases, minor releases, plugins, and themes.

A move like this would likely generate a lot of push back, especially from those who already don’t like WordPress’ current implementation since there’s not an option in the WordPress backend to configure them. However, the numbers indicate that millions of sites are running outdated code by choice which is unacceptable.

Safety First auto Updates
photo credit: Rescue device – (license)

The WordPress development team is in a position to help make the web safer for everyone. If all it takes to get people to support automatic updates for themes, plugins and core, is to add some UI to the WordPress backend to configure them, then so be it. I think it’s a small price to pay to quickly improve the situation and move in the right direction.

While I don’t like having my hand held by software to keep things up to date, it appears as though there is no other choice. Automatic updates to minor releases is a good first step, but it needs to auto update everything because leaving the responsibility up to users is clearly not working.

Category:
Tags: , ,
113

113 responses to “It’s Time For WordPress to Automatically Update Themes, Plugins, and Core by Default”

  3. Over 35% of users of my plugin are using “older versions,” and I’m thinking that’s largely because I botched a release a few years back and my userbase began distrusting updates. But the plugin has been stable for two major versions now w/o any major issues, but I have no idea how to get those users to update. It’s frustrating. For my plugin, I would definitely opt-in to auto-updates.

    Create forum topic from comment
    Reply

  4. This will never be implemented into WordPress. Not all plugin/theme authors respect semver. Even WordPress doesn’t respect it. So, how do you know: v4.1 – is it a security release, or new feature implemented, or new major update that breaks compatibility?

    WordPress prays for compatibility. Auto-updating plugins/themes will definitely break this, so this is a no-go to WP. Allowing auto-updating will also require some huge plugins reviewing efforts.

    Imaging Jetpack or whatever plugin will get hacked (or any comittee’s working machine) – millions of users via auto-update will get malicious code. That will be awful for WordPress community and ecosystem.

    Sorry, but no.

    Create forum topic from comment
    Reply

    • While a possibility, I highly doubt that. It’s happened once before but the keen eyes of developers caught wind of it before it became much of an issue. So what is the alternative to getting people to use updated code on their sites from WordPress core to themes to plugins? We keep educating and educating people and the numbers don’t look good, at least to me.

      Create forum topic from comment
      Reply

      • Strict versioning rules? Better plugins reviewing? There are no easy steps. Well, and educating them more.

        What did WP itself did for educating? Except camps with their much smaller audience comparing to all WP users. Imagine a person with low English level (there are lots of them), installed WP. Where does he get some insights (and which exactly) right after? It’s a situation when new user or developer should search and find information on a topic he is not familiar or keen of yet.

        Create forum topic from comment
        Reply

      • Here in the UK we’ve got the nanny State now, whether we like it or not. We voted for those bozos who think they know better than us, so we have nobody else to blame,

        But please please PLEASE save us from an Auntie WordPress who knows best for us.

        By all means give us a switch to turn on different levels of automatic update, but if we choose not to switch it on, that’s up to us.

        Now I know it means that some will and some won’t, but these things aren’t revolutionary they’re evolutionary, and you need to go softly softly.

        Create forum topic from comment
        Reply

          • Would there be? I find it actually quite difficult to opt-out any theme or plugin updates if my privately published plugin happens to have the same folder name as one published in the WP.org repository. The same as opting out for Gravatar, Google webfonts, browsehappy.com to name a few.

            Create forum topic from comment
            Reply

        • Terry, many folk around the world don’t have the (awful) experience of a nanny state like us Brits have. I totally agree. No to opt outs. Opt ins should be the rule. In other words, if you want to opt in, here you can do this, tick this box. After all, log in to any admin backend and all the red blobs are calls to action. If you can’t be bothered, why should I care? If someone gets hacked as a result, that’s their lookout.

          I was recently asked to take a look at a ‘problem’ a non-customer had with their website. 27 updates outstanding, including a few that I new were security risks. I politely asked them to get their site up-to-date and then I might help. They refused to update anything. I warned them of the consequences. I got a call today from them. help, we’ve been hacked … nuff said.

          Create forum topic from comment
          Reply

      • @Jeff Chandler:
        “It’s happened once before but the keen eyes of developers caught wind of it before it became much of an issue.”

        I don’t agree with this. If you enable automated updates then there is no time for any review. As soon as the plugin update hits the svn repo wordpress installations around the world are going to start downloading it. It’ll be a disaster.

        Create forum topic from comment
        Reply

      • If auto-update everything was to be considered, it would need to be an available option in Settings > General that a user could choose to check or leave unchecked. This would probably bring up the numbers of people using up-to-date plugins greatly, without anyone being stuck and forced into auto-updates of anything that gets mistakenly screwed up.

        Create forum topic from comment
        Reply

  6. You’re right on all points about how it *would be better* if more people ran the most recent versions of their plugins, themes, and WP Core, but forcing this onto people is a horrible idea.

    An option to disable this is mentioned as a good alternative – but even here, the only kind/appropriate way to handle this would be if it was disabled by default and then required action to opt into it.

    Create forum topic from comment
    Reply

      • I don’t understand your reply.

        If you think that auto-updates will “cure” the security problem, you are wrong. Okay, so it will still leave security on the Web something that people who want to *use* the Web need to know about, and be conscious of.

        Your solution is a would provide a false sense of “someone else will take care of this”, encouraging an even further lack of awareness about the risks and realities of running a site on the Web, the last thing the vast majority of the WordPress user-base needs.

        Create forum topic from comment
        Reply

        • It will not cure the problem, but it will substantially decrease it. Of course, that’s assuming the code automatically installed does the job its supposed to which in many cases, seems to be the achilles heel to enabling them to begin with. I know there isn’t a silver bullet to solving the web security problem, but on paper, automatic updates across the board seems like a big step in the right direction.

          Create forum topic from comment
          Reply

  7. No it isn’t time.

    Obviously it’s on the radar – core supports automatic updating of major versions, as well as plugins and themes, but it’s not ready to be turned on by default. I’m the most eager person in the world to see this happen, but rushing into it (and adding some UI for disabling it as a fallback) is absolutely the wrong way to go about it.

    Will it happen? Of course. There are plenty of plugins and services that encourage it, Jetpack Manage is the just the latest in a long line. But when we’re talking about auto-updating nearly a quarter of the internet, we have to take it in baby steps. We need to be confident enough in the update process, in core’s backwards compatibility, and in the failure handling that we’re not going to break millions of sites.

    For the same reason we’re not ready to drop PHP 5.2 compatibility in new WordPress versions, we can’t just turn on auto updates and hope for the best. Even breaking a few percent of sites means millions of people inconvenienced, tens or hundreds of thousands of businesses with their online presence taken away.

    Create forum topic from comment
    Reply

    • Thanks for the reality check, I just saw the active install numbers of plugins and felt like it was the last straw to just bit the bullet and turn it on. I understand there are still problems that need to be solved for it to be a great experience. The last thing we need is for it to blow up so many sites that users lose confidence in the feature thereby, disabling it all together putting us back at square one. Sigh.

      Create forum topic from comment
      Reply

      • I did about 50 Websites in the past years. An Update needs to be maintained by a human.

        What if:
        – The Plugin update is simply buggy.
        – Your Theme depends on an already deprecated function of the Plugin, has been working through a couple of upgrades. The new Version will kill that function.
        – You use a css selector that the Plugin also uses in the new Version
        – Some javascript mess
        – You violated the coding standards (modifying the core) in a way that doesn’t affect security, like change the core. Example (question and accepted anwer by me): http://stackoverflow.com/questions/13460188/force-wordpress-to-create-thumbnails-of-same-size-as-the-uploaded-image

        That’s why I ultimatively decided to test updates on a mirrored copy of the Website only.
        In other words, WordPress would need to ensure the same functionality of the Front End, and a way back. Since a plugin update might also include changes in the database … well, forget forced auto updates, and let people take responsibility and live with the consequences :)

        Create forum topic from comment
        Reply

  9. While I appreciate the sentiment, I have to disagree. The plugin ecosystem — even just widely respected plugins — is not stable enough. The extraordinary success of WordPress’s auto-updates is the result of pairing an extremely capable set of hands with a very mature piece of software.

    While I realize there isn’t always an immediate need to update a plugin unless it’s a security release, it’s a good idea to keep them updated regardless.

    This is only an accurate sentiment in the context of a piece of software with an intense commitment to backwards compatibility. Plugin updates frequently modify HTML markup, CSS code and other extensible components without even considering backwards compatibility. Sometimes this is a necessary part of the software’s evolution. Automatic updates would increase the market cost for good software to evolve.

    Automatic updates would also significantly increase the damage a broken update can do. Fixing a critical error in the first 24 hours after release can save 95% of users.

    If the plugin repository enforced semantic versioning, so that n.n.n releases only represented critical security fixes and minimal bug fixes, then perhaps automatic updates by default could work in that context. But it would take a ridiculous amount of manpower to police this.

    An alternative would be to implement a security patch system, which could deliver automatic updates to selected versions to fix security issues when they are identified. In this scenario, a plugin author, in coordination with the plugin repo managers, would patch whatever versions were still in wide use with a special version which only fixed this security issue in the most minimal way possible. So if 70% of users were spread across three versions, they could provide a patch for each version. Perhaps that could be delivered automatically. But again, we’re talking about a significant increase in monitoring and policing for the plugin repo folks. I wouldn’t envy them the workload.

    At the end of the day this is a problem that needs to be solved by developers. Don’t break your shit and over time people will begin to trust your updates. A few people will never update, but that is their (ir)responsibility. We can educate, encourage and build trust. But there will always be hobbyists, lazy developers and overworked low-budget web shops that sold a client a product at a price they can’t afford to maintain. Bullying them with automatic updates will just push more of them into avoidance strategies.

    (Having said all that, a feature to opt-in to automatic updates on a plugin-by-plugin basis would be nice!)

    Create forum topic from comment
    Reply

  10. Yep, this is a tough one and since I cannot come from a theme or plugin dev perspective, I can’t really address the implications.

    But I do know with education we can beat it into people’s heads until they are severely dented. Many get it. But I also wonder how many of these site are either semi-abandoned or people who just don’t pay enough attention since their sites may be static and are hardly visited in the backend at all. Just so many variables on the education side of things ;)

    Create forum topic from comment
    Reply

  11. Based on my experience, which may not be nearly as extensive as some of the commenters, the most likely reason a site is running old versions of core, themes, and plugins is inadvertent neglect. WP sites set up by low-budget developers put up brochure-ware sites for clueless clients. The site owner adds a couple of posts, because that’s all they know how to do but then they get busy and forget about the site.

    And those same developers don’t maintain the sites they’ve built, because that isn’t fun or it isn’t their business model (which is build and run.) The site was running correctly at the point they built it, and that’s good enough. Time goes by and the developer goes out of business, or gets very hard to contact. Many of my clients complain that the guy that did their site won’t return emails.

    Notices to the site admin aren’t the solution either, as many of those same developers set themselves up as the admin destination for emails coming from WP. I’ve had clients who said they didn’t want to see emails about new user registration.

    The solution you’ve proposed fails due to the likelihood that the site will break on updating, due to the gigantic base of inferior themes and the low bar to entry to publishing themes and plugins.

    Instead, I propose that thought be put into the communication channel, perhaps using a whois lookup for the domain. The site owner is likely still in the loop, as the domain registration still needs to get paid every few years. If the core was able to do a whois lookup and sent email warning of vulnerabilities to the administrative and technical contacts, perhaps you’d have a chance of reaching the site owners and nudging them to get critical updates done.

    Another possible help is to add an additional contact field to the General Settings page: for the “site owner” – which would be notified of vulnerabilities. There’s no guarantee developers would actually set that field correctly, but it might help.

    Create forum topic from comment
    Reply

  12. Nice to see stats on “active” installs and the version being used, but you’re missing the stat on “active” sites. The promise of the internet and the treasures one could potentially reap from blogging, coincided with the growth of WordPress. But when that promise wasn’t realized, and in 99% of cases it wasn’t, boredom and frustration led to abandonment. One look at even the websites of some of the WP gurus from 5 or so years ago and their last entries were two or so years ago. I doubt they’re bothering to update their plugins or themes. Also, at some point unless or until a WordPress core update itself crashes the site because of incompatibilities with the old plugins or themes, it’s simpler and safer to just leave well enough alone.

    Create forum topic from comment
    Reply

  14. I am going to split my answer…

    How does the WordPress.org site’s repository know how many plugins are active? Whenever I am looking for a feature, I try some plugins that can do that feature. I try plugin 1, then deactivate and go to plugin 2 then deactivate and so forth. Then I decide which of the 10 plugins i just tried will give me the feature best then finally delete the other 9.

    I don’t like sending usability stats or whatever it is called that many plugins ask me to do when I activate them.

    Create forum topic from comment
    Reply

  15. I am completely against this idea. First of all, I make part of my living fixing broken/hacked sites from business owners who all they care is that their site works. they don’t care how.

    Two:

    Do any of you remember the part of backing up your site BEFORE you update? No matter how small the update is, let’s say 4.1.1-4.2, 4.1.1-4.1.1.1.1.1.1.1.1.1 or 4.1.1-5.0. There is still a risk of breaking the site.

    I don’t have the luxury of having staff from around the world work for me, like Automattic/WordPress has, thus, it always being 9am-5pm somewhere. so someone is available to fix things.

    If I update things while in front of my laptop, I can be there to change things if things are broken. What if my tweets/G+ badge/instagram doesn’t show off all of a sudden? I need those shown on the sidebar ALL THE TIME.

    If something breaks on WordPress.com then Matt Mullenweg has people to fix it right away if needed. If something breaks on MY site then it will stay broken until I come to it.

    My browser tabs open to my sites on http://www.mydomains.com/wp-admin/update-core.php (all 8 of them) and I check for updates and voila I am finished within 10 minutes (15 if I have to update WordPress itself).

    I haven’t changed my mind when auto-updates came into place, I will not change my mind.

    Updates for Phpbb have broken sites too when I updated phpbb. Other software as well. I fixed it right away because I was there and it wasn’t automatic.

    Create forum topic from comment
    Reply

  16. If user education didn’t work, try to get in the face, reach them by Admin Panel UX – Instead of showing small red bubbles with update count, bring it on the Admin start screen in BIG letters. If done with the taste, it will not look tacky, but will draw more attention and provide user with valuable info.

    Create forum topic from comment
    Reply

  17. Jeff,

    I’m all for auto-updating plugins, but I think it should be an opt-in rather than an opt-out. Looking at all the stats, I’m not so sure as to whether the low upgrade numbers reflect a choice of users not updating plugins or if it is because there are many more sites running WordPress than have gone into neglect. Do we have a split as to which users are different WordPress versions? e.g. some may even be using the versions pre-auto update functionality.

    As a plugin developer, I don’t support any older versions, so if a user needs support, they need to be running the latest version of the plugin.

    As for themes, I think auto-updating is a bad idea in the current state of the system, where any editted changes are lost if you’re not using a child theme.

    Create forum topic from comment
    Reply

    • Good point: you need a child theme when updating a modified theme!
      Automatic updates just work for small sites with just a few plugins. A lot of plugins and themes add new features over time that can modify your site. So if you have a bigger website, you need to have a test-installation.
      And what about Backups?
      I think auto-updates for plugins and themes are a bad idea.
      Put more effort in educating people about managing and securing a WP site.

      Create forum topic from comment
      Reply

  18. Jeff, I think your overall argument and need for such a system is correct. I agree.

    But if we put this into the framework of “apps” who generally get auto updated then I don’t think WordPress “ecosystem” will be able to get anywhere near of successfully implementing it.

    The problem you see if with the underlying foundation – the “OS” to keep it generalized. By OS I mean version of PHP, type of OS, version of WordPress itself etc. In case of apps – the container (iOS or Android) has a tight grip and a mechanism to systematically rollout (not to undermine the fact that they also have help for the ecosystem in place for development, testing etc).

    Whereas, WordPress in the first place wasn’t built as an “APP” ecosystem. The onus completely rests on the developer who is building the plugin and the wordpress admin who is consuming it.

    For e.g. We are both consumers for our blog (http://blog.backroomapp.com) and we also have a WordPress plugin which we want every blog admin to implement for building a private community on their blogs (https://wordpress.org/plugins/backroomapp/). Although we would love that WordPress controls the entire process, it will have to undergo many fundamental changes.

    – Much more robust and may be restrictive API for plugin building
    – Stricter submission and approval process, which can result in delays (it’s already quite slow)
    – This also would mean that developers would want “BETTER” monetization for their effort as currently they can see in apps world
    – Stricter version of underlying programming technologies used.

    But again, WordPress needs to step up and make this happen – it runs close to 20% of the web. It’s a massive number.

    Thanks for sharing this thought and writing this piece.

    Create forum topic from comment
    Reply

  19. A neglected or creaky website can as readily be a glass half-full, as half-empty.

    In many cases, low-ball WP deployments represent those who, say for instantiation, work at WalMart, all the hours they can get, for less than minimum wage. They drive a 20 yo beater, spend scarce cash on tools, and precious personal time & energy, keeping it rolling. They pour money down the rent rat-hole, and struggle without a light to mark the end of the tunnel, except for the occasional oncoming train.

    Do we want to paint the owners of all under-performing sites with the ugly-brush? Dismiss them out of hand? Or is there a potentially important – even necessary – upside for WordPress, in being the platform that the unwashed see as their best hope of joining the digital future, of participating in the Internet?

    These low-end web ‘masters’ are very numerous. Their friends & family know who they are, and they know what they represent. They have a lot of influence & effect, down in the grassroots.

    Maybe WordPress figures it needs to off this cohort. Maybe they’re right. But note that for a lot of these ineffectual or under-enabled dreamers, the vision will not end if WordPress has to ditch them.

    Create forum topic from comment
    Reply

  20. I think that enabling automatic updates for themes and plugins would be a very bad idea. Many websites cannot afford to install a broken update because they have a business to run, and therefore test the updates on a staging website before applying them to the live version. How would a forced automatic update system cope with that need?

    An example is the WooCommerce 2.2 update that introduced a problem with the WC Subscriptions extension. It took several days to the WC subscriptions developers to fix it, and many ‘early adopters’ were left with the functionality partially broken.
    Luckily, every time a major WC version comes out I wait at least two weeks before updating all my client’s websites waiting for the plugin to be stable again, but that is totally incompatible with a forced update policy.

    Create forum topic from comment
    Reply

  21. When I first saw the post, I thought it was April 1st. Then when I realized it was still March, I thought Jeff Chandler had changed his name to Josef Stalin.

    Building off the above element, first tell me why you think it’s better if everyone only runs the latest code. What problem are you solving? Do you care if someone is still running 3.1? Why? Is it affecting your community or your site in any way whatsoever?

    Auto-updating, in my view, only has three rational reasons to justify over-riding the user’s right to control their own setup.

    First, same as for vaccines, if you needed herd immunity. So, suppose a site is running v3.2, it has a known vulnerability, someone hacks it, and suddenly OTHER sites are compromised. That might be a valid reason but that is rarely the case in WP world — it just means that that site might start spamming others, but it doesn’t create a contagion effect that spreads site to site.

    Second, if WP ran on a central server and everybody connected to it, then sure, everyone has to have the latest version to connect and manage loads, protocols, etc. properly. Just like at an office with a centralized system, everybody should probably be running the same version of everything. There’s always going to be disgruntled Joe in accounting who still runs the 1987 DOS version of Lotus 1-2-3, but well, Joe probably needs to move on.

    Third, if the support by WP needs to be limited to latest version only. In theory, Apple could release a new iTunes version tomorrow and say “That’s it, we can only support this version from now on.” And I could see WP.COM doing that, similar to the above. But even the big companies can’t do it on commercial stuff — they are always having to support legacy users who haven’t upgraded to latest version and in some cases can’t afford to do so.

    Yet, I can anticipate you saying, “wait, it’s free” therefore no cost to upgrade (unlike Microsoft, Adobe, etc.). But it isn’t free. Suppose, for example, that I have a fully working system in WP 3.4 with a great theme that I had custom-built. But I’m a little NGO and I don’t have the $$ to upgrade and redesign. So, yes, I’m going to milk my little installation as long as I can until I can afford to upgrade. And maybe I have a 4 year old theme. But it works. Not all the people in the user community are designing their own systems — there are lots of developers making lots of money creating WP installs. But even a simple upgrade can crash an install, whether it be an old incompatible theme, or a plugin that isn’t updated to the latest core.

    Every upgrade in core (other than minor tweaks) *always* has a list of plugins etc that are being glitchy for awhile. So how would the “auto-on” work?

    Instantly = massive problems (not the least because of the issues above about PHP versions, etc.). Or that my server can’t run the latest. Or I have a customized install to some plugins and setups that I don’t want you over-riding with a brute force upgrade.

    Phased in = auto core after 3 months, auto plugins after six? Still same problems.

    Officially phasing out “older versions” more quickly? This won’t solve all your problems but it *could* stop people from continuing to install older versions. Although even then, there are some older simple plugins that are “out of date”, no longer supported, never tested with latest version, but work just fine because they’re relatively innocuous. I assume we wouldn’t “disable” old plugins yet if we don’t, would “we” auto update to a version where that old plugin isn’t compatible?

    There are other problems listed above, but I don’t see a way around the “auto = crashes” problem. More importantly though, the whole point of running a WP install is that you can customize it however you want to delivery your content on your server. Would you accept Windows telling you, “Sorry, I know you really like Win XP, but we’re going to force you to upgrade to Win7 tomorrow because it’s for your own good?”.

    Last time I checked, I was using WP so that I could decide what was right for me. I compromise on main core design and layout, but I shouldn’t have to compromise on my own custom installs that are working to risk one that doesn’t.

    PolyWogg

    Create forum topic from comment
    Reply

    • Well, this is the first time I’ve been compared to Stalin, not sure how to take that. However, you raise a lot of good points. The thing is, WordPress is headed this way and I just thought I’d chime in and see if we can’t speed things up, but I’ve been reminded once again of the hurdles that need to be overcome before the switch can be flipped.

      I think it’s obvious that when it happens, it will be for new installs and not forced on existing installs. That’s probably the best way to go about it without getting so much pushback. I’d be fine with that implementation as well though that means a hell of a lot of sites wouldn’t have it turned on. Guess you gotta start somewhere.

      We’re a long ways off, but at least people got the chance to remind me how bad of an idea this is.

      Create forum topic from comment
      Reply

  22. This is a great idea in theory but the reality could be pretty well horrible. This would need to be a double opt-in solution. That is, developers would first need to opt-in and in doing so agree to higher standards along with some specific versioning standards. 1.0.0 to 1.1.0 is considered a “major version” which would not be automatically updated. 1.0.0 to 1.0.1 would be considered a “patch” update and would be included with the auto update.

    This would allow developers who opt into this to push important patches automatically but not force new versions.

    Second, it would need to be opted into by a site administrator. Not something that is enabled by default but could be disabled. It needs to be disabled by default and enabled by savvy admins.

    This is important because there are cases where sites have plugins they do not want updated. In some cases they have found the new version conflicts with another plugin or theme. In other cases they may not want new features. Regardless it shouldn’t be something where someone updates to version X of WP and suddenly all their plugins and themes are updated and the site breaks or otherwise doesn’t work.

    That said, as a caveat to my comment above, it would be a good idea to have the option enabled by default on new installations of WP so those sites would be less likely to get further and further behind. That’s when things tend to get wonky.

    Create forum topic from comment
    Reply

      • Exactly, and along with damaging WP’s reputation will be the damage to the reputations of everyone who recommends and installs it for clients.

        IF this is implemented, I agree with Nick’s double opt in solution. In addition, we should have some choices about timing. For example, let’s say I can opt to have 30 days from the release of the update to see if I want that release at all and to back up first. The real world includes companies that do not have huge, global IT staffs. If you want to bring publishing to everyone, you need to consider what lives are really like.

        Someone above made a comment about Jeff being like Stalin. Clearly that was not nice and not fair. However, anytime an IDEA bears any resemblance to an idea Stalin might have had . . . and this one darn sure does . . . it is a bad idea. Forcing other people to do things YOUR way, even if you are smarter, usually doesn’t work out for anyone.

        Create forum topic from comment
        Reply

  24. #nope. #nopenopenope.

    Auto updating core is one thing — it has established long betas and tons of testing to root out edge cases before shipping. Plugin updates can be the whim of a single developer, and an ‘oops’ moment on a popular plugin could suddenly whitescreen every site running it.

    It would need to basically designate a subset as test sites, and if they succeed, try the next larger subset, and if not, roll back all updated sites, which it can’t do, and — arrrrgh, yeah, really not a good idea at this point for arbitrary plugins.

    Create forum topic from comment
    Reply

    • +100!

      Very good points!

      Even a small plugin with, let’s say 100 installs: when that breaks because of a small bug, function typo, or whatever. That means: 100 frustrated site owners! If this happens around the world with different time zones etc. could lead to sites being down for a lot of hours even if the plugin developer is working on a fix.

      But after such a crash the auto updater won’t work – because of crashed site – so the update has to be done manually.

      Horrible scenario! If I am one week on holiday and such scenario would happen, I am surely out of business after that. And in that case my clients would be totally right to do so with me…!

      Create forum topic from comment
      Reply

  25. Jeff,

    The reference to Joseph Stalin was kind of harsh, BUT you could always change your name to “Instigator” or “Bomb Thrower”. Then viewers would always know what to expect from your new Posts (I got a kick out of this one).

    Seriously…there were some pretty smart replies here…Good Read.

    Create forum topic from comment
    Reply

  27. No way until users can be satisfied that premium plugins are abiding by the codex. See wp-beginner’s recent article on this and Envato’s inability or unwillingness to check their clients’ code for compliance. Even a monster like Microsoft lets the user decide whether to download updates!

    Create forum topic from comment
    Reply

  28. The comments above say it all already: it’s not the time YET for such a change!

    Also, a site with a “mixed” plugin structure, let’s say 10 plugins from WordPress.org and maybe 5 from other sources (commercial plugin shops, CodeCanyon, whatever). Add to that a parent theme and a child theme, maybe also not from WordPress.org.

    Then all is running on “auto pilot” and we have lots of auto-updates: maybe WordPress core, and 5 of the plugins from WordPress.org.

    Even when those 5 plugins from .org are bug-free, there’s still the high possibility that there can be compatibility issues with those other 5 plugins that are not from .org.

    Remember: in my example we have an auto-update including WordPress core. This often requires small compat updates for plugins, especially also for such “commercial” plugins. Those are not opted-in to auto-updates but maybe rely on those free plugins from .org.

    The chance of a crashed site when you come to the office in the morning is very high here. And, this scenario above is not out of this world, it is just from reality from a lot of my sites I administrate.

    In the current state, having all running on auto pilot is a horrible thought for me.

    Auto updates for point releases of WordPress core, however, are a really great thing! So don’t get me wrong :)

    Create forum topic from comment
    Reply

    • The comments above say it all already: it’s not the time YET for such a change!

      Roger that! Upon thinking of everything people brought up in the comments, it’s clearly not the right time. I’ve been thinking a lot about the subject since publishing the piece and I’m wondering what got into my head. Must have been one of those days.

      Maybe auto updates of plugins and themes is stretching things too far? Plugins appear to be the wild card much more than themes in terms of causing things to break, after all, there’s usually more than one active plugin on a site versus one theme. I don’t ever see the plugin directory adopting stricter guidelines or becoming anything like the Apple App store. Since the core team can’t vouch for every plugin out there, maybe it’s out of cores jurisdiction to automatically update them, the risk is just too high.

      We know core is tested, vouched for, has the highest standards and the least likely to break things, so perhaps automatic core updates makes the most sense. Maybe plugins and themes should forever remain the responsibility of the site owner to keep updated or not.

      Create forum topic from comment
      Reply

      • …what got into my head.

        Good question. Or maybe the word is “who”.

        I only just returned to watching the Tav (It’s going to be a good year! And I’m back up online!), so I don’t know how long these ‘overstated’ Posts may have been going on. But “The Time Is Upon Us! The Sky Is So Falling!” (some paraphrasing) is not the only such case currently on display. Hmm? ;)

        And Sarah may be doing it too, dredging up this parked script off GitHub and proclaiming infinite scroll to be our eminent salvation from the shuddering awfulness of pagination. Etc.

        And ya know, it has been an ‘issue’ especially with the ‘new’ Tav, that the ‘action’ can degenerate into something like the Sales Staff at a Used Car Dealership making small-talk on the showroom floor, comparing the merits of polyester versus polypropylene polka-dotted dingle-ball interior fringe-accents.

        So … I don’t think whatever or whoever got into yer head is such a bad thing … some tune-up & refinement may be indicated, but I’m not going to fuss much over a bit of transition-roughness. :)

        Create forum topic from comment
        Reply

  30. I reacted in absolute horror at the thought of plugins being automatically updated. There is a very good reason why some plugins are not updated on my sites, and that’s simply that sometimes the updates are either not wanted, or that they manage to break existing functionality! I lost count of the number of times I’ve had to roll-back an update because it simply broke – and I’m not talking about little, one-man-band plugins here, I’m talking about some of the big names in the WordPress ecosystem. So, from me, it’s a big fat NO – NEVER!

    Create forum topic from comment
    Reply

  31. I remember this being on the wishlist since 2012 and discussed in length on WordPress Community Summit 2013.

    In order for this to become mainstream for plugins they would need to undergo the same scrutiny as core – “long established betas and tons of testing before shipping”. Which I think is not likely to happen simply because of the nature of the currently established plugin developer / wordpress.org / WordPress enduser relationship. However it would be in the best interest of WordPress project to slowly start changing this relationship to try to achieve the level of trust in the plugins similar to level of trust to apps in the iOS app store. First step would certainly be ensuring that plugins in the repository are secure to begin with. I wrote about that in more length here https://managewp.com/solve-wordpress-security

    I believe it is not an option to roll out the update to a portion of sites and if nothing breaks roll out to the larger sample simply because people running theses sites do not want their sites to be picked for testing whether an update breaks things.

    The only way that I see this can be automated in the current setting is by writing sophisticated technology that will backup the site, apply the update, check whether it broke anything (in a very sophisticated way), and if it did automatically roll-back the previous state of the website.

    Create forum topic from comment
    Reply

  32. Web designer installs theme for client because it is already 80% of what they want.
    Web designer has to make hard-coded changes to theme for certain features or requests that cannot be done any other way, which means ANY future upgrades to the theme must be manually merged, often with line-by-line comparison (with a tool like WinMerge).
    Somebody makes an executive decision to update all themes automatically.
    Literally millions of websites with changes to the theme files break. Many of them do not have backups configured properly. The changes are lost forever.

    This one single scenario, which *would* happen, would cause millions of dollars worth of damage in a blink of an eye.

    Create forum topic from comment
    Reply

    • …way more necessary features

      This does worry me. It’s a long-running head-scratcher, that clear first-things-first priorities drag on for years and years and years, and are still half-baked at best … while a mild whirl-wind of what can almost be termed circus come & go (instead).

      Take for example Image Management. ‘Excuse me’, but we all know that project owner Matt Mullenweg himself is a diehard photography aficionado, yet ‘pitchers’ have been a stumble-fest in WordPress, and I will be stumbling around yet-again with the thing in a few minutes this morning, simply to upload a few post-images. How is it possible that WordPress would not have an inviting image-facility?

      It worries me, because it looks like other forces are setting strategy on the project (WP) chess-board. These things happen, not only in politics & geopolitics, but in Business too, and in highly competitive software development. Yes.

      But, as we say back in the Old Country, you can also end up with a tender part of the anatomy pinched in the door-jam, ‘playing this game’.

      There is no real, long-term plan. There once was, but the powers that be were chagrined to find that indeed the best-laid plans of mice & humans are subject to the same Natural Law. What happened to the small, light Core that would mainly serve to support Plugins? Life happened.

      So it is right, that rigid adherence to orthodox priorities be ready to bend to the winds. Verily, to hurricanes, and apocalyptic ice-storms, floods, drought and whatever else may materialize in the Morning Weather Roundup.

      But there are clear hazards. WordPress itself emerged from a time of uncertainty, not that unlike what prevails today. Although WP may seem secure in its market dominance, there is in fact now a ferment similar to that at the turn-of-the-century, in which WordPress was laughed at roundly by a cohort of supremely dominant and absolutely confident competitors. All of whom now rue their hubris.

      There is a time to dodge & weave, and there is a time to play it straight.

      Create forum topic from comment
      Reply

  34. I’m with PollyWogg and several others – in the real world this would never work without breaking large numbers of sites. And that would probably be the beginning of the end for WordPress.

    Unless theme and plugin developers HAVE to keep their wares up-to-date, forced auto-updates are sure to cause problems. But, the open source nature of the community means most developers won’t bother to create and publish – there’s no incentive.

    We work with many very small businesses who can’t afford to pay for the upgrade work (or broken site fixes) just to keep their code at the latest version – there has to be some benefit to them … and in general terms, there’s no benefit to a micro-business owner in having WP4.1 instead of 3.6 (for example). What has really been added in half a dozen releases?

    And there’s one particular plugin I use on nearly every site … ‘Page in Widget’ This is an essential plugin so clients can update content in a widget area with lowly user rights (a failing with the WordPress core functionality). It was last updated 8th July 2011. It still works, so what’s to update. It ought to be core functionality (along with lots of other things) … WordPress.org is still stuck in the ‘this is blogging software’ mindset, and needs to embrace being a ‘proper’ business CMS.

    In the WPMU DEV blog about their new ‘theme’ Upfront, James Farmer mentions the competition snapping at WordPress’ heels … and they all position themselves as business websites, not blogging platforms. Perhaps the writing is on the wall …

    Create forum topic from comment
    Reply

  35. Jeff, obviously a very thought-provoking article. There is no reason to retreat all the way. It is a valuable idea in some cases now, even with possible gotchas.

    Why not have the option for the site owner to auto-upgrade a plugin if a security fix was made or at least to auto disable if vulnerable? Even premium plugin authors might be willing to provide a new version or a patch for free to avoid getting a bad reputation. If a vulnerability was found with your plugin then you submit a priority ticket to have a fix rolled out.

    I’ve noticed the Wordfence plugin has auto update as an option already.

    Create forum topic from comment
    Reply

  36. As a commercial plugin developer and a professional WP sysadmin for clients, I’d say that the concept of having auto-updates for core and plugins is fine for those who want to opt in, but I would argue against making it default (or opt out) and I would honestly start looking for a different CMS if it became a forced thing that I couldn’t work around.

    Here’s why:

    1. As a sysadmin, I run some high traffic commercial sites where downtime = lost revenue. Those clients are paying me to make sure there is zero downtime. That means that I test every single update to every single plugin, as well as core WP, before applying those updates to my production WP installs. Any time I feel even remotely sketchy about a particular update even after testing it, I backup the db, backup the existing plugin, apply the update to production, then carefully make sure all is well before nuking those backups. My procedure has saved downtime more than once on broken plugin updates.

    2. As a commercial plugin developer, I test my updates on my system before I release them, but is my system your system? Is my system running the same ecosystem of plugins, themes, etc that yours is? That everyone in the world who is running my plugins are? Those are nopes, and that means that the responsible way to update for sites that cannot tolerate downtime is to test first in your own environment. Plus, I don’t know about you, but I MAKE MISTAKES SOMETIMES. As far as I know I have not yet released a seriously broken update, but I can’t say that will never happen.

    There are plenty of people who are running WP “casually” (meaning they can tolerate hours or days of downtime if an update goes wrong) and who are not so technically inclined, and for those people, having the option of turning on auto-updates would be a big plus. But there are also plenty of people running WP “professionally”, who need to do the kind of testing that I do before deploying to production. Taking away the ability to test before deployment for us pros would be tragically insipid.

    Create forum topic from comment
    Reply

  38. As a plugin developer, I’ve built auto updates into a plugin or two I’ve released. There is an option on the settings page to opt-out , but out of the box it’s set to auto update. I haven’t had many issues with users complaining about the auto update feature, and find that it keeps everyone on the same version which helps to mitigate support requests from users who are still using outdated versions.

    On another note, I noticed repository only tracks minor updates such as 1.1, 1.2 etc. It doesn’t get any more granular, like 1.1.1 or 1.1.2 etc.. Hopefully they update this to track the minor releases as well.

    Create forum topic from comment
    Reply

  39. I think we’re missing the crucial fact that WordPress, by its very license, is supposed to be free to use in any way desired, which includes running very outdated, security-compromised installations. Kind of like the freedom of speech, we need to allow users to do stuff that is pretty horrible and even stupid because 1) it’s their site and 2) it’s their freedom and choice to do so.
    We should never force users to do anything without their knowledge and approval. And that includes auto-updates. What we should be doing (and continue to do) is make it easier to do updates, make it easier to do backups, make it easier to roll-back to previous states, educate users on best security and update practices, provide useful communication in the dashboard about updates, provide better testing data so users can make meaningful decisions about whether to update or not, etc. Make it easier for people to make the choice to update. But don’t force updates on people. One example of a plugin update that really annoyed users was the Stream plugin going from 1.4.9 to version 2. The plugin completely changed how it did things as data is now stored on a 3rd party server and requires your WordPress.com account to access it. If a user updated without knowing this (which was very likely given the lack of communication about this change) they “lost” all their data (not really but that’s what it looked like), and seemingly lost the functionality of the plugin. Just that one instance shows that “auto-update all the things” is not a viable solution *at this time*. And even then, it should not be the default solution. Site owners should have the final decision on what they run on their WordPress site and how to run it.

    Create forum topic from comment
    Reply

      • Philosophically I was against it for the above reasons (it’s someone else’s site, not mine – I should ask permission first before doing something to it).

        That being said, since WordPress core has been extremely good at being conservative in what it auto-updates, provides a mechanism to disable auto-updates, and provides a way to safely fall-back if an update fails, I am more accepting from a pragmatic view.

        I see it a bit like somebody’s apartment – they’re paying the rent (hosting), they can have the 50’s style wall-paper (outdated theme) and the old 60’s oven (old plugin). And I shouldn’t go changing their apartment on them without first getting their permission. Now if you got the landlord’s approval, that would be a different matter. And really probably the better individual/organization to focus on as far as updating old sites, themes, and plugins. But again, get permission first – it’s a respect issue IMO.

        Create forum topic from comment
        Reply

  40. By default but with a clear, easy to immediately find and properly configure, set of options to turn it off, possibly in detail, for specific components and/or update types, can make sense, though I’m not sure how can anyone be 100% certain an update won’t break something for someone else and force it on them that way. (Don’t get me started on what software in general does in recent years, drives me crazy.)
    By default and less obvious or even impossible to configure or turn off completely without actually editing code, definitely not. Otherwise, users may have reasons not to update, or at least reasons to fear updating, namely lack of confidence in the release-day stability of new versions, possibly as a result of past experiences, or using other old or very “rough” custom components or modifications that could behave highly unpredictably, and in those cases such a move will only reduce the confidence even further.

    Basically, if you say you don’t like software holding your hand, don’t force the behavior down others’ throats.

    Create forum topic from comment
    Reply

  41. No No No 1000 times no! You are trying to use the tail to wag the dog, and that’s a fatal error.

    The problems exist not because wordpress itself is not secure, but rather by definition the plugins and themes are not tested, not held to high standards, and generally are released without testing and consideration. Almost every one of the major security issues facing wordpress right now comes from insecure plugins which essentially open your server / host up completely without any way for you to know.

    Currently there are a few big ones out there. Revslider has been huge, and today I am seeing a massive and consistent attack coming from infected wordpress installations, being used as part of a larger scale brute force attempt (thankfully, I don’t rely on wordpress weak security, and instead filter them away from being able to log in at all). It’s pretty big, I am seeing upwards to 10,000 login attempts an hour from hundreds of IPs – each one comes back to a wordpress install, and more than half of them have vulnerable revslider installs – and most of the sites are running wordpress 4.1. So automated updating of the core isn’t changing a thing.

    What really needs to happen with wordpress is that the plugin universe needs to be tamed. Right now there are few rules, no testing, and no certification or standards to meet before a plugin becomes available. The results are, well, catastrophic. Yes, we get lots of bonus functionality, but we also get lots of problems. It doesn’t help that many of the plug ins are written by people who only support very old versions of PHP, making some plugins incompatible with the core in some ways.

    Moreover, there is little or no version control. Since wordpress flags for update as soon as the version number changes, we all get to see silly updates (“added estonian language support” or “updated comments in code” being a couple of my favorite non-reasons for a new version). Themes are even worse, I recently had one theme I was using get completely replaced with a new incompatible design by the designer, who didn’t make it a new theme and instead tried to shove it on people using his existing theme. Automated update, with or without child themes would have been a disaster.

    My suggestions are:

    1 – plugins and themes need to be coded to the release they work on. Plugins which are out of date should be disabled.

    2 – by definition, plugins that are not maintained (and don’t have the version matched to current wordpress version) will more quickly fall out of use.

    3 – minor revisions should not trigger an update required flag. Perhaps pointing out that a minor revision is available and allow site operators to CHOOSE to get them would be better.

    4 – automated updating of the wordpress core should not happen if there are not compatible updates for all plugins. The problem should be noted on the control panel so that the site operator can make a choice.

    5 – WordPress needs a “code clean up” when a new version is installed. Give site operators a list (or an automated choice) to eliminate old code not in use, plugins not in use, themes not in use, and so on.

    If you get control of the real issues, and then automated updating makes more sense.

    Create forum topic from comment
    Reply

    • One of the problems associated with keeping plugins up-to-date is the WordPress.org reliance on plugins to do things which should be in the core.

      Over the course of a few years I’ve made numerous suggestions for additions to core, and the stock answer for the moderators and developers has been ‘you can find a plugin to do that’.

      Plugins (and themes) come and go – even paid-for ones – so they can’t be relied upon.

      Answer – much, much more core functionality.

      If the core seems to be getting bloated and slow, how about WordPress.org creating these free, guaranteed-to-be-updated plugins?

      Create forum topic from comment
      Reply

  44. “These statistics indicate that the only way to keep as many sites as possible updated is to forcefully turn on automatic updates”
    What? How is that indicated by the statistics? There’s several other ways, such as C.I.
    “the numbers indicate that millions of sites are running outdated code by choice which is unacceptable”
    That’s your opinion.

    Create forum topic from comment
    Reply

    • Because if auto updates were turned on, then the active version numbers would trend towards the most recent releases. Since so many sites are using outdated versions of plugins, the only logical explanation is because it’s by choice. The other reason is that all of those sites are dormant with no one taking care of them. So, if we can’t get users to keep plugins up to date which is something we harp on as basic security advice, than what’s the hope in getting anything else updated. Also, what does C.I. mean?

      Your darn right it’s my opinion, the entire post is my opinion, and this comment is my opinion. Since auto updates don’t exist for plugins, how can you not conclude that that running outdated versions is by choice.

      Create forum topic from comment
      Reply

      • I love your passion for this issue Jeff but you can’t deny the problems auto-updates would cause. You seem to go on a lot about having ‘pretty stats’ for WordPress and that people are running older versions by choice. But how does that affect you? If people do run older versions by choice, let them. It IS their choice. It’s also their issue if something goes wrong or they get hacked. But we have the right to make the choice for ourselves. WordPress depends on plugins, themes and the WP core playing nice…but we all know that doesn’t always happen. For those of us who manage heaps of sites, if auto-updates become mandatory and there is a conflict or bug – that is much more of an issue then not having auto-updates.

        Allow people to test updates in the sandbox before deploying. It’s the professional thing to do.

        Create forum topic from comment
        Reply

      • Sorry, took me a while to answer ha!

        C.I. means continuous integration. It’s a very important enterprise software testing and deployment technique.

        I never disagreed with your conclusion that running outdated code is by choice, I just think your opinion that other people’s choices are “unacceptable” is, let’s say, not very interesting.

        Cheers!

        Create forum topic from comment
        Reply

  45. I personally thing auto updating is a horrible idea. It just doesn’t work because some plugin developers thoroughly test their releases and others don’t. I manage dozens of WordPress sites and I’ve had various plugin updates break sites from time to time. I LIKE being able to update a plugin on one or two sites to make sure that the update doesn’t break something. If auto updates were forced on me and an update to a plugin breaks something, I have dozens of sites to fix and that costs me time and money.

    Create forum topic from comment
    Reply

  46. Auto-updating would be nice, but it just isn’t practical for the majority of plugins.

    Like everyone, I’ve had plenty of plugins straight up break after updating. Usually these issues are fairly easy to fix, but sometimes it’s the result of a terrible plugin you had to use because of a client request and fixing it just isn’t worth the time or energy. In these cases I’ve reverted and prevented the plugin in question from being updated period.

    Now, as a developer, I can troubleshoot any problems that arise from updating. But what about non developers or people who had someone else build their site for them? In this scenario, if something breaks when updating, you’re basically screwed.

    I’d favor auto-updating for the most robust and popular plugins. These could then be labeled on wordpress.org with a shiny badge or something. But autoupdating everything is madness.

    Create forum topic from comment
    Reply

  47. Auto-updating is the equivalent to a communist country. If people don’t update, it’s their own fault if something happens. HOWEVER…if you DO have auto-update there is one VERY BIG ISSUE…plugin, theme & WP core compatibility. With autoupdate, if there was a coding conflict between your plugins, theme and WP core your site would break and you wouldn’t know about it.

    So auto-update enabled, it updates, a conflict occurs…and your site is broke. But you don’t know because it was an auto update. Even if you get notified when it updates, you still have a broken website until you go and debug it. Whats more, you HAVE to debug and fix it right away. If you sandbox your site and test an update, you can (at your leisure) work out the issue and fix it before going live with the update. But auto-updates…NO, you have to fix it then and there else all your site visitors have a BROKEN experience.

    BAD idea and a WP communist ideology.

    Create forum topic from comment
    Reply

  48. Sadly on this occasion, much though I love the idea of everything staying updated, I have to agree with the naysayers.

    Just over a week ago the Yoast SEO plugin was updated and, for about an hour, the update completely broke sites – https://github.com/Yoast/wordpress-seo/issues/2029

    You had to manually delete the plugin folder and then wait for the next update before putting it back.

    With over 1 million active installs an automatic update would have been a complete and utter disaster.

    If such a popular, respected plugin can make that mistake, what hope anyone else?

    Create forum topic from comment
    Reply

    • Exactly. I’m running two multi-site blogs that are mission-critical at work, plus a number of sites I manage as a freelancer. If everyone starts getting the white screen of death at 2 in the morning, that’s a real problem. It feels like it’s a bigger risk than having a security hole being open for a couple of hours until I get in to the office to run my updates manually.

      Create forum topic from comment
      Reply

  49. While the vast majority of plugins / themes can’t cleanly pass the WP_DEBUG / WP_DEBUG_LOG test yet, let alone warrant they’ve done basic testing of new releases, I scream NOOOOO. Get the quality level up first before even considering an auto-update scheme.

    Create forum topic from comment
    Reply

  50. I know this isn’t a voting post.. However, I’m also screaming fkn No Way!
    There’s almost 100 replies and granted I haven’t read all of them, there are some extremely valid points up there.

    Why were we forced to update from Windows XP? Security, Compatibility, or for M$ own benefits. believe what you may. Someone once said, if it doesn’t name sense follow the money.

    It also goes against WP Open license. Do what we want with the code… but then have it altered back in a blink of an eye… No thanks.

    Create forum topic from comment
    Reply

  51. Well, this is interesting but in the end it’s very much apples and oranges.

    Not running the current version of Plugin X is actally not the same as site / install being venerable. They might loosely correlated but that’s still not cause, simply correlation.

    Helpful? I suppose. But we’re still not there yet, and perhaps not even close.

    p.s. If more plugins used OOP then retroactive security updates could “fix” older versions but leave older – probably more basic – functionality intact. That is, you could, ideally in theory, safely run not current versions and not be any more or less at risk.

    Ultimately, this whole problem is a product development and product architecture (is you will) issue and not strictly a security issue.

    Create forum topic from comment
    Reply

  52. It already updates the core automatically on new installs right?

    AND I still go into my configuration files and disable that feature.

    I like to update things manually. ESPECIALLY plugins because I need to know what the new changes are. This makes work, but if you care about your site, you should be doing manually updates on everything, especially themes and plugins which may have direct impacts on the look and functionality of your site.

    For sites that don’t keep their stuff updated, that’s a problem they need to solve if they care about the site.

    Create forum topic from comment
    Reply

  53. How about having some sort of metric to express how out of date an entire WordPress installation is could be given? Perhaps a total of the number of versions behind each active plugin, the current theme and WP core is (with perhaps a higher weighting for core). Inactive plugins would not contribute to the score as generally they pose no issue until activated.

    This would be an internal score only, visible on the dashboard and perhaps the updates page, and a higher score would indicate an out-of-date site with a higher chance of security risks.

    Seasoned developers and site maintainers perhaps would not get too much from this, but typical hobbyist or content-focussed owners that have a lower technical level may appreciate the instant appraisal of such a score?

    Create forum topic from comment
    Reply

    • Actually, you could add weighting for different release types (major/minor/maintenance) but who’s to say that a maintenance release isn’t more important (from a security point of view) than a major release, as they are often released to target a specific issue, whereas major releases address multiple issues and add functionality.

      Another thought – these individual scores could be shown against each plugin/theme on the updates/plugins page. Could even add some colour-coding?

      This is all assuming that the out-of-date plugins are on sites managed by people less-interested in the technical detail and more interested in actually running their site to achieve sales, publish content, etc.

      Create forum topic from comment
      Reply

  54. Nice idea.

    1. I think WordPerss core should offer a way to update everything. The good thing is that it already does. The first step is taken.

    2. It must be opt-in, default off, for old installs, even if they update to newest core, and default on for brand new sites, with ability to opt-out on the install screen or later as an option.

    3. It must be opt-out-able for each individual (auto updatable) plugin and theme by site admin

    4. It must be enabled only for some very well-maintaned, “class A”, plugins. These must be developed by at least three, or so, leads on a public repo, follwing a set of rules for good practice and versioning.

    a) The plugin must have at least 10 (or so) alpha sites to which the plugin is first pushed to as auto updates. Then wait 48 hours or so before next step, with an easy abilty to halt the process.

    b) the plugin must have atl east 100 or so volunteering beta sites to which the plugin or theme is then pushed to as an auto update. Then wait 96 hours, or so, before proceeding

    c) The release must not do any database schema changes automatically

    5. WordPress core must have a full revert/rollback ability for plugin and theme auto updates, like it has today for core secutiy updates. It must revert if anything detactable breaks. If anything breaks in alpha or beta pools of sites, the update is set to halt.

    If, and only if, all these criteria is met, a theme or plugin is allowed to perform a global auto update.

    We will have a “class A” set of plugins and themes. When isntalled they will say so, and offer to disable if the admin wants. The rest must either strive to get class A status or not be able to auto update.

    For core should also be a hook and documentation on how backup plugins can be triggered to make a full or patrtial backup and signal back to the update system that it’s now safe to perform the update. This could also work for manual updates, automatically running a backup, then update.

    Jetpack was once auto updated to bring a security release, riding on cores’ current mechanism. I suggest making this possible for other plugins, and for themes, in a very controlled way.

    I already have fuly automated updates of core (major), plgins and themes on 40 of the about 50 sites I manage. I mostly miss the ability exclude a plugin or two.

    No one, I have seen, has suggested to force WordPress users to auto update if they don’t want to. Yet, someone is mentioning totalotarian ideologies and dictators by name. Those sayig such thing are the ones who know exactly how to circumvent anything in WordPress. Are they speaking on behalf of anyone else? Not the common user, that is for sure. I would say the commun user need a way to stay updated without having the knowledge on how to do it safely and easily (install and auto update plugin, as per today). Many common userss are afraid to press the update button because they thing it might break something. And it may, sometimes. So what we need is to get the most important things updated safely, and then it might just as well go automatically. If they haven’t said no thanks, that is.

    When I buy I car I would welcome automated service and tyre changes, if available from well reputated garages, approved by the car manufacturer, picking up my car at midnight (or whenever agreed upon) and returning my the morning. If it was free, I wouldn’t mind if was an opt-out thing when buying a brand new car, but would like it to be opt-in when buying a used car. Analogy not perfect, though.

    I never update Chrome. Chrome updates itself. I don’t know where to turn it off, and i don’t bother finding out. I am sure there is a way. I sure hat if I wanted to look for it I would find it. I’ms sure there are thousands who have disabled it. Add-ons may break after an update, but I only depend on “class A” addons. I guess they are well tested on thousands before I receive an update.

    This is the future of WordPress, a web OS, offering to keep your site safe and secure for the majority. The majority are do-it-yourself-amateurs, only seeking help when they see the immediate need. The advanced users and developers will, as always, go their own way, taking more manual control, and even making a living on maintaining others web sites, like I do.

    Thank you for speaking the best for the majority, Jeff. It can be done, with enough caution. We may start walking the path today, but it’s a long way to go. And it won’t be for everyone, just the majority.

    Create forum topic from comment
    Reply

  55. I’m not surprised that lots of people use an outdated version of Jetpack. It consistently fails to auto-update for me, to the point where I used the notification as a sign to visit the jetpack site and upload the contents of the zip file via FTP. This is through no fault of the developers (nor mine) but more a problem of my host. I imagine many hosts (and their customers) would not be thankful for auto-updates that had the potential to cripple sites.

    Create forum topic from comment
    Reply

  56. its very needed : it will minimize the load of site developers and maintenance team

    but for some plugins or themes its not good , last time I have updates a slider plugin which was not working properly after the update , and I was unable to revert back the changes , actually I am still searching for where can I find the logs of core & plugin/theme update procedures.

    if the wordpress team is thinking to add this feature then they should take all the precautions.

    I should add this here, I have setup core wp updates automatically (while installing wp via QuickInstall/softaculous ) and found no bad things after auto updates.

    Create forum topic from comment
    Reply

  57. Instead of this, maybe we can take a few incremental steps?

    1. Can we please fight for a better plugin management system in core than using FTP? It makes it a larger hassle to update plugins than the process needs to be. There are lots of ways to incorporate Composer into WP right now as a developer, but it’s never standard. Integrating Composer would save a lot of time managing plugin/theme versions, discourage users from making hard edits to files they shouldn’t be, and be more VCS friendly.

    2. Perhaps we can start letting plugin developers flag a release as a security update? I’ve used this a lot with Drupal as it quickly identifies what updates are features (and may not be necessary enough to soak up precious dev time and money) vs. security patches that should be immediately updated.

    3. An alternative and more controversial option would be allowing plugins to declare dependencies. Maybe myPlugin declares it depends on yourPlugin v1.3. However, no one depends on otherPlugin, so it can be (more) safely autoupdated. This would at least give users and developers a chance to prevent autoupdating on plugins that they want to test before deploying.

    Create forum topic from comment
    Reply

  58. The only way automatic updates would be anything but a disaster is if it was manually opt-in, instead of opt out.

    Not only do web developers often mod themes and plugins directly, instead of via a child theme, even non-programmers can find on the web how to make little changes, and are likely to do it directly to a theme or plugin.

    There would be websites breaking all over, if things simply updated without asking.

    There is already too much of this sort of busybody thuggery in the technology world, with operating systems that update themselves or programs without asking by default. It’s OFTEN a cause of problems, as well as keeping people more ignorant of the workings and status of their own machines.

    Create forum topic from comment
    Reply

  59. I agree that things should be updated regularly. But I also like version “control” when I can add value as a site admin eg; release note, rating, forum reviews, etc.

    I also love large problems. This still seems like a large problem to solve.

    Would still like to to be able to do my own code freezes. For a while longer, I think.

    Do people still say, “code freezes”?

    Create forum topic from comment
    Reply

    • I agree with Brent about the versioning.

      It isn’t practical to update sites (when one is managing a large number, say more than 10) every time a plugin update notification is received.

      And experience has taught me it’s asking for trouble just to run plugin updates on live sites … plugin updates sometimes break the site, mess up the display or conflict with other plugins.

      The security plugins don’t help. Wordfence, for example, flags EVERY plugin update as ‘critical’, when patently they’re not.

      I’d also like to take issue with plugin writers who don’t include version numbers in the file names – I know I can add this myself when I download them (which I do to short-circuit some of the time spent searching through the repository), but it’s a pain and (I think) unprofessional on the part of the plugin writer. This is actually worse on premium plugins.

      Create forum topic from comment
      Reply

Leave a Reply

Your email address will not be published. Required fields are marked *

This site uses Akismet to reduce spam. Learn how your comment data is processed.

You may also like

Newsletter

Subscribe Via Email

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

Discover more from WP Tavern

Subscribe now to keep reading and get access to the full archive.

Continue reading