[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 boonebgorges):

 > I noticed that get_term_meta() does that, but I assumed that happened
 mistakenly - @boonebgorges Can you weigh in on this? I consider false an
 unexpected return value for that function (although the docs state
 "mixed"). If someone runs get_site_meta() with $single = false like the
 default, they should safely be able to assume it's an array. I think we
 should rather fix that in get_term_meta() and do it right here. Returning
 a different value just to indicate the table is not installed sounds like
 a hacky workaround for me, we should rather introduce something like
 is_site_meta_supported() if necessary.

 From my recollection, I/we considered returning `WP_Error` in the case
 that the tables weren't yet installed, but decided not to because there's
 already a convention for returning `false` from meta functions on "error"
 conditions. See https://core.trac.wordpress.org/browser/tags/4.8.1/src/wp-
 includes/meta.php?marks=463,468#L461. Speaking personally, I have done `if
 ( false === get_*_meta() )` checks to distinguish between failures and
 null results. I don't particularly like this pattern, and I wish that more
 descriptive return values were returned, but that was the reasoning.
 Changing existing functions to return something other than `false` in case
 of failures is going to be very problematic, so I lean in favor of
 following the pattern with new functions, but I could probably be
 convinced otherwise.

 > A random question, not related to the patch: Where do the database
 versions actually come from? Is that a changeset number? Just highlighting
 since we're randomly using 40001 in here.

 Yes, the committer should bump it to the relevant commit number at the
 time that the code is committed.

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