Skip to:

Opened 10 years ago

Closed 8 years ago

#5762 closed defect (bug) (fixed)

WP Multi Network plugin & BP 2.0.1 signup

Reported by: summoner's profile summoner Owned by: r-a-y's profile r-a-y
Milestone: 2.5 Priority: normal
Severity: normal Version:
Component: Core Keywords: dev-feedback has-patch commit
Cc: needle@…


Hi there,
Hello there,

I have a WP 3.9.1 MU installation with WP Multi Network activated. Network 1 has a site A which is public and BuddyPress is not activated on this network. Here i need just the usual WP registration. There is also a Network 2 with site B on it (This is a subdomain of Network 1). On this second network BuddyPress 2.0.1 is installed.

I noticed that new users are always signed up as pending users on Network 2 even if they register themselves on site A which is a part of Network 1. If they activate themselves, they will become members of Network 1 assigned to site A and will be even members of Network 2 but not assigned to site B until they log in on site B. However when they log in to site B they become an assigned member of both site A and site B. It is totally unexpected for me. Can you confirm this bug? Is there any code i could use to signup users only to the Network and site they registered on beeing able to keep them separated?

Any help/hint is very welcome!


Attachments (2)

5762.patch (619 bytes) - added by needle 9 years ago.
5762-1.patch (870 bytes) - added by needle 9 years ago.

Download all attachments as: .zip

Change History (13)

#1 @r-a-y
10 years ago

  • Milestone Awaiting Review deleted
  • Resolution set to invalid
  • Status changed from new to closed

You will need a BuddyPress plugin that supports WP multi-network. BP core does not handle this functionality.

Here are some that are available:

Note that I haven't tested these. If there are bugs when using either of those plugins with WP multi-network, please inform those plugin developers and if they find an issue with BP core, please tell them to post a ticket.

I'm going to mark this as invalid for now.

Last edited 10 years ago by r-a-y (previous) (diff)

#2 @needle
9 years ago

  • Resolution invalid deleted
  • Status changed from closed to reopened

I'm reopening this as I believe it is a valid ticket.

Scenario: WP Multi Network, BP Multi Network, BuddyPress activated on a network that is not the main network.

When a signup occurs (or is attempted) on a network that is not the main network, BuddyPress cannot locate the signups table because the value of buddypress()->members->table_name_signups is set incorrectly.

BP Multi Network works in part by filtering bp_core_get_table_prefix to create new BuddyPress tables per network, so there are tables specific to that network "attached" to the main site of that network. So, for example, we get tables such as 'wp_12_bp_activity', 'wp_12_bp_activity_meta', etc etc. However, the 'signups' table does not have the same $wpdb->base_prefix but is always on the original network, i.e. at 'wp_signups'.

The issue here is that the value of buddypress()->members->table_name_signups is set to bp_core_get_table_prefix() . 'signups' (line 106 of bp-members/bp-members-loader.php). Therefore it looks to me as though either:

  • bp_core_get_table_prefix() needs a param passed to it so it can be optionally filtered, or
  • there needs to be a filter at line 106 of bp-members/bp-members-loader.php. Something like:
'table_name_signups' => apply_filters( 'bp_signups_table_prefix', bp_core_get_table_prefix() . 'signups' ),

The latter option seems less intrusive and would allow BP Multi Network to correctly address the 'signups' table on the main network.

Am happy to attach a patch if a suitable filter name can be agreed or suggested.

#3 @needle
9 years ago

  • Cc needle@… added

#4 follow-up: @r-a-y
9 years ago

However, the 'signups' table does not have the same $wpdb->base_prefix but is always on the original network, i.e. at 'wp_signups'.

It appears that BP Multi Network's purpose is to share the same user base across the network:

If the users are the same across the entire network, then it sounds like the signups table should be the same across the entire network as well. This might be a better question for the the WP Multi-Network plugin. How does that plugin handle the wp_signups table?

Misread your post! Does bp_core_get_table_prefix() even need to be added to buddypress()->members->table_name_signups?

Regardless, I think we could add a filter for devs that need this.

Last edited 9 years ago by r-a-y (previous) (diff)

#5 in reply to: ↑ 4 @needle
9 years ago

Replying to r-a-y:

Misread your post!

To be fair, I may have misread the original ticket as well!

I'm not entirely sure the issue I identified is actually the cause of the behaviour described by @summoner. On re-reading the ticket, it's asking for separated signups per network, yet BP Multi Network specifically states that it doesn't separate signups between networks.

Whilst the SQL errors as a result of targeting a non-existent 'signups' table are real, they don't actually prevent signups on the non-main network. They do, however, break all the checks to the signups table that BuddyPress makes on the non-main network - for example the 'Manage Signups' page is non-functional. I wonder if the OP could have been getting confused by the broken behaviour?

Does bp_core_get_table_prefix() even need to be added to buddypress()->members-table_name_signups?

I wondered about this too, but it seems to get more complex and involved the more I think about it. Ultimately, I don't think it's worth BuddyPress doing any heavy-lifting here at all, given that the current code works just fine in all situations except a BP Multi Network context...

Regardless, I think we could add a filter for devs that need this.

Thanks - it seems better to let BP Multi Network do the filtering of $wpdb->base_prefix to point to the existing 'signups' table. I've opened a thread at the plugin's WP repo.

9 years ago

#6 @needle
9 years ago

Ron Rennick (author of BP Multi Network) says that this is "something that should be fixed in BuddyPress." I don't entirely agree, which is why I suggested the filter. @r-a-y Ron's objection re-opens your question:

Does bp_core_get_table_prefix() even need to be added to buddypress()->members->table_name_signups?

BP could indeed find the global table prefix, but the question I have is how (and indeed whether) BP could do that without causing any unforeseen breakages.

#7 @needle
9 years ago

Having thought about this further, I have changed my mind and think that BuddyPress should be adding the correct table prefix to the 'signups' table. This is done elsewhere in BuddyPress e.g. in bp_core_install_signups() where it's noted that BP should "Never use bp_core_get_table_prefix() for any global users tables".

New patch attached.

9 years ago

#8 @r-a-y
9 years ago

  • Keywords dev-feedback has-patch added
  • Milestone set to Under Consideration

5762-1.patch looks right to me.

Going to tag this with dev-feedback to get some eyes on this.

Thanks needle!

#9 @boonebgorges
9 years ago

+1 to 5762-1.patch. There may be cases where you'd want signups handled on a per-network basis, but it would take additional modifications throughout BP to make it work, and in that case you could reach into the global and modify table_name_signups if needed. Using the global base_prefix seems like the correct default behavior to me.

#10 @DJPaul
8 years ago

  • Keywords commit added
  • Milestone changed from Under Consideration to 2.5

#11 @r-a-y
8 years ago

  • Owner set to r-a-y
  • Resolution set to fixed
  • Status changed from reopened to closed

In 10506:

Members: Use WPDB's global base_prefix for the signups DB table.

This increases compatibility for those using BuddyPress in a multi-network

Props needle.

Fixes #5762.

Note: See TracTickets for help on using tickets.