• Resolved mzandstra

    (@mzandstra)


    Is this a bug in the most recent update or an issue specific to my environment? I have upgraded 10+ sites recently and they all break predictably with the same error.

    Secondly, is my fix the best solution or should we be changing the version in the database rather than version.php?

    Taken from my post at: https://mzandstra.com/wordpress/how-to-fix-wp-admin-timeout-or-dashboard-not-loading/

    5. Check database version
    A mismatch in the database version will cause /wp-admin to get stuck in a loop. The most recent WordPress update seems to break this. Check the database version like this:

    mysql> use your_database_name;
    mysql> select * from wp_options where option_name='db_version';
    +-----------+-------------+--------------+----------+
    | option_id | option_name | option_value | autoload |
    +-----------+-------------+--------------+----------+
    | 52 | db_version | 22441 | yes |
    +-----------+-------------+--------------+----------+
    1 row in set (0.01 sec)

    Compare this to the version in /wp-includes/version.php on line 14:

    $wp_db_version = 22442;

    If there’s a mismatch, change the value in /wp-includes/version.php to match the database value. Normally, you should never edit the contents of /wp-includes or /wp-admin but it seems that database version doesn’t get updated in /wp-includes/version.php like it should during the update.

Viewing 8 replies - 1 through 8 (of 8 total)
  • Thread Starter mzandstra

    (@mzandstra)

    Apologies, I thought I had found something but I’m told this is specific to my environment.

    I updated over 15 sites across multiple servers and didn’t get a single problem in one of them. so, this is specific to your installs. Are they all on the same server? Or with the same hosts? Have you tried:
    – switching to the default theme by renaming your current theme’s folder inside wp-content/themes and adding “-old” to the end of the folder name using FTP or whatever file management application your host provides.

    resetting the plugins folder by FTP or phpMyAdmin.

    – backing up your database

    – re-uploading all files & folders – except the wp-content folder – from a fresh download of WordPress. Make sure that you delete the old copies of files & folder before uploading the new ones.

    – running the upgrade manually via wp-admin/upgrade.php

    Thread Starter mzandstra

    (@mzandstra)

    Thanks for response. I resolved the incidents, but not the problem. This is a dedicated server by the way.

    I can fix this on all the sites by changing the database version in /wp-includes/version.php. After the upgrade, the database version in there doesn’t match what I get from the MySQL CLI. Does version.php need to be web-writable, or maybe the wp-includes folder (not recursive)?

    version.php should have the same permissions as all other WordPress files – 644. all folder should be 755.

    Thread Starter mzandstra

    (@mzandstra)

    The permissions look fine. I’m running Apache + mpm-itk so the permissions are a little different but even with the entire site Apache-writable the error still occurs.

    With mpm-itk, the apache thread for this vhost actually runs as user.

    [user@httpd public]$ getfacl wp-includes/
    # file: wp-includes/
    # owner: user
    # group: user
    user::rwx
    group::---
    other::---
    
    [user@httpd public]$ getfacl wp-includes/version.php
    # file: wp-includes/version.php
    # owner: user
    # group: user
    user::rwx
    group::---
    other::---

    Edit: The DB version for 3.5.2 is 22442 correct? That would mean that the DB version in the database is the one that didn’t get changed. Any idea why that would (not) happen?

    Before upgrade (version.php)
    $wp_db_version = 22441;

    After upgrade (version.php)
    $wp_db_version = 22442;

    Before upgrade (mysql)
    db_version | 22441

    After upgrade (mysql)
    db_version | 22441

    The DB version for 3.5.2 is 22442 correct?

    Yes.

    Any idea why that would (not) happen?

    Nothing that is really going to be of much help. On the face of it, it would seem that something stopped the database from being upgraded – which throws into doubt other values in the db. Now, this time, you should be OK as very little was changed between 3.5.1 and 3.5.2 (or so I was assured recently) but it is worrying.

    Did you switch to the 2012 theme and deactivate all plugins before upgrading? I have known of situations where a theme or (more usually) a plugin retains a connection to 1 or more db tables. This may stop the db from upgrading correctly.

    In some cases where this has definitely happened and the user has a wsod, I’ve managed to talk them through a manual upgrade by first getting them to rename the current theme to activate the default one, resetting the plugins folder by FTP or phpMyAdmin and then running wp-admin/upgrade.php

    In most cases, the result has been a successful upgrade and a site back online. It might be worth trying this on one or more of your sites when 3.6 comes out as there will be fairly big db changes then.

    Just out of curiosity, when did you last repair all of the db tables?

    Thread Starter mzandstra

    (@mzandstra)

    Thanks for the info. This a hosting environment, so manual upgrades aren’t ideal, but I will look into that.

    I haven’t done any db table repairs. A lot of these were brand new installs at 3.5.1, even running the default theme without plugins. I would hope that repairs aren’t needed right out of the gate ??

    I’ll do some further research and post here if I find anything.

    Thread Starter mzandstra

    (@mzandstra)

    I discovered what was causing the updater to fail. It was actually a DNS misconfiguration. I came across it when I was doing an upgrade on a multisite install and got the error:

    Warning! Problem updating https://thesubdomain.site.com. Your server may not be able to connect to sites running on it. Error message: couldn’t connect to host

    I added /etc/hosts entries for the site and it upgraded with no problem. Thankfully multisite is more verbose about upgrade errors than single-site WordPress, or I never would have figured it out. I added Google’s DNS servers to resolv.conf and that fixed it across the board.

Viewing 8 replies - 1 through 8 (of 8 total)
  • The topic ‘WordPress bug?’ is closed to new replies.