Plugins Management for Groups

[michaelha]

I want to manage plugins in Groups just like how WPMU does to individual blog. For example I can, in group 1, select which plugins I want to enable/disble so that a group can be customized for a particular purpose. Hope this makes sense.

[DJPaul]

Kind of related: in #2712, we got rid of our own gravatar type option and are now using WordPress' Settings > Discussion option.

[DJPaul]

That was posted on the wrong ticket. Paulbad.

[imath]

Hi,

I think, now that the Group Admin UI is available, this is something that can be consider. I remember the time when i was playing with css from the functions.php of my theme to eventually hide the group extensions nav i didn't want to show in some groups.
I think it can be very handy for Super Admin to have such a feature as they will be able to have more control on the groups and their capabilities to use the group extensions.

So, i thought about it and i think we need to :
1/ allow Super admin to set group extensions that are available by default ( see ​http://flic.kr/p/fBwybF for an illustration)
This page is a submenu of the group admin UI called "Extensions"
2/ allow Super Admin from the group Admin UI to override the default setting if he wants to activate / deactivate the extension for the current group ( see ​http://flic.kr/p/fBwyaP for an illustration )
In group admin UI i've added a metabox that list the group extensions with their statuses

This is how i built this patch :
1/ I needed to know what group extensions class was registered so i used the global $wp_filter to list the add_action() on the hook bp_actions with a priority of 8
2/ then i loop the array i get and build a list of available extensions and i get the parent plugins infos.
3/ I've added two filters : one in the bp_register_group_extension() function to eventually disallow the group extension on front, and on in BP_Group_Extension::is_screen_enabled() to eventually deactivate the admin screen.
4/ The Extensions Group Admin UI submenu is there to allow Super Admin to set the available group extensions by default - if inactive, it helps to avoid the group extension to not show its create step while creating a new group
5/ A new metabox in group admin UI allows the super admin to override the default settings.

NB : for it to work at 100%, plugin authors (including me!!) needs to call bp_register_group_extension() after bp_init otherwise the group id is not set, so it breaks the overriden group settings.

i've added the 2673.diff to attach the patch.

[boonebgorges]

Thanks for the really interesting patch, imath. I have some conceptual questions for the whole group, and then some technical feedback on the patch.

Concept: In general, I really like the idea of allowing extensions to be toggled on a group-by-group basis. This patch both does less and more than this: it does more by allowing for a global default setting for each extension (the Groups > Extensions panel), and it does less by not allowing group admins to handle this task. If I'd been the one to write the first draft, I would have set it up a bit differently:

• I would have created a front-end UI for group admins to toggle extensions. To my mind, the real power of this functionality is to let group admins have it.
• I would have left out the global defaults. They're a bit confusing: as imath wrote the patch, they provide global fallback settings. But they're just fallbacks - there's no way to force an extension toggle across all groups. So, it seems to me like it's of limited use, especially given that we're adding an entire admin panel for it. A more fleshed out version of the admin panel would do a bit more: it would allow super admins to set the *default* value for each extension, and it would let the admin toggle whether group admins would have granular control over that given extension's toggle.(This is how xprofile field visibility works: admins can set a default level, and can also say whether individuals can modify it.) IMHO, it's only worth adding this panel if we provide this kind of rich functionality. If it's just for fallbacks, the same thing can be done with filters.

What do others think? Is this the kind of power we want to give to group admins as well as super admins? IMO, the answer is yes; moreover, if we're only going to give it to super admins, I think it'd be better handled by a plugin, not by BP itself. I'd also tentatively suggest that we table the Extension admin panel (and the idea of global defaults) at first, and think about adding it after the UI for individual groups has been set.

Technical considerations: imath, you wrote much of this like a plugin, which is to say you added a bunch of functions, but didn't change anything about BP. This is good for a plugin :) but it makes for some ugly hacks. So, instead of fishing around in $wp_filter, we should just register all new extensions at the time that bp_register_group_extension() is called. BP_Group_Extension already creates ReflectionClass objects for each extension, so your ReflectionClass stuff (which is clever, btw) should be moved there instead. See 2673.02.patch for a mostly-working version of these suggestions.

I'm moving this to 1.9 for preliminary consideration. Let's talk about it at the next dev chat to see if it's something we can agree on conceptually in time for 1.9.

[imath]

Replying to boonebgorges:

• I would have created a front-end UI for group admins to toggle extensions. To my mind, the real power of this functionality is to let group admins have it.

I agree at 100%, but i guess i didn't think about this as for instance i always add an option in my plugins to deactivate/activate the plugin for the group from the group front-end admin ui. But you're right some plugins may not allow the group admin to deactivate them.

• I would have left out the global defaults. They're a bit confusing: as imath wrote the patch, they provide global fallback settings. But they're just fallbacks - there's no way to force an extension toggle across all groups.

My goal wasn't really to toggle, i wanted to find a way to let the superadmin making globally unavailable plugins group extensions or simply leave them available. So when a plugin is deactivated, i guess the verb i use in the group extension management is confusing for restoring the group extensions as available. So "Activate" should be replaced by the idea "make it activable by group admins"

So, it seems to me like it's of limited use, especially given that we're adding an entire admin panel for it. A more fleshed out version of the admin panel would do a bit more: it would allow super admins to set the *default* value for each extension, and it would let the admin toggle whether group admins would have granular control over that given extension's toggle.(This is how xprofile field visibility works: admins can set a default level, and can also say whether individuals can modify it.) IMHO, it's only worth adding this panel if we provide this kind of rich functionality. If it's just for fallbacks, the same thing can be done with filters.

In 2673.diff, the super admin was able to globally deactivate a group extension, and from the group backend admin UI force the group extension to be active even if it was globally deactivated. I thought that a super admin might want to restrict some group extension to some groups. That's why my groupmeta was an array of group extension statuses ( e.g. buddydrive => 1, forum => 0..)

I've noticed in 2673.02.patch that you changed this behavior by only saving the inactive group extensions which breaks in a way my first logic, because if in the group back-end admin UI we can only deactivate, then the global setting can't be override for the group by the super admin.
(PS : there was also a fatal error as you refer to a function of my first patch but don't include it in yours :( )

So in 2673.03.diff, i benefit from your great work - i agree mine was a bit ugly, i like fishing ;) - and restore to my first idea :

1/ Super Admin has a global power on Group Extensions : he can leave them do their job or neutralize some of them
2/ If a group extension is globally neutralized, Super admin can still activate it from the group back-end admin UI for the groups he wants.

And i agree a front end UI could give us a third point :
3/ group admins from the group front end UI can deactivate a group extension that is left available (globally > point 1/ or not point 2/)

[boonebgorges]

Thanks for the feedback and additional patch, imath. I'm going to make the executive decision to move this to the 2.0 milestone. I'd like to make this a major project for the 2.0 release, and in particular, I would like to take this opportunity to rethink the way that group extensions interact with the group creation process (#3717). I think we need quite a bit more time to think about the intended functionality, and to talk about the UX.

My goal wasn't really to toggle, i wanted to find a way to let the superadmin making globally unavailable plugins group extensions or simply leave them available.

Maybe I misread the original patch, then. The way I read it, individual group settings for extensions overrode the global settings. Maybe this makes sense when the only person who can manage extensions is the super admin. Or maybe I was just mistaken in the way I read it. In any case, I still think that the ideal functionality will allow the super admin *both* to set a _default_ and to set an _override_ for individual group settings.

there was also a fatal error

Yes, my patch was pretty messy, I was just putting it up so you could see the more important of the differences :)

Let's see if we can pull karmatosed into this conversation to talk more about the way that this interface might work in 2.0 (both from the super admin point of view and the group admin point of view).

[r-a-y]

Really like the work that has gone into this so far, imath!

Let's look at this again in 2.1 when we'll have more time.

[DJPaul]

Hate to punt this to 2.2, but looks like no-one's had time to revisit this ticket this dev cycle. One day... :)

[DJPaul]

We're closing this ticket because it has not received any contribution or comments for at least two years. We have decided that it is better to close tickets that are good ideas, which have not gotten (or are unlikely to get) contributions, rather than keep things open indefinitely. This will help us share a more realistic roadmap for BuddyPress with you.

Everyone very much appreciates the time and effort that you spent sharing your idea with us. On behalf of the entire BuddyPress team, thank you.

If you feel strongly that this enhancement should still be added to BuddyPress, and you are able to contribute effort towards it, we encourage you to re-open the ticket, or start a discussion about it in our Slack channel. Please consider that time has proven that good ideas without contributions do not get built.

For more information, see ​https://bpdevel.wordpress.com/2018/01/21/our-awaiting-contributions-milestone-contains/
or find us on Slack, in the #buddypress channel: ​https://make.wordpress.org/chat/