Cannot see/activate/delete pending accounts when BuddyPress is activated on a subsite of a multisite installation

[tomdxw]

1. Start with a WordPress multisite installation
2. Activate BuddyPress on the main site (do not network activate)
3. Visit /wp-admin/users.php
4. Click on the "Pending" filter

Result: "You do not have sufficient permissions to access this page."

However you can see the pending accounts when you visit /wp-admin/network/users.php?page=bp-signups

But all of the activate/delete buttons link to /wp-admin/users.php?... which shows the same error message. (It is possible to activate/delete accounts if you add /network/ to the URL each time you see that error.)

Reproduced using BuddyPress 2.1.1 and WordPress 4.0.

[imath]

Thanks for your feedback tomdxw

I confirm. That's a config i didn't think of :( Sorry for the inconvenience. I need to explore it more.

[imath]

Ok i got it to work!

But i think we need to discuss with core team the choices i made. I think they are consistent. Let's detail them :

Not multisite config

When a user signs up, he's created with a role on the site. Unless a specific constant ( BP_SIGNUPS_SKIP_USER_CREATION is defined. In both cases, there's no problem to manage signups and extended profiles.

Multisite regular configs (BuddyPress is network activated)

When a user signs up, he's created without having a role on any blog. I think it's a good thing and we should keep it this way. As BuddyPress is network activated, there's no problem to manage signups and extended user profiles

Specific configs : BuddyPress is not network activated, but activated on a site.

1/ BuddyPress is activated on a subsite of the network

• managing signups is not possible
• managing extended profile is only possible for the users having a role on the subsite (see #5367)

2/ BuddyPress is activated on the main site of the network. (tomdxw's feedback)

• it's actually the same case than the previous one except that a menu to manage signups shows in the site admin. Clicking on it leads to the result tomdxw explains in the description of this ticket.

Now. A simple fix could be to neutralize the signups management menu for case 2/ (i actually thought of it). But i think we have an opportunity to fix the situations for these 2 specific configs and also the ticket #5367.

I'll start by 1/ : the subsite. In this case, it's not possible to register a blog from the sub site where BuddyPress is activated. Only user accounts can be registered. I Suggest then to use the BuddyPress signup process instead of the WPMU one. Registered users will have a role on the sub site and it will be possible to manage signups and extended profile from there for the user having the 'manage_network_options' capacity.

Now 2/ is a bit more complex. Because, you can also register a blog in this config. So i suggest to introduce a new function :
bp_is_network_main_site() to check if the BuddyPress root blog is also the main site of the Network. If so, we then create users with role on the BuddyPress site so that it's possible to manage extended profile. The BuddyPress site is not the primary site if users registered with a blog, it is if they simply registered an account. Users having the capacity 'manage_network_options' will be able to manage signups.

I think, although it's a bit different than WordPress Multisite logic (creating users without roles), it makes sense for people using such particular configs. If they do so, it means : they want BuddyPress to manage signups and members extended profile from a site and not from the network. So they implicitly agree to create users with roles on their blogs in order to be able to manage them from this site (sub site or main site).

5977.patch is applying the choices i suggest to manage members on the network for these 4 configs. What do you think ?

[johnjamesjacoby]

​5977.patch seems right, though I wish this was all a bit more sane to manage. The patch does a good job encapsulating the experience and funneling it down into a few convenient helper functions to handle the somewhat edge-case installation type.

Some thoughts on the patch:

• Can your new bp_is_network_main_site function just use bp_is_root_blog() instead?
• If not, maybe rename bp_is_network_main_site to bp_is_main_site_for_network or something similar?
• I confirmed that our BP_ROOT_BLOG logic is still sound, and covers most use-cases (including this one.)
• Maybe rename bp_core_get_specific_signup_meta to bp_core_get_site_signup_meta or bp_core_get_blog_signup_meta to keep the naming consistent? The specific verbiage isn't wrong, but it's new, and isn't likely an approach we'll take in very many other places.

Nice work, Imath.

[imath]

Replying to johnjamesjacoby:

• I confirmed that our BP_ROOT_BLOG logic is still sound, and covers most use-cases (including this one.)

Thanks a lot for your feedback johnjamesjacoby. I think i was a bit afraid about using bp_is_root_blog() because i've seen some people defining BP_ROOT_BLOG to a specific sub site directly from wp-config.php (which is btw causing some of my plugins to fail!).

So i wanted to be 100% sure the site where BuddyPress is activated is the main site of the network, that's why i've created the function bp_is_main_site_for_network() (renamed it in 5977.02.patch)

[johnjamesjacoby]

It would be an interesting use-case to define BP_ROOT_BLOG as one ID, and then activate BuddyPress on another site. What would be the benefit, and the desired outcome?

In the case of profiles.wordpress.org, we have different components active with different table prefixes, so it behaves quite like a separate network running on the same installation. Very edge case, but the flexibility is nice to have, and we do force the BP_ROOT_BLOG to do so.

[boonebgorges]

5977.patch seems right, though I wish this was all a bit more sane to manage

This pretty much sums up my thoughts :) I'd only add the following general thought, following up on johnjamesjacoby's comment here ​https://buddypress.trac.wordpress.org/ticket/5367#comment:21: It would be a good idea for us to think about the different kinds of events that can differ between installation types (where user registration takes place; whether blog registration is available; where user management happens; etc etc etc), and try to allow these different types of settings to be toggled independently of one another. That way, as jjj suggests, we can draw up a list of different setup types, and perhaps do an explicit mapping of default behavior, something like:

array(
    'single_site' => array(
        'registration_location' => 'root_blog',
        'role_on_root_blog' => 'subscriber',
        // ...
    ),
    'multisite_activated_on_single_site' => array(
        'registration_location' => 'root_blog',
        'role_on_root_blog' => false,
    ),
),

or whatever. Then, we make these defaults filterable for complex networks (or meta-networks) that need to customize how this stuff works. (I'm not saying we should do all of this *right now*, but I think it's something to shoot for, because it'll make it so much easier for us to maintain the current systems, and for site owners to customize the experience.)

[imath]

Thanks a lot boonebgorges for your feedback. I agree, i'll work on a new patch that will include a default (and filterable) "config" setup types.

johnjamesjacoby: i think some people (very fiew) are defining BP_ROOT_BLOG to a sub site but are activating BuddyPress on the network

[boonebgorges]

I agree, i'll work on a new patch that will include a default (and filterable) "config" setup types.

Please don't feel like this is a prerequisite for the fixes you're suggesting here. I'm just suggesting that this is a direction we might think about moving down the road.

[imath]

Replying to boonebgorges:

Please don't feel like this is a prerequisite for the fixes you're suggesting here.

:) oh ok, let's say the patch is here and we can eventually rely on it for 2.2. But I'm very interested in exploring all potential configs so i'll try to improve it in the direction you and John are suggesting before the end of dev cycle ;)

[fredleeflang]

hi imath, I can confirm that this patch works. I had been sitting here staring rather baffled at the screen for a while how come I couldn't click on 'pending users' even as super admin. Then I realized that I had never seen it before, which was when I realized it had to be a plugin.

[fredleeflang]

@imath I applied patch 5977.02. It resolved the issue of not being able to click on the pending users tab.

I also however no longer see any signed up users from the frontend, so cant invite anybody to groups for example.

I do see newly signed up users in the regular admin backend however.

[fredleeflang]

BTW, I'm also using WP-FB Autoconnect (Pro).

In the Buddypress activity stream I can see that people are signing up. I can send them messages as well. Maybe I'm just not familiar enough with Buddypress yet. Do I need to be friends with somebody before being able to invite them to a group?

[imath]

Replying to fredleeflang:

BTW, I'm also using WP-FB Autoconnect (Pro).

Do I need to be friends with somebody before being able to invite them to a group?

Yes, unless you add users from the Group Administration screen (in WordPress Administration).

And Thanks a lot for your feedback about the patch :)

[imath]

I am sorry, even if the patch is working, i haven't found the time to build the default (and filterable) "config" setup types jjj and boonebgorges suggested.
I'd really like to work on this during next dev-cycle as it will also fix #5367

[imath]

Sorry again :( i was completely focused on attachments API. Will look at it for 2.4

[supaiku]

I have this issue but am a little confused as to the conclusion:

it seems there is a patch? BUt how can it be installed? Do I need to manually insert the code into the related files?

My situation is that I have a multisite with budypress on a Secondary Sub-site (using a Multisite plugin manager).

I thought maybe there was a workaround where i could create a localsite admin, but it didn't seem to work.

What's the best way to authorize the pending user registrations atm? Can the patch be installed as a temporary solution?

Much appreciated!

[goelji]

feedback: patch 5977.02 resolved the issue

Error: 'not have sufficient permissions'
Where: clicking 'Pending users' when BuddyPress activated on main site of multisite install

Thanks