I have BP+WPMU. Some plugins for buddypress (tweetstream, BuddyPress Like, BuddyPress Links e.t.c.) are visible and activatable for non-admin users in their consoles. I think, it’s not good. How can I fix it? Because most of plugin developers don’t know, how to fix it in their plugins?

[@jeffsayre Participant 14 years, 8 months ago]

This is a simple fix. Sometimes BuddyPress plugin developers do not set the proper plugin header tag to make their BP-specific plugins activated sitewide–which means that everyone with a blog has access to the plugin and not just the Site Admin.

So, go to the main files of each of the plugins in question and look for this in the header:

Site Wide Only: false

If you see that, then you make the following change:

Site Wide Only: true

Of course, if you do not even find that tag in the header section, then you add it.

BUT, before doing that, make sure you have deactivated the plugins in question. Once you’ve done that, make the change, save the file, reactivate, and it should now work sitewide only. This means that only the Site Admin will have access to the plugin settings and activation in the admin dashboard.

One final thing to do, since you’ve discovered this issue with these plugins, please help out the community by contacting each of the plugin developers and pointing them to this thread.

[@motomac Participant 14 years, 8 months ago]

Thank you, Jeff.

Now these plugins are not visible for non-admin users, but after I activated them, they were activated sitewide. Is it right? I think these plugins should be activated only for main blog?

One more: Now non-admin users can see Facestream admin options in console. Is it plugin problem? All plugin options in console should be in the BuddyPress section?

I had written to many developers, but onle 1-2 fixed this. Another don’t know, how to make it.

[@jeffsayre Participant 14 years, 8 months ago]

All BuddyPress plugins should be activated sitewide. Since they depend on BuddyPress, they will only work with BuddyPress. This means they will only work on whichever blog BuddyPress is associated. So, although they are technically activated sitewide, they only work on the main blog–the blog that BuddyPress works on.

Now non-admin users can see Facestream admin options in console.

Yes, that is a problem with that plugin.

[@motomac Participant 14 years, 8 months ago]

Big thanks, Jeff

[@stwc Participant 14 years, 8 months ago]

Thanks for this clarification, guys. It was something I was wondering about too — the terminology had never been clear to me.

And I totally did not know this:

All BuddyPress plugins should be activated sitewide.

[@stwc Participant 14 years, 8 months ago]

Follow-on question! On the BP install I’m currently working on, the following long list of plugins (all of which seem to be working flawlessly activated non-sitewide) do not even offer the option for Site-wide Activation.

Is there a reason (or reasons) for that? Is there any possible downside? Or are they fine the way they are?

BP Group Management, BuddyPress Album+, BuddyPress Forums Extras main plugin (but not sub-plugins), BuddyPress Like, BuddyPress Links, BuddyPress Profile Privacy, BuddyPress Rate Forum Posts, Custom Profile Filters for BuddyPress, Enhanced BuddyPress Widgets, External Group Blogs (written by Andy!), Invite Anyone, oEmbed for BuddyPress, Welcome Pack and WP-FB-AutoConnect.

[@djpaul Keymaster 14 years, 8 months ago]

I’d wondered what that particular parameter did too, so thanks Jeff.

[@hnla Participant 14 years, 8 months ago]

Thanks Jeff, that’s an incredibly useful bit of info. I had wondered about when site wide should be used as was never too sure, but had noticed that certain plugins activated NON site wide would place themselves in the top section of activated plugins as site wide only, now I understand how this happens.

So for clarity if one adds ‘Site Wide Only: true’ to pluginin files main description then it forces site wide activation regardless of whether one chooses to activate normally non site wide. tested this with buddypress-links and is as described.

Edit/ found a plugin that already had ‘Site Wide Only: true’ set yet does not activate site wide using the plain activate link placing it self in the site wide section unlike bp-links. Is there something else that must be set to enable the site wide activation link or the ability to force the plugin to activate site wide?

[@djpaul Keymaster 14 years, 8 months ago]

For WordPress 3.0, the new tag to do this is:

Network: true

[@mrmaz Participant 14 years, 8 months ago]

Still unsure if I should add this tag to my plugin header. Shouldn’t it be up to the site admin to decide how the plugin is activated?

[@hnla Participant 14 years, 8 months ago]

I sort of had it in mind that BP specific plugins should be site wided or at least not sure I’ve come across an instance that I would like any general site member gaining access to them? But I remain a little confused on the issue.

If I have bp-links available but not activated it appears in general members dashboard on MU, however despite attempting to activate it doesn’t, if I then activate as admin on main blog and as site wide then general users never see that plugin mentioned – regardless of whether they can activate/deactivate. Taking bp-links as an example I can’t think of a reason that I would want users having or needing any access to this level of plugin and would prefer that it activated automagically as site wide much in the same fashion that BP itself does?

[@hnla Participant 14 years, 8 months ago]

Slightly tangental – apologies. This discussion brings to my mind the fact that in many ways I find the description of Buddypress, Buddypress-links, BP-Events, BP-Album and others of the same ilk as far more than plugins; plugins tend to make me think of things that are fun but not essential in any way to the operation of the core application whereas Buddypress whilst not necessary to WP is not simply a plugin it changes the working nature of WP and is far more suited to being known as a module or something to set it apart.

In an ideal world I would like BP installed much as is but described differently but along with BP are installed a series of modules that can be activated or not by admin but that these are only activated from within BP so to speak always sitewide as BP is these modules representing some essential core set of features e.g Links, Events, Album etc. In some ways that would also remove any confusion as to how they were activated, but I also realise that single WP probably has to be considered somewhere in all that.

[@jeffsayre Participant 14 years, 8 months ago]

Lots of questions to address, so I’ll do it in the order they were posed.

@stwc

On the BP install I’m currently working on, the following long list of plugins (all of which seem to be working flawlessly activated non-sitewide) do not even offer the option for Site-wide Activation.

Is there a reason (or reasons) for that? Is there any possible downside? Or are they fine the way they are?

These plugins should work fine whether or not they are activated sitewide. However, there are two reasons why a BP plugin should be tagged to activate sidewide automatically:

1. Because they are BuddyPress-dependent plugins and require BuddyPress to work. Since Buddypress operates sitewide, then all add-on plugins are sitewide-acting by implicit reference.
2. By virtue of the first point, only Site Admins should have access to any plugin configuration. Offering all members with blogs access to these BP-dependent plugins in their admin dashboard only creates confusion as these plugins are for BuddyPress only and not for WordPress blogs.

______________

@hnla

So for clarity if one adds ‘Site Wide Only: true’ to pluginin files main description then it forces site wide activation regardless of whether one chooses to activate normally non site wide

This is correct. When the Site Wide Only tag is set to true, it does not matter which activation link is clicked as either action will result in sitewide activation. In fact, for all BP plugins I test, I simply click the “Activate” link right under the plugin name and not the “Activate Site Wide” link. If the plugin then shows under the Site Wide listing of plugins, I move on. If it does not, then I know that the plugin author failed to set the tag properly.

Edit/ found a plugin that already had ‘Site Wide Only: true’ set yet does not activate site wide using the plain activate link placing it self in the site wide section unlike bp-links. Is there something else that must be set to enable the site wide activation link or the ability to force the plugin to activate site wide?

Not that I am aware. It might be that the plugin has two Site Wide Only tags and there is a conflict. To which plugin do you refer?

______________

@MrMaz

Still unsure if I should add this tag to my plugin header. Shouldn’t it be up to the site admin to decide how the plugin is activated?

See my response in this post to @stwc. Since your plugin requires BP to operate, there is no value in letting non-admin members have access to your plugin via their blog dashboard. The more you can do to make installation, activation, and operation of your plugin foolproof the better. Is there actual functionality that your plugin offers if activated non-sitewide? What features of your plugin even make non-sitewide activation a desirable option to Site Admins?

______________

@hnla

In an ideal world I would like BP installed much as is but described differently but along with BP are installed a series of modules that can be activated or not by admin but that these are only activated from within BP so to speak always sitewide as BP is these modules representing some essential core set of features

I agree completely. I always refer to BuddyPress as a plugin suite but that never sat quite right with me. BuddyPress is a feature-rich platform as far as I’m concerned. It transcends the idea of a simple WordPress plugin. I also agree that many of the BP “plugins” are best described as modules as well. In fact, I consistently refer to my privacy “plugin” as the BuddyPress Privacy Component to separate it from the idea of it being just another plugin.

I could see the possibility of BuddyPress modules having their own set of 3rd-party plugins. So BuddyPress > 3rd-party BP modules > 3rd-party module plugins.

I also like your idea of requiring that all BP-dependent “plugins” get activated within a BuddyPress dashboard–instead of outside of BP. That could take care of all activation conflicts.

In my version of an “ideal BP world”, BuddyPress would become the foundation of the WordPress ecosystem as it is a user-centric platform and not blog centric. WordPress then would be a layer that sits on top of BuddyPress and could be activated if desired. So, Site Admins would install BuddyPress and then could check a box to install WordPress (in single or multisite mode), bbPress, and other modules.

Now I’m taking this thread too far of topic.

[@hnla Participant 14 years, 8 months ago]

Now I’m taking this thread too far of topic.

Yes sorry that’s my fault, yet I agree with your sentiments above re BP foundation and do think the nature, nomenclature and plugin/module approach is worthy of deliberation by the project team.

The plugin that caused me confusion was buddypress-classifieds which does have site-wide set to true yet doesn’t activate sitewide from ‘activate’ link only from the site wide link, suggesting it’s possible to circumvent the site-wide only: true.

I’d like to find out as it makes a lot more sense that ALL BP plugins simply activate site-wide and correspondingly automagically deactivate when BP not activated present. less to go wrong then.

[@johnjamesjacoby Keymaster 14 years, 8 months ago]

The visibility of the Admin nav-item is a side effect of “Site Wide: true” but it isn’t the correct way to fix this.

The “Site Wide” meta value doesn’t have anything to do with users, roles, or capabilities. It’s only there to tell WordPress that plugin can act as the umbrella that covers all blogs/sites in a network.

The offending plugins are simply just not using the correct methods to add their navigation to the Admin area.

WordPress has many wrappers to help make this easy for plugin authors:

add_management_page

add_options_page

add_theme_page

add_users_page

add_dashboard_page

add_posts_page

add_media_page

add_links_page

add_pages_page

add_comments_page

All of the above functions are passed an $access_level variable, that can be set to a “current_user_can” value to limit its access.

I’d drop a message to the authors of the plugins that are showing their settings to unauthorized users. That isn’t just inconvenient/embarrassing/confusing, it’s a security risk.

[@jeffsayre Participant 14 years, 8 months ago]

jjj-

What you are saying is true. However, the issue that the OP raised is that the plugins themselves are visible to non-Site Admins in each member’s “Plugins” menu on their dashboards. This means that individual members have access to activate or deactivate each offending BP-dependent plugin. Of course, this should not be possible. So, the fix for the OP’s issue is to make sure that each BP-dependent plugin has the meta tag Site Wide set to true.

But, as you state, even with the correct plugin meta tag set, there are other things a plugin developer can mistakingly do that expose certain plugin Admin navigation items to non-Site Admin members.

[@boonebgorges Keymaster 14 years, 8 months ago]

Seems to me that good practice for admin panels is to add them either under Site Admin, Site Admin > Options, or BuddyPress. That way the current_user_can/is_site_admin provisioning is already done for you.

[@jeffsayre Participant 14 years, 8 months ago]

Boone, I agree. There is little value in adding Admin-only menu items to the navigation menus.

[@francescolaffi Participant 14 years, 8 months ago]

if I add the sitewide only true to the header, could there be some problem when updating if plugin is not already activated sitewide?

[@jeffsayre Participant 14 years, 8 months ago]

@francescolaffi-

There should not be any issues. However, I would instruct all Site Admins using your plugin to manually deactivate, upload the new version, and then manually reactivate.

Even if there were a few members with blogs that for some reason activated the plugin on their blog (per blog plugin activation), WPMU runs a check to see if any plugins that used to be per blog activated are now site-wide plugins. This means that WPMU will deactivate the plugin in the corresponding wp_x_options table of each user blogs.

For more in-depth information, see the function check_is_wpmu_plugin_on_activate in mu.php.

[@rubencc-2 Participant 14 years, 5 months ago]

Damn, this is an extremely useful topic. Thanks a lot Jeff. The way to activate various plugins have been bothering me for a while and I couldn’t find any info on it.