[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:53 spacedmonkey]:
 > Saving the value in popular network, stops the need for it checking in
 the bootstrap process.

 The issue with this is that multi-network setups out there possibly use
 `populate_network()` to fill their additional networks with settings, and
 `populate_network()` actually supports that (you can pass a network ID,
 and if the setup is not yet a multisite, the new network will copy some
 settings from the current network. Therefore your current patch will
 essentially enable the option on every network for those setups. We should
 either wrap it in a conditional `if ( ! is_multisite() )` to only do it
 for the first network, or remove it completely (I'm in favor of the
 latter). The performance benefit of looking up the table directly just
 once is really negligible IMO.

 > `is_site_meta_supported` is designed to lazy detect if table exists. The
 first to access that function will populate the value and the response is
 cached in network options forever more.

 Right. That actually means that we don't even need to populate the main
 network option anywhere. Just wait until someone calls
 `is_site_meta_supported()` for the first time, and it's set.

 > I still think it much better to have the setting on each network. It
 means you can disable site meta per network, which something you might
 want to do if are lots of networks, such as WordPress.com.

 I don't think there should be a way to disable it per network. Either you
 install the table, or you don't - the table is global, so the setting
 (which I do not consider a setting, but just a flag) should be global too
 (of course it isn't actually global here, but the main network idea is the
 workaround we figured out). Working with cases where site meta is not
 supported may be painful enough in the future, and allowing to disable it
 per network would overcomplicate that even further.

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