[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                     |      Status:  new
 Priority:  normal                              |   Milestone:  Awaiting
Component:  Networks and Sites                  |  Review
 Severity:  normal                              |     Version:
 Keywords:  2nd-opinion has-patch dev-feedback  |  Resolution:
                                                |     Focuses:  multisite
------------------------------------------------+--------------------------

Comment (by flixos90):

 Replying to [comment:24 andy]:
 > > it would be nice to be able to query for sites using some kind of
 other arbitrary method
 >
 > There is no need to move the primary source of truth into a global
 table. What you need is secondary index that covers all of the data you
 are interested in and supports an acceptable level of consistency.

 From my POV there is a difference to be made between a site's metadata and
 site options:
 * I'd describe metadata as two things: first, it's miscellaneous data that
 is associated with the site (for example `post_count` or `db_version`);
 second, it's what we'd put into the main database table if we had the
 possibility to always adjust it to our needs (which we obviously don't)
 (for example `blogname` and `blogdescription`) - only the first is what I
 would actually consider meta even if we had the possibility to put it into
 the main table. The latter is actually data that describes the site in a
 network context (core also treats these in a special way, see the 4 extra
 "properties" in `WP_Site` or `get_blog_details()`).
 * Options however are what their name implies, they define how a piece of
 functionality on the site works rather than providing some kind of
 identification for it.

 My approach would therefore be to migrate (i.e.) move the "almost-site"
 data and site metadata into `blogmeta` as the source of truth. Everything
 else is options and thus can remain as is. Proxying `*_option()` calls to
 `blogmeta` for the moved values would only need to happen for backward-
 compatibility. So I don't consider that table an implementation of a
 secondary index, although I have to admit we started discussing that
 because of the lack of a possibility for querying by these values. But I
 assume the reason this has not come up before is that we rather not touch
 things if we don't actually need a new functionality from them.

 > There is prior art in multisite search via external indexes. Proponents
 of a core patch should explore the needs, solutions and problems already
 understood by those who have done it. Use cases might differ too much to
 make a unified solution viable.
 >
 > I have browsed 37923-phase1.diff and it looks like quality code but I'm
 not convinced any of this is better than adding or improving the API for
 plugins.

 What I stated above is obviously my opinion, maybe the general concensus
 ends up in this ''being'' a means to a secondary index only. I'm certainly
 open to introducing the feature in a flexible manner, for example by
 supporting override via a drop-in. I think however the underlying
 functionality will be essential for parts of multisite, therefore core
 should provide a default solution to the problem.

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