Make WordPress Core

Opened 2 years ago

Last modified 17 months ago

#54801 new defect (bug)

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

Reported by: schlessera's profile schlessera Owned by:
Milestone: Future Release Priority: normal
Severity: normal Version: 3.0
Component: Database Keywords: has-patch
Focuses: Cc:

Description (last modified by 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.

Change History (15)

This ticket was mentioned in PR #2148 on WordPress/wordpress-develop by schlessera.

2 years ago

  • Keywords has-patch added

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

This ticket was mentioned in Slack in #core by schlessera. View the logs.

2 years ago

#3 @schlessera
2 years ago

  • Description modified (diff)

#4 @schlessera
2 years ago

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

#5 @schlessera
2 years ago

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

Version 0, edited 2 years ago by schlessera (next)

#6 @schlessera
2 years ago

The changeset in [51358] already has a history of being reverted due to unexpected breakage caused by the additional error output:

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:

Last edited 2 years ago by SergeyBiryukov (previous) (diff)

#7 @hellofromTonya
2 years ago

  • Milestone changed from Awaiting Review to 6.0
  • Version changed from trunk to 3.0

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:

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.

Last edited 2 years ago by hellofromTonya (previous) (diff)

This ticket was mentioned in Slack in #cli by schlessera. View the logs.

2 years ago

#9 @hellofromTonya
2 years ago

  • Keywords reporter-feedback added

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

This ticket was mentioned in Slack in #core by hellofromtonya. View the logs.

2 years ago

This ticket was mentioned in Slack in #core by hellofromtonya. View the logs.

2 years ago

This ticket was mentioned in Slack in #core by peterwilsoncc. View the logs.

2 years ago

#13 @hellofromTonya
2 years ago

  • Keywords reporter-feedback removed

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.

#14 @costdev
23 months ago

  • Milestone changed from 6.0 to 6.1

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.

#15 @davidbaumwald
17 months ago

  • Milestone changed from 6.1 to Future Release

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.

Note: See TracTickets for help on using tickets.