Why doesn't Drupal offer an auto update feature like Wordpress? | Modules Unraveled

Drupal Auto Update Feature?

Let me start out by stating that I don't know the technical implications of an autocomplete feature. Okay? I don't have the answer. I'm just looking for information. Best case, I can help get something started that will benefit the entire Drupal community in the future.

With that out of the way, I firmly believe that anything is possible with Drupal. And with the "Drupageddon" of late, an auto update feature would be greatly appreciated by many, I'm sure. (I certainly would have benefited from one.)

I was recently discussing the security update with some friends, and one of them asked "Does Drupal have an auto update?"

And I was like "...no."

Immediately, I thought about all of the updates I don't immediately apply to contrib projects because they change a configuration option, or otherwise modify the way I've set up the site.

So I thought "I don't really want an auto update because it might break things."

That said, why can't Drupal automatically update security fixes - at least in core - automatically? If it did, Drupageddon could have never been a widespread issue.

It's easy to think, "Well, it's fixed now, so there's nothing to worry about."

But I think that's shortsighted.

The particular vulnerability that caused "Drupageddon" has been around since the inception of Drupal 7, which was officially released in 2011. So, for at least 3 years, every time we've fixed a security flaw, we've thought, "It's fixed now, so there's nothing to worry about." ... until the next issue was found, and this last one was a pretty gigantic one!

Wordpress introduced auto update in version 3.7 on October 24, 2013. They also included options in their configuration file that can be set to disable auto updates, as well as choose which types of updates should be performed automatically: none, major and minor or minor only.

You can read more about it on the Configuring Automatic Background Updates page:

I'm just curious if this is something that can be added in a point release of D8 (like 8.5 or something).

Also, I've ready a few posts saying that auto updates would not fit their workflow. They use Drush, Git, etc. to manage their development workflow. And if that's you, I'd say that turning the auto update setting to off would mean that you can continue to work the way you currently do.

However, small business owners, churches, non-profits and the like that have volunteers (with little to no development background) managing their sites don't have the luxury of utilizing Git, Drush etc. In those scenarios, I think the case could be made that an autoupdate feature (as long as the updates are tested before release) could be a much more stable way of maintaining a site than having a volunteer FTP files to a server without really knowing what they are doing.

If you have thoughts, please add them below. I'd love to hear them!


  1. After doing some more research, I've found that some people tried to do this in D7, but postponed to D8. However, there hasn't been any movement since April 28, 2013. https://www.drupal.org/node/606592
  2. There's also a post explaining why auto updates would be a very bad idea from September 1, 2011. http://www.freelock.com/blog/john-locke/2011-09/why-auto-updates-are-very-bad-idea I'm not sure that I agree with everything he says though.
  3. It looks like the current conversation about this is happening here: https://www.drupal.org/node/2367319 (And I agree with comment #4, I'd rather have a broken site than an exposed site... A multi-million dollar ecommerce site might disagree, but that's not me.)


The problem with wordpress auto updates is that the webserver user must have write access to the code base, which is an inherently insecure configuration and is strongly discouraged. See https://www.drupal.org/node/244924 . For example with #drupalsa05 many attacks tried to plant evil PHP files somewhere besides the Drupal core files, which is not possible if you have locked down your permissions.

https://www.drupal.org/node/2367319 is the new discussion for an auto updater, maybe with drush?

Thanks for the updated link! I didn't find that in my searching.

On requiring Drush:
If we require Drush, I think we're alienating the users who would actually utilize auto updates.

I'm thinking of my dad for example. He's built a Drupal site for his church (with my help), and hosts it on a GoDaddy shared server. (I recommended he not do that, but cost was the deciding factor. As it is for many.) He doesn't have Drush installed and does all of his updates through FTP (no version control). So he would definitely like an auto update feature! But if we require Drush, he won't be able to use it.

People who are already using Drush, likely have the knowledge and experience to do the updates in a matter of minutes (or seconds) already, so an auto update, while helpful, isn't as big of a deal to them. And those users are most likely the ones that want to test the updates on their dev environment before pushing to live anyway. So, I suspect they would probably disable auto updates to begin with.

My suggestion in that issue wasn't to require the updates be done with Drush, just to provide it as an option. That way it's also available to people who want more secure server setups, as well as potentially integrate with dev/test->staging->production workflows.

I do think automatic updates would be useful for experienced developers also. Even if you can update a single site in a few minutes, you might have many different sites (on several different hosting platforms) that you're responsible for, and you also might not want to be awake at 2am local time to do the updates... :)

I totally agree! I host a number of sites across various platforms, and I do use Drush. I would definitely setup automatic updates on quite a few of them if I could.

Also, 2am... yeah... that's a barrier that we ran into with SA-CORE-2014-005. They had to hold off on releasing the fix because there were a number of events that were happening once the fix was ready for prime-time. And they tried to release at a time that would work for everyone across the globe... not an easy thing to do.

Automatic (at least security) updates, would mean we would have had the fix weeks earlier than we did, and there wouldn't have been the rush to get everything patched before hackers started exploiting sites - hours after it was released.

Oh, but you can!
Make a script, say something like this:

drush up drupal --security-only -y

Make it executable with chmod +x scriptname.sh

Add it to cron so it'll run every night or whatever.


That's great to know for private hosting! But doesn't help those on shared hosts... I think shared host users have the most to gain from an auto-update feature.

The way WP auto updates work is through FTP, though I believe it can now do SFTP so long as you have mod_ssh2 installed. Of course that leads to just as bad, if not worse security nightmares. Of course that means running insecure FTP, or if you are running SSH, then having the password or a public key saved for the webserver to access. I've never been one to really trust auto-updates and even the last couple of WP sites I maintained for clients, I disabled that feature. I do employ a somewhat auto update feature for my client sites, utilizing my private server, drush, git, automatic testing and shell scripts. It's worked out great for the 2+ years I have been running it.

It's not limited to FTP, if the core files are owned by the user that the web server runs as: http://codex.wordpress.org/Updating_WordPress

The question of webserver having access to codebase is not simple. First there is the balance of harm. For general users balance of harm favours allowing auto-updates, for professionals users, Drupal would use the WP concept of allowing this to be turned off in code (in settings.php).

Yep, I think that if there ever is an auto-update feature, it'll have to be disable-able (or enable-able, depending on the default value) to satisfy both types of users.

I think auto updates will add a huge benefit to Drupal. Recently when Drupalgeddon came up, many people and agencies had panic as they need to update all their sites at the same time somehow. This could be avoided with update automation. Due to the workflow may Drupal shops have, I agree that updating a live site with an auto update feature is not a good idea. But what if we let our continuous integration platform like Jenkins add the updates to a feature branch of the git repository, notify the development team that there are new updates (after the automatic tests for the project have been passed), create a ticket automatically in your project's task tool and if the ticket is closed, deploy the update feature branch to live and merge it back to the dev and stage branch in the repository. With this process we have updates applied as soon as they are available and we have the quality ensurance passed.
We implemented this recently with an integration to our internal ERPAL installation and it was possible to run all updates automatically within a couple of hours after the security update was released. I am wondering if there is no other way to do this but I am sure it will help Drupal to get even more trust and reliability.

I had the exact same thought to the main title ("...no").

but thinking further, it exposes another problem - updates should not break existing sites/apps.

Just imagine you lived ina world where firefox would break itself regularly - or even chrome. Both have automatic updates, and it would be crazy to expect either to break during an automatic update (though I am sure that must happen at some point). (lets not forget automatic updates of thw whole OS, which most people require)

WIth drupal there is the engineering aspect of automatic updates which can be overcome. but then there is a cultural aspect where either updates are expected to occasionally break sites (I hae experienced contrib updates incorrectly deleting content from the database...).

The culture can be changed but probably requires more engineering than the engineering aspect.

What about the economic model? We all earn money when your clients have to update. There is little incentive to break that money maker, there are plenty of support firms that have no problem with leveraging the fact that you need to keep your site up-to-date manually (without automatic updates) as a selling point of their services.

I can't tell if this is supposed to be a snarky dig at capitalism, or a legitimate concern. If it's snarky, then touché. :) I'll assume it's legitimate though.

In that case, I can certainly see companies continuing to perform the updates and verifying that they performed as intended, and didn't break anything.

Automatic updates would likely not work with version control (although, I'm sure something could be scripted), so if a "proper" dev shop built the site utilizing Git, I don't see why they shouldn't make it apparent that enabling auto updates voids their support contract, since it would be performed outside of their development workflow.

Just my initial thoughts.

First off, I have really enjoyed some of your podcasts. Thank you!

I've thought a lot about updates and here are some wrinkles, info:

-One thing, the WP auto-update is minor releases only. Not major releases.

-There was a lot of WP developer fear when this was announced, but it has worked out well. There are very few issues.

-I took a look at the links suggested above about auto updates, file ownership and permissions. The idea seemed to be that auto updates are bad because you have to give Apache permission to write core files. While not a guru on this issue, I popped over to the WP codex to check. The info there says that when you do auto updates the files are owned by the user and not the web server. So, maybe there is a way to be safe and add these features.


-Besides the 'auto' update option, in Drupal we have the ability to manually update modules and themes from within admin, but not core. Your dad, for example, might be comfortable updating from within admin, while not by using FTP or drush.

Best regards

I will start by saying I am not qualified to speak of the technical requirements to make such a thing happen. However, as a user of the AEgir hosting system and Pantheon, I see how third parties (as opposed to core) could be leveraged to tackle the issue. AEgir has full control of the platform, mostly utilizing Drush, and can upgrade sites from Git repos manually with Drush Make. Seems like it could probably be built to automatically build a new platform and migrate a site under configured circumstances. Additionally, Pantheon had a fix ready to roll right away and all I had to do was click a button to deploy the patch. Seems like a great selling point for them to build some rules that would go ahead and push through security updates that meet configured criteria. Finally, both of these systems are capable of backing up the site before deployment. It seems a backup would be a key aspect of any such system.

Reading through the current conversation on d.o. there are some interesting points on file permissions and shared hosting. Seems like an auto update solution would be best suited for these scenarios, as automatic updates would most likely conflict with more robust deployment methods. Perhaps the communities efforts would be better suited towards working with shared hosts and helping them develop tools to make such a thing happen on their end? I realize there are thousands of shared hosts, but this would definitely be a defining factor in helping people find real "Optimized for Drupal" hosts.

So, a fundamental software security maxim is that software should not rewrite itself. Only the developer should modify the software, otherwise the software is exploitable to unknown lengths.

When you develop software, say websites/apps, then you are the responsible manager of the software not the software or whatever frameworks/libraries you built on. When those thing update, then it's up to you to use newer versions.

When we talk about Chrome, then the Chrome Dev Team is the developer, your computer is one of the servers, and you are the end-user. The relationship is perhaps the inverse of what you thought, but mirrors the relationship when you publish mobile apps.

Now, getting back to WP which has developed a solution for what I'll call the ProAm market. In that market users typically have a single instance of the production site, but maybe a development copy. These users may allow the web-server to modify the source, which allows for downloading plugins, themes, and updates.

The danger here is not that they can break they're site, of course they can do that. The danger is that an attacker can break their site. Theoretically, if an attacker found a vector, like SQL injection or XSS, they could convince the site to download an "update" from their malicious site, and rewrite source. It's such a danger, that professional sites typically leave a web app's source only write able to via their deployment automation software. Locking down the individual developers, who could themselves be compromised.


Anyway, my point is not that Drupal shouldn't do it, it is in fact a cool feature. My point is that it's no silver bullet for Drupaggedon.

Very interesting points you guys mentioned here. I agree that the update process needs a tight integration with the development workflow, Git in particluar. For this reason Drupal cannot update itself. Depending on the update criticality different update processes may be triggered (no tests required for critical security updates to follow the "security first" philosophy, but automated or even manual tests for all other update types).
Some Drupal guys are evaluating services and ways to help Drupal users with security updates. You can join the discussion at groups.drupal.org/node/465588

Wordpress in general would be thought of as insecure, but for the most part, Wordpress websites run just fine. The auto update feature isn't perfect, but with incremental changes over time, they will have solved the security flaws. Drupal devs should stop being so scared and just work towards a solution. It doesn't have to auto update contrib plugins, but having a way to auto update and have it work, would save money in the long run. No more having to pay someone to apply an update. Although, you would still have to pay someone to test that the update didn't break anything. But there are many sites out there that it might not matter. I would like to see progress made to allow for auto updates, or at least, a better way of updating Drupal sites from the browser. We need to stop being so scared and come up with a solution.