[wp-trac] [WordPress Trac] #37923: Introduce shared wp_blogmeta database table for multisite installation (was: Introduce shared wp_blogmeta database table for multisite installations)

WordPress Trac noreply at wordpress.org
Thu Feb 2 21:40:01 UTC 2017


#37923: Introduce shared wp_blogmeta database table for multisite installation
--------------------------------+------------------------------
 Reporter:  johnjamesjacoby     |       Owner:
     Type:  feature request     |      Status:  new
 Priority:  normal              |   Milestone:  Awaiting Review
Component:  Networks and Sites  |     Version:
 Severity:  normal              |  Resolution:
 Keywords:  2nd-opinion         |     Focuses:  multisite
--------------------------------+------------------------------

Comment (by spacedmonkey):

 Blogmeta has to be the name, as the meta api needs that naming
 conversation to work. It is also a better naming, make everything be meta.
 The name is really unimportant for a table.

 So I don't think that it should be a copy of options table. Storing
 transient and rubbish options plugins add in this table seems a little
 pointless. We should have an array of key names (option names) that is
 filter able that are copied over. We can only copy over useful data that
 way, but plugin creates add data where desired. The list of option should
 be heavily vetted, but home URL, site URL and blog title are a sure thing
 for me.

 Keeping the data betweeen the data two tablessynced  is going to be
 interesting. But we if hook in on the add_option / edit_option /
 delete_option actions in the option functions on multisite, you can use
 get_current_blog_id and also save data blog meta table. This means that
 unless there are plugins that are touching options table directly (which I
 am sure there are), if the correct functions are used, everything is fine.

 Roll out for this functionality is going to be hard. We can create the
 table on upgrade, but the first time sync would be pretty painful on a
 massive multisite. Maybe it would have to work the term split. Creating a
 single cron event for each site to sync the data over. The roll out will
 need a lot of thought. I willing to help with this ticket..

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


More information about the wp-trac mailing list