Sometimes upgrading WP is catastrophic: critical plugins don’t work any more (and new compatible versions don’t exist yet).
What do the WP veterans do about it? Do they upgrade WP after the boring work of backing up everything (and the horrible, awful perspective of having to reinstall the previous version after a potential catastrophe) or do they just never upgrade WP?
“the boring work of backup”…
Backups may be boring, but they are essential and gives you a fallback position in case things go wrong. Without backups, you’re essentially playing Russian roulette with your site. It doesn’t even take very long, and reverting isn’t horrible or awful, it’s pretty easy.
WP veterans take backups, test upgrades on non-production servers, and when they’re happy do the upgrade. Most ‘ordinary’ people don’t have access to multiple servers or even local development environments, in which case the best way to mitigate your risk is to have a backup
If you have access to the command line, then doing a complete backup is as easy as:
tar czvf yoursite_backup.tar.gz /path/to/your/wordpressmysqldump -u <username> -p <database name> > mysqlbackup.sqlReverting is as easy as unarchiving your WP backup to your WP directory and importing the MySQL dump into your database.
I do backups via shell (see Grep and Friends for some commands and examples). File and database backup runs within seconds even on larger sites and stuff is easy to restore. No need to worry about backups and upgrade crashes at all.
In a perfect world all plugins and themes would have been already tested with the new WP version before I upgrade, well, but that’s not always the case. So I just do always the backup. It’s easy, it’s fast and it’s save. Let the upgrade crashes come, I don’t fear them.
You just have a problem with upgrade crashes if you don’t backup. That easy it is.
If you dislike making back-ups, don’t upgrade. Instead backport security fixes to your old version. That doesn’t mean you need to take care for everything on your own, you can go with the debian package for example.
The wordpress project itself does not offer a long-term-support version, not even support for the pre-lastest version, only support for the latest version. A bit pushy on upgrades so.
So if you want a more relaxed journey, don’t jump on the first release. Skip the .0. Wait until the .1 is out. That’s a good rule of thumb since years with WordPress.
always keep a local copy of your site that you can test any upgrades on first.
Because I have a Theme and several Plugins in the WPORG repositories, I start running nightlies as soon as Beta hits, so that I can test for compatibility issues. I have yet to run into any kind of issue.
However, I do daily, automatic backups of my DB, so if something goes horribly wrong with an upgrade, no worries; just re-install the previous version, and import the DB. There’s really no reason to think of backups as “boring” (there are plenty of Plugins to automate it), or restoring an older version of WP as an “awful perspective” (the install process really is 5 minutes).
What I would consider to be an “awful perspective” would be the thought of having to recover from my site being hacked due to a failure to keep WordPress updated whenever a new version is released. That would certainly take far longer than a 5-minute re-install.
I trust in my server side backups of SQL databases.
I was using the plugin for the past 2 years DBC-Backup-2 and I always manually run a backup before running any core update.
This plugin hasn’t had any love for the past couple of years so I’ve now revived the plugin and re-released it as I think it does the job it needs to do.
Hats off to Lester Chan and his plugins http://lesterchan.net/portfolio/programming/php/#wp-dbmanager as I think these are the bees knees for database stuff
I also trust in my local MAMP or virtual linux box to test core updates
It is not that hard to get a local webserver running on your pc.
The apple air even comes pre-installed with a server, so as far as I am concerned there is no exscuse not to have a local test server at the very least. having at least one remote test site is also useful.
I kept a nightly beta version going as well as the last 2 stable versions with copies of all the plugins that I use on sites activated.
All versions point to the same wp-content folder, so the same versions of the plugins are tested in all versions of wp.
I update regularly so that there is no big jump in functionality.
One must simply factor in the overhead of all of that.