A recent update of PHP broke one of my oldest WordPress blogs. It was set up with an offset for the timezone, which is no longer supported. What it looked like was the white screen of death, but enabling debug mode in my wp-config.php gave me some hints.
The first hint that it was something weird is that all of my other blogs, which all run off of the same database, were all fine. I can look at their settings, log into their administration interfaces, change their settings, but my old blog would not load.
After considerable DuckDuckGo-ing, I figured out the setting that needed to be fixed, but because I couldn’t load the administration interface, I could not fix the setting. Access to all of your WordPress settings is inside the database, so I had to figure out how to change that setting directly in the database, preferably without ruining everything.
The option was timezone_string, but if you don’t know how the database is laid out, you have to do some poking before you can get yourself sorted.
All of the options are in a table called options, or in my case, since I have multiple WordPress blogs in the same database, there is a prefix underscore first. I found this by logging into the database engine, navigating to the correct database, and then using the show tables; command.
mysql -u $BLOGDATABASEUSERNAME -p
use $BLOGDATABASENAME;
show tables;
show columns from $BLOGNAME_options;
The next wrinkle was interpreting the results – they lay out the columns vertically, which isn’t very intuitive, since we definitely asked for columns, and they are shown as rows. Still, it is standard, and looks like this:
| Field | Type | Null | Key | Default | Extra |
| option_id | bigint(20) unsigned | NO | PRI | NULL | auto_increment |
| option_name | varchar(191) | YES | UNI | NULL | |
| option_value | longtext | NO | NULL | ||
| autoload | varchar(20) | NO | MUL | yes |
I was then able to figure out that I need to change the option_value for the row with the option_name timezone_string. Since I want to figure out what to change it to, I tried this:
select option_value from $BLOGNAME_options where option_name='timezone_string';
That showed me the problem that I was seeing in the debug messages. Then I looked at the timezone_string from one of the blogs that wasn’t broken, which in that case was “America/Toronto”. Then I finally had enough information to update the option_value to (hopefully) fix my ailing blog. So, I ran this:
update $BLOGNAME_options set option_value = 'America/Toronto' where option_name = 'timezone_string';
And it worked! It took too long, and was stressful and annoying, and made me wish that all of these options were in a flatfile, ’cause doing this with no interface is annoying, and completely beyond the average blog-haver, I think.
If the whole blog is going to go down from a borked option, maybe the blog should load a default set of options and then tell the user which options to fix.