Update for WordPress 4.2.2: The issue is still real. The fix described below still works. The new db_version is 31535.
When you upgrade to WordPress 4.2, it will automatically convert the tables to utf8mb4, if the following conditions are met:
- You’re currently using the utf8 character set.
- Your MySQL server is version 5.5.3 or higher (including all 10.x versions of MariaDB).
- Your MySQL client libraries are version 5.5.3 or higher. If you’re using mysqlnd, 5.0.9 or higher.
This is to improve the support for all the weird characters in the world. You can read more about it on the Make WordPress Core blog.
This upgrade is done when you try to log in. You may have noticed the following screen while doing so:
Database upgrade for WordPress 4.2
Normally you just click to upgrade and that’s it. But on a lot of our websites the operation timed out. So our clients were complaining they can’t get to their website.
The thing is PHP is only allowed to work for 30 seconds and that’s not enough. Increasing to 60 seconds or even 120 didn’t helped. WordPress executes a lot of database queries during this process and it doesn’t record which were finished properly. So if it won’t finish the operation in 30 seconds, it’s as if it never even started.
How to fix this
That’s why we came up with this shell script which lets you execute the upgrade from the server command line. The advantage is that command line PHP is not restricted to the 30 seconds run time:
php -d display_errors=1 -r "\$_SERVER['HTTP_HOST'] = 'your-domain.com'; define('WP_USE_THEMES',false); define('WP_CACHE',false); \$_GET['step'] = 1; include 'wp-admin/upgrade.php';"
This might take minutes, your database tables will get locked and nobody will be able to use the site properly. So you should schedule this for low traffic hours. Also WordPress shows some information about the process once it’s one. In our case we got:
- fairly small site – 943 pages, 1,453 posts, 1,396 comments, 55 users
- 211 queries
- 134.605 seconds
- medium-sized membership site – 467 posts, 9,762 galleries, 30,646 comments, 10,870 users
- 211 queries
- 454.606 seconds
- medium-sized news site – 12,136 posts, 65,531 comments, 6,028 members
- 213 queries
- 228.980 seconds
- medium-sized cooking website – 914 posts, 45,557 comments
- 258 queries
- 140.365 seconds
- big product review site – 2,004 posts, 507 products, 246,004 comments
- curiously enough, this website managed to do the database upgrades in to 30 seconds limit
Quick fix
If you want to avoid the database upgrade quickly, you can set db_version to 31533 and then revert it back once you are ready to do this. Don’t postpone this upgrade until forever as you might get into trouble with later WordPress versions.
Martin Viceník
Martin graduated as an engineer in Computer Science from Slovak Technical University in Bratislava. He grew up in Liptovský Mikuláš in northern Slovakia next to the beautiful Tatra mountains. He is the developer behind our FV Player.
True hero… thanks! I will publish this one in Dutch. There are only a limited number of people who are pushing WordPress to the limit, I am one of them. I ran this on a website with a 2 gb WordPress database, took for ever but worked!
I did not have shell access, so I created a new cronjob using CPanel, and run the command using php5 not php, because php didn’t have the r option. include ‘wp-admin/upgrade.php’ and this must be the full path, like: /home/yourdomain/public_html/wordpress_path/wp-admin/upgrade.php
Thanks for this! It did the trick for me. And just a note to the previous comment: If you put the script in the root directory of your web site and then cd over to that directory before executing the script, there’s no need to put in the full path.