Opened 11 years ago
Closed 9 years ago
#5762 closed defect (bug) (fixed)
WP Multi Network plugin & BP 2.0.1 signup
Reported by: |
|
Owned by: |
|
---|---|---|---|
Milestone: | 2.5 | Priority: | normal |
Severity: | normal | Version: | |
Component: | Core | Keywords: | dev-feedback has-patch commit |
Cc: | needle@… |
Description
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!
Regards
Attachments (2)
Change History (13)
#1
@
11 years ago
- Milestone Awaiting Review deleted
- Resolution set to invalid
- Status changed from new to closed
#2
@
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.
#4
follow-up:
↓ 5
@
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:
https://wordpress.org/support/topic/doesnt-list-members-properly?replies=4#post-7477068
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.
#5
in reply to:
↑ 4
@
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 tobuddypress()->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.
#6
@
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 tobuddypress()->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
@
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.
#8
@
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
@
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.
You will need a BuddyPress plugin that supports WP multi-network. BP core does not handle this functionality.
Here are some that are available:
https://wordpress.org/plugins/bp-multi-network/
https://github.com/sbrajesh/buddypress-multi-network
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.