[wp-trac] [WordPress Trac] #54801: Avoid WPDB errors when examining installation state of a site/network

WordPress Trac noreply at wordpress.org
Wed Jan 12 15:15:04 UTC 2022


#54801: Avoid WPDB errors when examining installation state of a site/network
--------------------------+-----------------------------
 Reporter:  schlessera    |      Owner:  (none)
     Type:  defect (bug)  |     Status:  new
 Priority:  normal        |  Milestone:  Awaiting Review
Component:  Database      |    Version:  trunk
 Severity:  normal        |   Keywords:
  Focuses:                |
--------------------------+-----------------------------
 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.

 [[Image(https://p141.p3.n0.cdn.getcloudapp.com/items/xQuzDx5J/af6ecbf1-e74a-4237-82d6-47cb0b18fd26.jpeg?v=d5c251cf4ad17f9c808bdf8394034636)]]

 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.

-- 
Ticket URL: <https://core.trac.wordpress.org/ticket/54801>
WordPress Trac <https://core.trac.wordpress.org/>
WordPress publishing platform


More information about the wp-trac mailing list