mysqli_query call in wp-includes/wp-db.php generates fatal error during first run of WP with PHP 8.1

[lovingboth]

Server: new upgrade of Ubuntu 20.04 to Ubuntu 22.04. As part of this, PHP 8.1 replaced PHP 7.4

Download latest.tar.gz, unzip, create empty database, plus setup access passwords etc.

On first run, rather than see the 'which language' start of the install process, there's a white screen. Apache 2.4 error log says

Got error 'PHP message: PHP Fatal error: Uncaught mysqli_sql_exception: Table '[site-specific]wp_options' doesn't exist in /home/user/public_html/[site]/wp-includes/wp-db.php:2056

It turns out that with PHP 8.1, this is what mysqli_query does by default when it can't find a table.

(See, for example ​https://php.watch/versions/8.1/mysqli-error-mode)

Adding

mysqli_report(MYSQLI_REPORT_OFF); /* fixes install */

immediately before line 1056 stops it from doing so, and the install proceeds as normal. What that does on earlier versions that are out of support as far as the PHP devs are concerned, like 7.4, I don't know.

It is possible that not doing any wp-config.php setup prior to the first run would mean that WP notices that there's no database access somewhere else and avoids this, but that's not many people's workflow. I would be shocked if some control panels' automated installations did not set up wp-config.php prior to the first run, for example.

[SergeyBiryukov]

Hi there, welcome back to WordPress Trac! Thanks for the report.

I could not reproduce the issue on PHP 8.2.3 or 8.1.16, the installation is completed as expected in my testing.

The proposed line was already added to wpdb::db_connect() in [51582] / #52825, though it only runs if the $use_mysqli property is true. Some more information about the particular environment would be helpful here, specifically whether WP_USE_EXT_MYSQL is set in wp-config.php.

PHP Fatal error: Uncaught mysqli_sql_exception: Table '[site-specific]wp_options' doesn't exist in /home/user/public_html/[site]/wp-includes/wp-db.php:2056

The version of WordPress would also be helpful. Line 2056 suggests WordPress 5.8 here, as that appears to be the last version with the mysqli_query() call​ on that line. In the later versions, the function call was moved around, and the whole file was renamed to class-wpdb.php for WordPress 6.1 in [53749] / #56268.

So if WordPress 5.8 is indeed used here, I would suggest testing with the latest version, as this would likely be fixed for WordPress 5.9 and later versions in [51582] / #52825.

Possibly related: #51988.

[lovingboth]

I would be absolutely certain that it was 6.1.1 - this was a new install (hence it not finding the table) from a download of latest.tar.gz yesterday - and in my terminal scroll back, I can still see the editor saying it's editing public_html/site/wp-includes/wp-db.php around that line..

.. except that if I look now, that file is only 450-odd bytes long and if I do a grep, I cannot find that added line anywhere on the server.

Trying again reveals another change (in something that was never guaranteed to stay the same between versions, it just had for many, many years) since the last time I did an install has gently broken the script I use to set up WP sites and an old latest.tar.gz was being unzipped..

.. so, yes, it was an old version of WP with the problem. At some point in the puzzling, it must have been overwritten, possibly via the automatic updates the script enables?

Argh, my fault, not WP's.

Thank you and how do I remove the evidence of my fallibility? :)

[SergeyBiryukov]

Thanks for the follow-up! No worries, glad you were able to identify and resolve the issue :)