[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
-------------------------------------------------+-------------------------
Changes (by flixos90):

 * keywords:  has-patch dev-feedback has-unit-tests needs-testing ms-roadmap
     => has-patch has-unit-tests needs-testing ms-roadmap


Comment:

 Replying to [comment:41 spacedmonkey]:

 I reviewed [attachment:37923.3.diff]. It looks good for the most part, I
 just have a few notes about fixes/suggestions:

 > Removed references to meta_query. Works on this functionality should
 continue here #40229

 The changes from `blog_id` to `$wpdb->blogs.blog_id` can be removed too,
 plus there's some incorrect indentation in that file.

 > Added a new network option when site meta is installed. This is similar
 to how `ms_files_rewriting` was handled in core.

 Let's further think about this. It's a good initial approach, but this is
 the most complex problem that we need to solve. One thing that should be
 changed is that the `*_site_meta()` functions should use
 `get_network_option()` instead of `get_site_option()`. `get_site_option()`
 is outdated and confusing especially being used there, where `site_meta`
 means site meta and `site_option` actually means network option. If we're
 really precise, we actually also need to pass the correct network ID for
 the site for which metadata is requested, but I don't see a reasonable way
 to do that. I'm wondering whether we should put a higher priority on our
 global storage discussion from last week. It would help a lot with this
 too. Let's bring it up in next office-hours.

 > Moved *_site_meta function into the option.php file. This means plugin
 developers can use the functions on none multisite sites with getting
 function exists errors. We may think about falling back to options table
 on non multisite.

 I'm strongly against this. What benefit does it have to move the functions
 to `option.php`? They are multisite-only, so they should reside in a
 multisite file. For now it should be located in `ms-blogs.php`, and later
 be moved into `ms-site.php`, as suggested in #40647, which would bring the
 location in line with the other meta functions (all of which are located
 in the file specific to their object type).

 > - Moved formatting.php and meta.php earlier in bootstrap. See #37181

 I'm fine with this being included in the patch, since it's needed, however
 as a reminder, this should be committed separately in advance, as part of
 #40948. Why is `formatting.php` moved too? Is that required somewhere?

 Another thing that needs to be fixed is that `get_site_meta()` must not
 return `false`, but an empty array or string, depending on the `$single`
 parameter. This is weird, but `get_metadata()` works like that, so it
 should use that same return type.

 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.

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