Make WordPress Core

Opened 2 years ago

Last modified 19 months ago

#54936 new defect (bug)

db_version mismatch after update to 5.9

Reported by: mtruglio's profile mtruglio Owned by:
Milestone: Awaiting Review Priority: normal
Severity: normal Version: 5.9
Component: Upgrade/Install Keywords: reporter-feedback
Focuses: Cc:

Description

Hello, is my first time submitting feedback to the team to apologies if I got anything wrong in the process.

I run a small hosting company with just over 150 WordPress sites hosted on both Apache2 and Nginx; VPS and Shared; Exclusively WordPress.

I noticed after a few sites auto updated and then their /wp-admin/* links were all redirecting to 404.

After ruling out our various hosting environments and checking the files and DB. We found the /wp-includes/wp-version.php for 5.9 didn’t match the db_version value in the database on the failing sites post update.

When I manually set the db_version to match the wp-version.php file the redirect stopped and the site loaded without clearing any caches.

However, this wasn’t the case on all our sites. Most of them updated normally.

Here’s a quick list of db_version values that broken out by what worked, and what didn’t.

if initial_db_version then breaks

49752,33055,24448

if initial_db_version then works

48748,43764,44719

WP 5.9 found in /wp-includes/wp-version.php

db_version: 51917

I hope it helps the WP team even if in a small way. Thanks for the years of dedicated work on this project, it has made my small company possible! 🙂

Change History (3)

#1 @peterwilsoncc
2 years ago

  • Keywords reporter-feedback added
  • Severity changed from major to normal

Hi @mtruglio and welcome to trac.

Immediately after upgrading but prior to logging in to the admin, it's expected that the database versions do not match in the options table and the file wp-includes/version.php.

The redirect when visiting a wp-admin URL is also expected, it should redirect to wp-admin/upgrade.php to prompt the user to run the database upgrade. After this, the db versions in the options table and the file should match.

Are you able to confirm the following:

  • was visiting wp-admin/ returning a 302 redirect to wp-admin/upgrade.php
  • was wp-admin/upgrade.php return the correct, 200 response -- was the file present if not?

I've added the reporter-feedback keyword to this ticket, feel free to remove once you've replied with the above. You can do so in the section below the comment preview.

Thanks
Pete

#2 follow-up: @mtruglio
2 years ago

Hey Pete,

Thanks for the quick response. :)

Everything I experienced with these sites worked exactly as you describe, except instead of a 302 to "wp-admin/upgrade.php" I get a 302 to "/wp-admin/upgrade.php?_wp_http_referer=%2Fwp-admin%2Fabout.php%3Fupdated" which then responds 404.

The wp-admin/upgrade.php file is present in the install after updating.

All other permalinks on the site seem to be working normally. Only the wp-admin area is inaccessible.

#3 in reply to: ↑ 2 @pixolin
19 months ago

Replying to mtruglio:

Everything I experienced with these sites worked exactly as you describe, except instead of a 302 to "wp-admin/upgrade.php" I get a 302 to "/wp-admin/upgrade.php?_wp_http_referer=%2Fwp-admin%2Fabout.php%3Fupdated" which then responds 404.

Similar issue here after updating from WordPress 5.9.1 to 6.0.1.

In a plain vanilla test installation I am forwarded to https://wp.test/wp-admin/upgrade.php?_wp_http_referer=%2Fwp-admin%2Findex.php and get a 403 Forbidden error in the browser. Database field db_version shows 51917, which according to https://core.trac.wordpress.org/browser/tags/5.9.1/src/wp-includes/version.php is the db version number of 5.9.1. The field isn't changed during the upgrade process.

An attempt to access the backend fails with another 403 error.

After changing the db_version manually to 53496, I get full access to the backend.

A user reported [another issue](https://de.wordpress.org/support/topic/keinen-zugriff-auf-das-dashboard/) where changing the db_version manually solved the problem of missing access.

Note: See TracTickets for help on using tickets.