Skip to:
Content

Opened 8 months ago

Closed 7 months ago

Last modified 7 months ago

#7834 closed defect (bug) (fixed)

WordPress Changeset 42836 introduces conflict with BuddyPress `blogmeta` table

Reported by: needle Owned by: djpaul
Milestone: 4.0 Priority: normal
Severity: normal Version:
Component: Blogs Keywords: dev-feedback
Cc: needle

Description

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.

Attachments (1)

7834.bp_blog.patch (8.9 KB) - added by r-a-y 8 months ago.

Download all attachments as: .zip

Change History (18)

#1 @DJPaul
8 months ago

Ouch. Nice spot @needle.

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

#2 follow-up: @DJPaul
8 months ago

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

#3 in reply to: ↑ 2 @needle
8 months ago

Replying to DJPaul:

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

@DJPaul Thanks for doing that.

#4 @DJPaul
8 months ago

  • Milestone changed from Awaiting Review to 3.1

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

#5 @needle
8 months ago

  • Cc needle added

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

#6 @DJPaul
8 months ago

No helpful ones. 🙃

#7 @imath
8 months ago

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

Last edited 8 months ago by imath (previous) (diff)

@r-a-y
8 months ago

#8 @r-a-y
8 months ago

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.

#9 @needle
8 months ago

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

#10 @imath
8 months ago

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 😉

#11 @r-a-y
8 months ago

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!

#12 @DJPaul
8 months ago

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.

This ticket was mentioned in Slack in #core-multisite by jeremyfelt. View the logs.


8 months ago

#14 @DJPaul
8 months ago

  • Milestone changed from 3.1 to 4.0

Milestone renamed

#15 @djpaul
7 months ago

  • Owner set to djpaul
  • Resolution set to fixed
  • Status changed from new to closed

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

#16 @johnjamesjacoby
7 months ago

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.

#17 @johnjamesjacoby
7 months ago

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

Note: See TracTickets for help on using tickets.