id,summary,reporter,owner,description,type,status,priority,milestone,component,version,severity,resolution,keywords,cc 7834,WordPress Changeset 42836 introduces conflict with BuddyPress `blogmeta` table,needle,djpaul,"[https://core.trac.wordpress.org/changeset/42836 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.",defect (bug),closed,normal,4.0,Blogs,,normal,fixed,dev-feedback,needle