[wp-trac] [WordPress Trac] #37923: Introduce shared wp_blogmeta database table for multisite installation
WordPress Trac
noreply at wordpress.org
Wed Mar 22 00:31:35 UTC 2017
#37923: Introduce shared wp_blogmeta database table for multisite installation
------------------------------------------------+--------------------------
Reporter: johnjamesjacoby | Owner:
Type: feature request | Status: new
Priority: normal | Milestone: Awaiting
Component: Networks and Sites | Review
Severity: normal | Version:
Keywords: 2nd-opinion has-patch dev-feedback | Resolution:
| Focuses: multisite
------------------------------------------------+--------------------------
Changes (by flixos90):
* keywords: 2nd-opinion has-patch => 2nd-opinion has-patch dev-feedback
Comment:
I have spent some time on a first patch ready to apply to trunk, based on
our discussions.
As discussed, the site meta project will have 3 (or 4) stages:
1. Introduce `wp_blogmeta` database table, its surrounding site meta API
and related functionality like meta query support in `WP_Site_Query`,
however none of this should be used by core at this point. The list of
core site meta keys should be used as a blacklist so that developers
cannot store their own site meta values for these keys.
2. Migrate the core site meta keys from their options tables to the
`wp_blogmeta` table and keep them in sync (`*_site_meta()` should also
update `*_site_option()` and vice-versa). There's still some discussion to
do regarding whether we should sync at all or only migrate (delete options
immediately and only provide a fallback so that `get_option()` calls
`get_site_meta()`). If we end up syncing, it will only be a temporary
solution to make sure things work, before we actually remove the options a
few versions later.
3. Start making use of the site meta query functionality in core.
4. If in 2. it was decided to sync the core keys instead of only moving
them from options to site meta, we should at this point stop syncing and
actually perform the migration.
For the next version we'll likely only need stage 1, and that is what I
implemented in https://github.com/jeremyfelt/wordpress-develop/pull/3. I
also provided it as a regular patch with [attachment:37923-phase1.diff],
so that you can easily apply it to trunk.
The stages 2-3 (or 4) will likely end up in follow-up tickets later.
--
Ticket URL: <https://core.trac.wordpress.org/ticket/37923#comment:19>
WordPress Trac <https://core.trac.wordpress.org/>
WordPress publishing platform
More information about the wp-trac
mailing list