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

 Replying to [comment:45 spacedmonkey]:

 Thanks for updating the patch! A small detail I just noticed is that the
 `@access` tag in `wp-db.php` should be removed (see #41452). I have some
 responses to your latest comments:

 > No longer move formatting.php in wp-settings.php. Only move
 `sanitize_key` as it is used in meta api

 Ah, I just wasn't sure why you moved the `formatting.php` file loading
 order, but as `sanitize_key()` is used, I think we should leave it in that
 file and just load it earlier (like you did in [attachment:37923.3.diff]).
 Sorry for the confusion there.

 > Fixed formatting

 What do you mean with this?

 > I don't agree with the use of get_network_option. I personally prefer
 network_options of course, but it is a function that will remain in core
 forever and can now just be considered a helper function.

 Although `*_site_option()` will probably remain in core for a long time,
 or even forever, I think we should use the latest versions of functions in
 core code itself, so I'm leaning towards `*_network_option()`. But that is
 only a small detail, so I don't have a strong opinion on that.

 > As for get_site_meta returning false if not supported, this is how
 get_term_meta works. Forcing false is a nice way to return that site meta
 is disabled and not result in false positives.

 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.

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