Avoid WPDB errors when examining installation state of a site/network

[schlessera]

When trying to discover whether a given site is already installed properly or still needs to have its installation routine triggered, the queries that are executed by default generate a two WPDB errors on empty sites that cannot easily be avoided:

• Enumeration of site IDs triggers an error for the missing wp_blogs table;
• Setting of the site name property triggers an error for the missing wp_sitemeta table.

This is an operation that is commonly done via WP-CLI, and while the errors do not change the outcome (i.e. the check will fail either way), they do fill up the logs unnecessarily for an operation that should be safe to do.

I'd suggest doing a quick check on these fundamental operations to see if the tables are present before manipulating them.

Performance considerations

The suggested fix (see PR that will follow) adds two DB requests which, even though they should be very cheap, should be properly cached to ensure no important negative performance impact.

The alternative would be to change the logic in WPDB so that it can be silenced for operations that are known to be failing in an expected manner. However, that seems like a major change throughout multiple parts of the code.

I'm happy to discuss alternative ways of fixing this, as I'm not too happy with introducing two DB requests like that.

I suggest using $wpdb->suppress_errors() around the two problematic calls to avoid showing these errors.

This PR adds two safeguards to avoid WPDB errors on site/network discovery:

1. Check for existence of wp_blogs table before enumerating site IDs;
2. Check for existence of wp_sitemeta table before loading $site_name from DB.

This adds two (hopefully cheap) database requests, so I'm happy to discuss alternative ways of solving this problem (WPDB throwing errors for an operation that seems necessary).

Trac ticket: #54801

[schlessera]

The PR description is not up-to-date, please see the description on GitHub for a recap of what it does.

[schlessera]

The root cause of why these errors started cropping up with the 5.9 release cycle is because of the changes in https://core.trac.wordpress.org/changeset/51358. The errors have always been present, was error reporting was completely disabled when the multisite files were being loaded.

[schlessera]

The changeset in [51358] already has a history of being reverted due to unexpected breakage caused by the additional error output: https://core.trac.wordpress.org/ticket/11742#comment:22

Given that we are this late in the cycle and there might still be other breakage caused by this that we haven't surfaced yet, the suggestion would be to:

1. Revert [51358] to get the error reporting in multisite back to what it was with 5.8.
2. Start early in the 6.0 cycle to fix error reporting again, in tandem with an audit on the database accesses that might potentially produce unexpected error output depending on the state of the WordPress installation.

See full discussion on Slack: ​https://wordpress.slack.com/archives/C02RQBWTW/p1642033761079000

[hellofromTonya]

Thank you @schlessera for reporting this error.

The underlying bug(s) were not introduced in 5.9 cycle, but rather have existed since 3.0. As you noted, error reporting was turned on in [51358] which explains why this error is showing in 5.9 but not in 5.8 or early.

As 5.9 is in RC and a deeper dive is needed, I agree with:

• reverting [51358] in #53493
• moving #53493 and this ticket to 6.0 (as you noted)

As the bug is from 3.0, changing the version on this ticket to match.

Update on 17 Jan 2022:
After further discussion and testing, current thinking is: [51358] in #53493 is not the root cause of this problem. Investigation to find the root cause is ongoing.

[hellofromTonya]

@schlessera can you share the step-by-step process to reproduce the issue please?

[hellofromTonya]

Summarizing initial testing and investigation work that ​happened in #core slack between @peterwilsoncc and @costdev:

With a default wp-config.php setup, running these cli commands results in errors on multiple WordPress versions going back into 4.2 (as far back as they tested):

wp db --yes reset
wp core is-installed

Adding define( 'MULTISITE', true ); gives .wp_site table errors.

Adding these constants changes the errors to .wp_blogs and .wp_sitemeta tables:

define( 'MULTISITE', true );
define( 'DOMAIN_CURRENT_SITE', 'localhost' );
define( 'PATH_CURRENT_SITE', '/' );
define( 'BLOG_ID_CURRENT_SITE', 1 );

Root cause is unknown and will require further investigation.

As these errors are reproducible on multiple versions of WordPress and do not seem to be introduced in 5.9, leaving this ticket in 6.0 for further investigation, testing, and hopefully resolution.

[costdev]

As this touches WPDB and installation, and we past 6.0 Beta 1 with no progress on this ticket, I'm moving this to 6.1 so that the PR can be tested and any potential further investigation can be done.

[davidbaumwald]

From reading the discussion above, any apparent change here should be addressed earlier in a cycle, before the Beta phase.

As 6.1 Beta 2 just released today and no documented momentum gained during the 6.1 cycle, this is being moved to Future Release. If any maintainer or committer feels the resolution could be addressed in a specific cycle and wishes to assume ownership, feel free to update the milestone accordingly.