<p>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.</p>

<p>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.</p>

<p>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.  </p>

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

<p>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.</p>

CC BY-SA 3.0
2014-07-16T10:27:59.893Z
Thanks Ben, great advice - assessing each project individually based on budget and implementation details seems like a good way to go.
Alex H
CC BY-SA 3.0
2014-07-15T15:33:14.830Z
2014-07-15T15:33:14.830Z
Ben Parizek
<p><a href="https://craftcms.stackexchange.com/a/1123/57">Ben gives some good practical updating advice.</a></p>

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

<p>Just adding my 2 cents on top of that.</p>

<p><strong>First, some background:</strong></p>

<p>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.</p>

<p>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 "<a href="https://mariadb.com/kb/en/mariadb/mariadb-vs-mysql-compatibility/" rel="noreferrer">drop in</a>" 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.</p>

<p>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.</p>

<p><a href="http://www.hanselman.com/blog/EverythingsBrokenAndNobodysUpset.aspx" rel="noreferrer">Everything is broken</a>.  <a href="http://techcrunch.com/2014/03/29/the-internet-is-held-together-with-bubble-gum-and-baling-wire/" rel="noreferrer">It's amazing software works at all</a>, <a href="https://medium.com/message/everything-is-broken-81e5f33a24e1" rel="noreferrer">much less the Internet.</a></p>

<p>How is a simple PHP script meant to survive is such as harsh world?!</p>

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

<h2>Auto-updating stats</h2>

<p><strong>Hard numbers:</strong></p>

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

<p><strong>Soft, touchy-feely, by-the-gut numbers:</strong></p>

<ul>
<li><p>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.</p>

<p>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... <a href="http://php.net/manual/en/ini.core.php#ini.memory-limit" rel="noreferrer">memory_limit</a> and <a href="http://php.net/manual/en/info.configuration.php#ini.max-execution-time" rel="noreferrer">max_execution_time</a> being the most common.</p>

<p>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 <a href="http://buildwithcraft.com/docs/config-settings#backupDbOnUpdate" rel="noreferrer">backupDbonUpdate</a> config setting.</p>

<p>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 <a href="http://www.yiiframework.com/" rel="noreferrer">Yii</a>, 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 <a href="http://buildwithcraft.com/docs/updating#manually-updating" rel="noreferrer">manual update</a> during those times, since that can finish executing quicker than an auto-update would.</p>

<p>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 <a href="http://www.fastcgi.com/mod_fastcgi/docs/mod_fastcgi.html" rel="noreferrer">FastCGI</a> don't allow PHP scripts to use <a href="http://php.net/manual/en/function.ini-set.php" rel="noreferrer">ini_set()</a> in order to increase them at runtime.</p></li>
<li><p>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.</p></li>
<li><p>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).</p></li>
</ul>

<h2>Does Craft practice safe-updating?</h2>

<p>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.</p>

<ol>
<li><p>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.</p></li>
<li><p>Craft will unzip that file to a temp location, grab the <code>RequirementsChecker</code> 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.</p></li>
<li><p>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.</p></li>
<li><p>Craft will now make a backup of all of the files/folders it's about to update by coping them from <code>fileName.php</code> to <code>fileName.php.bak</code> or <code>folderName</code> to <code>folderName.bak</code>.  If the update deleted a file/folder, it still gets a backup created.  If a failure occurs here, it's a non-rollback failure.</p></li>
<li><p>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.</p></li>
<li><p>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.</p></li>
<li><p>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.</p></li>
<li><p>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.</p></li>
</ol>

CC BY-SA 3.0
2014-07-15T22:49:16.227Z
This answer > $0.02.
Matt Stein
CC BY-SA 3.0
2014-07-15T22:59:09.157Z
Holy moley batman. I would love to see this in a white paper format/docs for clients. Such good stuff here.
Adam McCombs
CC BY-SA 3.0
2014-07-15T23:11:43.540Z
You've got my vote Brad!
Ben Parizek
CC BY-SA 3.0
2014-07-15T23:12:25.077Z
You've got my heart, @BenParizek.
Brad Bell
CC BY-SA 3.0
2014-07-15T23:13:42.740Z
Upvoting the hell out of that answer.
Steve Abraham
CC BY-SA 3.0
2014-07-15T23:41:04.533Z
Thanks for that Brad, a really comprehensive answer that alleviates my concerns. I realise this could never be a 100% bullet-proof process but I do think it's a great feature and I know in the small chance that something does go wrong you guys would be straight on the ball with a fix!
Alex H
CC BY-SA 3.0
2014-07-16T04:37:57.343Z
Brad for president.
Anna_MediaGirl
CC BY-SA 3.0
2014-07-16T06:07:04.980Z
On fire today, are we?
Jérôme Coupé
CC BY-SA 3.0
2014-07-16T14:40:36.430Z
One problem I've run into with WordPress is updates failing to clear the APC opcode cache.
TRiG
CC BY-SA 3.0
2014-07-15T22:28:35.090Z
2014-07-16T11:13:07.497Z
2017-04-13T12:50:59.930Z
Brad Bell
<p>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.</p>

<p>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.</p>

<p>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?</p>

<p>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?</p>

<auto-updates>
How safe is auto-updating?
# How safe is auto-updating?

(Asked by: username_0 on 2014-07-15)

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?

**Tags:** auto-updates


---

## 2 answers

### Answer by username_2 on 2014-07-15. Score: 69 | Accepted answer

[Ben gives some good practical updating advice.](https://craftcms.stackexchange.com/a/1123/57)

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](https://mariadb.com/kb/en/mariadb/mariadb-vs-mysql-compatibility/)" 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](http://www.hanselman.com/blog/EverythingsBrokenAndNobodysUpset.aspx). [It's amazing software works at all](http://techcrunch.com/2014/03/29/the-internet-is-held-together-with-bubble-gum-and-baling-wire/), [much less the Internet.](https://medium.com/message/everything-is-broken-81e5f33a24e1)

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](http://php.net/manual/en/ini.core.php#ini.memory-limit) and [max\_execution\_time](http://php.net/manual/en/info.configuration.php#ini.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](http://buildwithcraft.com/docs/config-settings#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](http://www.yiiframework.com/), 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](http://buildwithcraft.com/docs/updating#manually-updating) 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](http://www.fastcgi.com/mod_fastcgi/docs/mod_fastcgi.html) don't allow PHP scripts to use [ini\_set()](http://php.net/manual/en/function.ini-set.php) 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.

> **Comments:**
> **username_3**: This answer > $0.02.  
> **username_4**: Holy moley batman. I would love to see this in a white paper format/docs for clients. Such good stuff here.  
> **username_1**: You've got my vote Brad!  
> **username_2**: You've got my heart, @BenParizek.  
> **username_5**: Upvoting the hell out of that answer.  
> **username_0**: Thanks for that Brad, a really comprehensive answer that alleviates my concerns. I realise this could never be a 100% bullet-proof process but I do think it's a great feature and I know in the small chance that something does go wrong you guys would be straight on the ball with a fix!  
> **username_6**: Brad for president.  
> **username_7**: On fire today, are we?  
> **username_8**: One problem I've run into with WordPress is updates failing to clear the APC opcode cache.  

---

### Answer by username_1 on 2014-07-15. Score: 16

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.

> **Comments:**
> **username_0**: Thanks Ben, great advice - assessing each project individually based on budget and implementation details seems like a good way to go.  

---

