• The ‘signups’ table is always prefixed by $wpdb->base_prefix, but BuddyPress prefixes it with the return from bp_core_get_table_prefix(), resulting in queries on a non -existent signups table on non-main networks.

    I’ve asked for an additional filter in BuddyPress to prevent this. The following code in BP Multi Network works for me to restore functionality that requires querying the signups table:

    function ra_bp_multinetwork_filter_signups_table_prefix( $prefix ) {
    	global $wpdb;
    
    	if( $wpdb->siteid > 1 ) {
    		return $wpdb->base_prefix;
    	}
    
    	return $prefix;
    }
    add_filter( 'bp_signups_table_prefix', 'ra_bp_multinetwork_filter_signups_table_prefix' );

    Thanks for a really useful plugin.

    https://ww.wp.xz.cn/plugins/bp-multi-network/

Viewing 6 replies - 1 through 6 (of 6 total)
  • Plugin Author Ron Rennick

    (@wpmuguru)

    That’s something that should be fixed in BuddyPress.

    The original table name prefix filter in BP was not applied to global WordPress tables, just the BP ones. BP creates its tables on activation if the tables don’t exist but it does not attempt to create any of the global WP tables.

    As a result, with the BP Multi-Network plugin active BP creates new BP tables for each network but corresponding WP tables are not created.

    Thread Starter Christian Wach

    (@needle)

    That’s something that should be fixed in BuddyPress.

    Well, sort of, IMO. That’s why I opened the ticket and why the filter will be added. The current BuddyPress code works just fine in all situations except in a BP Multi Network context, so it seems reasonable that this plugin should handle this logic (i.e. ensuring the correct signups table is queried) in a multi-network context.

    The original table name prefix filter in BP was not applied to global WordPress tables, just the BP ones.

    The signups logic was introduced in 8119 and has been present since March 2014. I guess no-one has thus far noticed the resultant SQL errors when BP Multi Network is enabled.

    BP creates its tables on activation if the tables don’t exist but it does not attempt to create any of the global WP tables.

    True for multisite and multi-network, though in single site mode BuddyPress will create the signups table from the supplied WordPress schema.

    As a result, with the BP Multi-Network plugin active BP creates new BP tables for each network but corresponding WP tables are not created.

    Quite so, which is why this additional code is needed to point BuddyPress to the global signups table. It doesn’t seem sensible for BuddyPress to have to tease out a this particular context before querying the signups table.

    I’ll raise your concerns on the ticket.

    Plugin Author Ron Rennick

    (@wpmuguru)

    though in single site mode BuddyPress will create the signups table from the supplied WordPress schema.

    Right, so if it did the same in multisite mode then all would be ok.

    It doesn’t seem sensible for BuddyPress to have to tease out a this particular context before querying the signups table.

    https://buddypress.trac.ww.wp.xz.cn/ticket/2561 is the ticket where I wrote & submitted the patch for the original bp_table_prefix filter. In the ticket I explain the use case/purpose for the filter.

    Thread Starter Christian Wach

    (@needle)

    Having thought about this further, I’m inclined to agree with you that BuddyPress is incorrectly filtering the table prefix for the ‘signups’ table. I assume that the prefix will always be $wpdb->base_prefix regardless of the network from which it’s being queried, so I’ll amend the patch on 5762 appropriately and will close this if the BP devs agree. Thanks for your help in clarifying the situation.

    Thread Starter Christian Wach

    (@needle)

    BuddyPress has now made the necessary change and committed it. Thanks for your help Ron.

    Plugin Author Ron Rennick

    (@wpmuguru)

    Awesome 🙂

Viewing 6 replies - 1 through 6 (of 6 total)

The topic ‘Filtering table prefix for 'signups' table produces SQL errors’ is closed to new replies.