WordPress Changeset 42836 introduces conflict with BuddyPress `blogmeta` table

[needle]

​WordPress Changeset 42836 introduces the $wpdb->blogmeta table into core. Existing multisite BuddyPress installs with the Site Tracking component active already have the $wpdb->bp_user_blogs_blogmeta table installed and refer to it via the blogmeta property of the $wpdb object.

There are two consequences of this:

1) The WordPress "Upgrade Network" routine fails to install the core $wpdb->blogmeta table because is_site_meta_supported() erroneously reports true due to the existence of the $wpdb->bp_user_blogs_blogmeta table.

2) Queries performed after BuddyPress alters $wpdb throw SQL errors of the following form:

[16-May-2018 10:14:16 UTC] WordPress database error Unknown column 'meta_id' in 'order clause' for query SELECT blog_id, meta_key, meta_value FROM wp_bp_user_blogs_blogmeta WHERE blog_id IN (2,3,4) ORDER BY meta_id ASC made by require_once('wp-admin/network/admin.php'), require_once('wp-admin/admin.php'), do_action('admin_init'), WP_Hook->do_action, WP_Hook->apply_filters, _wp_admin_bar_init, WP_Admin_Bar->initialize, get_blogs_of_user, get_sites, WP_Site_Query->query, WP_Site_Query->get_sites, _prime_site_caches, update_site_cache, update_sitemeta_cache, update_meta_cache

The query above is intended for the $wpdb->blogmeta table but gets routed to the $wpdb->bp_user_blogs_blogmeta table instead.

tl;dr BuddyPress and/or WordPress need a disambiguation exercise to resolve this name clash.

[DJPaul]

Ouch. Nice spot @needle.

BP_Blogs_Component->setup_globals() ($meta_tables) --> BP_Component->register_meta_tables()

[DJPaul]

I've gone left a comment over at ​#WP37923.

[needle]

Replying to DJPaul:

I've gone left a comment over at ​#WP37923.

@DJPaul Thanks for doing that.

[DJPaul]

This won't impact us until WP 5.0 ships, so there's no need to rush it into 3.0.

[needle]

@DJPaul Any thoughts on how to develop with WordPress and BuddyPress bleeding edge in the meantime?

[DJPaul]

No helpful ones. 🙃

[imath]

@needle on a fresh install i'd probably try to filter 'bp_blogs_global_tables' and return array( $GLOBALS['wpdb']->blogmeta )

[r-a-y]

bp_blog.patch renames our existing blog meta entry to $wpdb->bp_blogmeta.

This is a quick patch to ensure no conflicts for WP 5.0, but currently means that there are two blog meta tables -- WP's version and our version.

The alternative approach would probably mean migrating our existing blog meta data to WP's new blogmeta table, but we would have to wait until WP 5.0 for this.

[needle]

@r-a-y Patch works without a hitch here. Thanks!

[imath]

Thanks a lot for your work on the patch @r-a-y I’m in favor of using the WordPress generated table as it’s a bit too bad to have the same table twice with a different name 😊.

Instead of prefixing the table name, the meta keys could be BP prefixed if there are some fears to introduce a mess with plugins that could use similar meta key names :)

I also think, it could be a nice opportunity to have an upgrade tool to fix some other areas like favorites one of these days 😉

[r-a-y]

Thanks for the feedback, @imath.

Instead of prefixing the table name, the meta keys could be BP prefixed if there are some fears to introduce a mess with plugins that could use similar meta key names :)

We do need to prefix the table name if we're keeping a separate blog meta table due to how WordPress looks for the global property in the $wpdb global in _get_meta_table():
​https://core.trac.wordpress.org/browser/branches/4.9/src/wp-includes/meta.php?marks=42,47,904#L889

However, if we decide to migrate our data to WP's blog meta table, then prefixing the meta key should be doable. When we do the migration, we would change all our meta keys to add our prefix. Then in our blog meta functions, we would just automatically add the prefix during lookups to avoid breaking existing blog meta entries.

I also think, it could be a nice opportunity to have an upgrade tool to fix some other areas like favorites one of these days 😉

Agreed!

[DJPaul]

Let’s have this ticket focus on fixing the existing implementation, if only because that’s quicker to get done, and doesn’t involve changing to require a new version of WordPress.

[DJPaul]

Milestone renamed

[djpaul]

In 12173:

Blogs: rename meta table key for compatibilty with ​#WP37923

The WordPress change introduces a blogmeta table in WordPress 5.0.
It uses $wpdb->blogmeta to access the table name, which is what BuddyPress has been using.

This'll be a breaking change for any manual SQL queries as soon as WP 5.0 is released.
When BuddyPress requires 5.0, we can look at migrating table content over, but that is some ways in the future.

Fixes #7834

Props needle, r-a-y

[johnjamesjacoby]

In 12180:

Meta: Prefer internal table references over $wpdb ones.

This change updates a few direct database queries to reference the database table names internally set by BP_Component rather than what's been passed into the $wpdb global.

We want to use these everywhere, as they are already in use everywhere else direct queries are made.

Blogs, Groups, and Messages meta deletion functions are affected.

See #7834.

[johnjamesjacoby]

We should consider doing this for all of the other meta data tables to avoid similar collisions.