I have auto-updating currently disabled using the "allowAutoUpdates" config setting, due to concerns about plugin compatibility and unforeseen breakages, mainly due to experiences with other CMS's.

However, I'm starting to feel that having that button available for clients to update automatically is very tempting, especially as the number of Craft installations to keep up to date increases.

How safe is this mechanic to enable? For example, if a client was to auto-update and there was a breakage, and the database was not able to roll back to a previous version? Surely you can't guarantee that the internal API won't change in the future, and if it ever does, how can the auto-update feature prevent plugin breakages?

And if I was to enable it, would this just be a case of adding the app folder to my .gitignore and not including it in my git repo?

2 Answers 2


Ben gives some good practical updating advice.

And I agree with him that for the majority of cases, the best practice is to update locally, then push to production.

Just adding my 2 cents on top of that.

First, some background:

Being a self-hosted PHP web application is a hard life. Your parents try to raise you correctly and equip you with the tools necessary to successfully go out into the world and live on some stranger's unknown, unfriendly and oftentimes hostile server environment so you can serve up web pages, but things are stacked against you.

For any given 1,000 web hosting providers, you will find 2,500 different environmental configurations... at least. Different Linux distributions each with their own different libraries and versions. Windows servers running IIS... or Apache. Different permissions and user/group setups for each account. Different versions of Apache and all of its modules... or nginx. Different MySQL versions each with different configurations. Or "drop in" MySQL replacements that the host doesn't mention they're using, that's actually not a drop in replacement. Or hosts that decide it's a good idea to store PHP sessions in memcached.

You'll find yourself living on fully-managed servers where you have limited to zero control of what you can do. On boxes administered by weekend sysadmin warriors, running the bleeding edge of every piece of software on their box, because they read it on HackerNews. You'll live on overloaded, underperforming, $5/month shared hosting accounts where the host has crammed 400 sites on one box and you get blamed for being slow.

Everything is broken. It's amazing software works at all, much less the Internet.

How is a simple PHP script meant to survive is such as harsh world?!

Now that we've painted this picture of a horrible, bleak universe that Craft has to live in, let's look at some stats:

Auto-updating stats

Hard numbers:

  • Craft has successfully sent out over 8,100 auto-update requests.
  • 94% of Craft installs with recent control panel usage are running Craft 2.
  • Since launch, we've received roughly 2,000 Craft-related support tickets.
  • About 370 of those tickets have been related to updating.

Soft, touchy-feely, by-the-gut numbers:

  • Of those 370 updating support tickets, I'd guess 90% of them fall into environmental issues that are mostly outside of Craft's control, but Craft tries to deal with as gracefully as possible.

    Usually the culprits are either a) permissions aren't setup correctly and Craft can't download the update patch file, unzip it, or write to the craft/app folder to actually update the files b) during the update, Craft runs into a php.ini limitation... memory_limit and max_execution_time being the most common.

    Both of these can be an issue if they are set low (32M and 30 seconds on older PHP installs or stingy hosts), or the size of your database has grown large enough that when Craft tries to automatically back it up during an update, it bumps into them. That's a reason we added the backupDbonUpdate config setting.

    We'll also see a spike in update errors related to these settings during bigger Craft updates (like 1.3 => 2.0) when we'll do an update to Yii, for example, that touches thousands of files. More files in an update = more time to process the update = more of a chance of bumping into a limit. Some people might prefer to do a manual update during those times, since that can finish executing quicker than an auto-update would.

    Craft will also try to increase these limits for itself at runtime during potentially long running or memory intensive operations like updating, but that doesn't always work. Some hosts have hard limits on them and things like FastCGI don't allow PHP scripts to use ini_set() in order to increase them at runtime.

  • 5% of those tickets are related to bugs in a database migration that the update needs to run. This usually occurs when we overlook some way that someone is using Craft and usually get fixed quickly.

  • The remaining 5% of the tickets were related to bugs in the updating logic in Craft itself. We saw a few of these back in the 1.0, 1.1 and maybe 1.2 days, but honestly haven't ran into one in quite awhile (knocks on wood).

Does Craft practice safe-updating?

I think so. We've got some ideas to try and further bullet-proof the process, but this is how it stands currently and is working out pretty well.

  1. When Craft downloads an update patch file, it first validates the MD5 hash of the file to make sure that the file it received is the one it expected and nothing got corrupted during the transfer. If a failure occurs here, we consider that a non-rollback failure - meaning, a failure has occurred, but no files have been updated, the database hasn't been touched and the site is still online - so no harm, no foul.

  2. Craft will unzip that file to a temp location, grab the RequirementsChecker script from the recently unzipped file and run it, so that if any new requirements were added to be able to run Craft, and your server doesn't support them, you'll get a message stating so. If a failure occurs here, it's a non-rollback failure.

  3. From the recently unzipped patch file, Craft will validate that all of the paths that it's about to update are still writable by PHP. If a failure occurs here, it's a non-rollback failure.

  4. Craft will now make a backup of all of the files/folders it's about to update by coping them from fileName.php to fileName.php.bak or folderName to folderName.bak. If the update deleted a file/folder, it still gets a backup created. If a failure occurs here, it's a non-rollback failure.

  5. The recently updated files get coped over to their new homes. If a file was deleted during the update, it gets deleted at this point. If a failure occurs here, it's a file-only rollback failure and Craft will attempt to take all of the recently backed-up .bak files and put them back in their proper place and put the site back online. The database hasn't been touched at this point.

  6. If Craft is configured to backup the database during update, this is the point where a database backup gets created. If a failure occurs here, it will do a file-only rollback.

  7. If the update came with any new database migrations (alter table schema, and/or data) to run, this is the point where they run. If a migration fails, or any other error occurs, this is a full-rollback failure and Craft will attempt to restore the database from the backup it just made in step 6 to its last known working state, as well as perform the file rollback.

  8. If we've made it this far, we're almost done. All that is left is housekeeping. Craft will try to delete all of the .bak files it created as well as flush various bits of info from cache. If a failure occurs at this point, technically the upgrade is finished, so we don't attempt any rollback.

  • 8
    This answer > $0.02.
    – Matt Stein
    Commented Jul 15, 2014 at 22:49
  • 4
    Holy moley batman. I would love to see this in a white paper format/docs for clients. Such good stuff here. Commented Jul 15, 2014 at 22:59
  • 2
    You've got my heart, @BenParizek.
    – Brad Bell
    Commented Jul 15, 2014 at 23:12
  • 2
    Upvoting the hell out of that answer. Commented Jul 15, 2014 at 23:13
  • 1
    Brad for president. Commented Jul 16, 2014 at 4:37

We just had a client auto-update a Wordpress site, run into plugin conflicts, and bring their whole site down. The Wordpress Wikipedia page references "dead simple installation and upgrade" being added in January 2004, which is over 10 years ago at the time of this posting.

I think someone can speak more extensively to the checks and fallbacks Craft has in place (or is planning to add), and I don't doubt that the makers of Craft, and the folks at WordPress, take one-click upgrades seriously and do their best to make the process pretty seamless and comfortable in most use cases.

For small, low-risk sites, where the owner doesn't have an ongoing budget, it may be worth it to let them take that risk. For anything where not taking the site offline matters, or that has a maintenance budget, I think the best approach is to have a developer test the update in a development environment first and push things live once it has been confirmed everything works smoothly.

The more plugins (or other variables) you have on your site, the more you should probably opt for the manual approach.

In either case, I'd make it very clear to clients that a one-click update is not a promise of youth and beauty and flawlessness. It might come pretty close, it might be pretty tempting, and I'm sure it will improve; but Craft and the plugins and servers and networks and options around it will constantly be evolving and one-click update will have to evolve with them.

  • 2
    Thanks Ben, great advice - assessing each project individually based on budget and implementation details seems like a good way to go.
    – Alex H
    Commented Jul 16, 2014 at 10:27

Not the answer you're looking for? Browse other questions tagged or ask your own question.