[wp-trac] [WordPress Trac] #37923: Introduce shared wp_blogmeta database table for multisite installation

[WordPress Trac]

#37923: Introduce shared wp_blogmeta database table for multisite installation
-------------------------------------------------+-------------------------
 Reporter:  johnjamesjacoby                      |       Owner:
     Type:  feature request                      |  spacedmonkey
 Priority:  normal                               |      Status:  assigned
Component:  Networks and Sites                   |   Milestone:  4.9
 Severity:  normal                               |     Version:
 Keywords:  has-patch has-unit-tests needs-      |  Resolution:
  testing ms-roadmap                             |     Focuses:  multisite
-------------------------------------------------+-------------------------

Comment (by flixos90):

 [attachment:37923.8.diff] makes the following changes:

 * Introduce an optional `$force` parameter for `is_site_meta_supported()`
 to allow developers to bypass the option lookup and run a direct query to
 the database. This parameter should only be used to detect whether the
 database exists after specific changes that could possibly have installed
 it have occurred.
 * Return a boolean instead of integer from `is_site_meta_supported()`.
 * Run the `is_site_meta_supported` filter before the actual logic to allow
 short-circuiting. Developers can use that filter to bypass the database
 lookups completely and also to prevent the network setting from being
 populated at all.
 * Add verbose documentation to `is_site_meta_supported()` so that
 developers know how its internals work and how they can modify it.
 * Do not set the `site_meta_supported` network option in
 `populate_network()`, since it should only be set on the main network.
 This furthermore allows setups using the `is_site_meta_supported` filter
 to not have to deal with that main network option at all.
 * In `upgrade_network()`, call `is_site_meta_supported()` with the
 `$force` parameter set to true, so that the database is checked directly,
 and the main network option is set accordingly. Similar to the above, when
 using the filter, the main network option is not even populated.
 * Keep the `sanitize_key()` function in `formatting.php`, and load the
 file earlier. People using the meta API may possibly use other functions
 from that file, and since it's loaded a bit later anyway, I don't think
 there are any performance implications for loading it earlier.
 * Load `WP_Meta_Query` and `WP_Metadata_Lazyloader` earlier as well, since
 they are part of the meta API. Note that this should eventually be
 committed through #40948.
 * Fix spacing in `WP_Site_Query` class to account for the new parameter.
 Makes a lot of code churn, but I thought we should include it sooner than
 later.
 * Bring back the original tests for site meta from
 [attachment:37923.diff], and adjust a few things to account for the new
 `is_site_meta_supported()` function. The actual site meta tests are
 skipped in case the table is not available. This should not commonly
 happen, but will ensure the tests are stable and do not produce unexpected
 errors.

--
Ticket URL: <https://core.trac.wordpress.org/ticket/37923#comment:57>
WordPress Trac <https://core.trac.wordpress.org/>
WordPress publishing platform