Make WordPress Core

Opened 15 years ago

Last modified 3 years ago

#14569 new feature request

Assign plugins on a per-site-basis

Reported by: chantalc's profile ChantalC Owned by:
Milestone: Future Release Priority: normal
Severity: normal Version:
Component: Plugins Keywords: has-patch needs-refresh
Focuses: multisite Cc:

Description

It's possible to assign themes per site with WordPress Multisite. However it isn't possible to assign plugins per site. Some plugins are only used for the mainsite and I don't want them to be visible in subsites.

Attachments (2)

15569.patch (16.1 KB) - added by rufein 10 years ago.
Patch to disable some plugins in a multsite installation
comments.php (5.2 KB) - added by realcoolmanbd 8 years ago.

Download all attachments as: .zip

Change History (22)

#1 @defries
15 years ago

+1 I actually think it's odd to have this flexibility and not for plugins if you think about it.

#2 @Qoate
15 years ago

+1, i'd really like to see this. :)

#3 @illutic
15 years ago

+1 totally agree

#4 @markmcwilliams
15 years ago

+1 here too!

#5 @gazouteast
14 years ago

  • Cc gazouteast added

It's already there isn't it?

Activate plugin = this site only
Network Activate plugin = all sites and blog owner can configure
MU-Plugin = all sites and either no configuration network wide, or home site admin configuration only.

At least, that's the way I understand it works.

Then if you need plugin ABC on a site other than home, admin goes to that site and activates it - it then operates on (and is available to) only the home and selected additional site.

Or have I got all that wrong?

#6 @ChantalC
14 years ago

Sort of. But other sites see that plugin and can activate it. There should be a feature just like themes, that you can assign plugins to be visible just to one site. Invisible for others.

#7 @deepak.seth
14 years ago

  • Cc deepak.seth added

+1 for this, definitely want this to be implemented just like themes.

#8 @nacin
14 years ago

  • Milestone changed from Awaiting Review to Future Release

#9 @gruvii
13 years ago

  • Cc gruvii added

#10 @Messenlehner
11 years ago

  • Cc Messenlehner added

#11 @jeremyfelt
11 years ago

  • Component changed from Multisite to Plugins
  • Focuses multisite added

#12 follow-up: @earnjam
11 years ago

This is something that has come up quite a bit for me, so I'd love to work on writing a patch for this. But before I get too far into it, I wanted to post a thought/question here.

Right now, all plugins are available on all sites immediately upon installation, so I would assume we'd like to keep that behavior going forward for easy backwards compatibility and consistency. So should this be set up opposite of the way themes work? Themes are stored as an array of "allowedthemes" in wp_sitemeta and the individual wp_options table for each site. But if the desire is for plugins to be enabled by default, then should this be "disabledplugins" or something similar?

Would that be to confusing for themes and plugins to act differently though? They act differently now, but that is primarily because plugins don't have the enable/disable option. Perhaps they should be aligned for consistency?

#13 @earnjam
11 years ago

This also relates to a similar discussion about how themes are handled in #18301 and here: http://make.wordpress.org/ui/2011/09/10/18301-multisite-theme-activation/

#14 @jeremyfelt
10 years ago

  • Keywords needs-patch added
  • Version 3.0.1 deleted

I would very much like this feature and would be happy to help with testing and development. It's possible we could find a way to do portions as a feature as a plugin. :)

#15 in reply to: ↑ 12 @rufein
10 years ago

Replying to earnjam:

This is something that has come up quite a bit for me, so I'd love to work on writing a patch for this. But before I get too far into it, I wanted to post a thought/question here.

Right now, all plugins are available on all sites immediately upon installation, so I would assume we'd like to keep that behavior going forward for easy backwards compatibility and consistency. So should this be set up opposite of the way themes work? Themes are stored as an array of "allowedthemes" in wp_sitemeta and the individual wp_options table for each site. But if the desire is for plugins to be enabled by default, then should this be "disabledplugins" or something similar?

Would that be to confusing for themes and plugins to act differently though? They act differently now, but that is primarily because plugins don't have the enable/disable option. Perhaps they should be aligned for consistency?


You are right. The behaviour is different. I want to make an explanation about the different behaviour of themes and plugins:

Themes

Network Enable => This option makes that a theme will be available in the themes admin page of every site. The admin of every site can active or deactivate the theme.

Plugins

Network Activate => This option makes that a plugin will be active in all sites. The admin of a site has no privileges to activate or deactivate. In fact, the plugin won't be shown in the admin plugins list of a site.

Conclusion

So, you can add themes to the server. But it won't be visible until the network admin enable the theme to the network. On the other hand, a plugin always be visible. If the network admin activate the plugin, it will available in every site. The sites admin can´t deactivate the plugin, but they can configure and use it.

The request feature of this thread is about visibility. Instad of disabledplugins meta option, i would call it visibility_plugins. This change is to avoid confusion. A plugin could be disable, but visible to give the chance to activate the plugin.

A possible approach

I would build visibility_plugins in the following way:

array(
  "plugin_name" => array(),     // Always visible
  "akismet" => array(1, 2, 5),  // array of unique $blog_id sites that will be invisible
  "hello" => array(0),          // Plugin -hello- will be invisible in all sites.
);

We have to take into account:

  • If a plugin is activated in network, the visibility of the whole module have to be unset.
  • If a plugin is active in some site, the $blog_id visibility have to be unset.

And it could be neccesary build an admin configuration page with checkboxes in the network admin area to configure the visibility of plugins.

This ticket was mentioned in Slack in #core by jeremyfelt. View the logs.


10 years ago

@rufein
10 years ago

Patch to disable some plugins in a multsite installation

#17 @rufein
10 years ago

Finally, I've done a patch to disable plugins in a multisite. The admin of a network can disable (not showed) a plugin in a concrete site.

I've considered the following schema:

  • If a plugin is active in a network: The disable plugins won't be evaluated.
  • If a plugin is not active in a network:
    1. if a plugin is active (activated by the site admin), the network admin cann´t disable.
    2. if a plugin is not active, the network admin can enable/disable.

I've tested manually in the last development version of wordpress.

This ticket was mentioned in Slack in #core by earnjam. View the logs.


10 years ago

This ticket was mentioned in Slack in #core-multisite by earnjam. View the logs.


10 years ago

#20 @desrosj
3 years ago

  • Keywords has-patch needs-refresh added; needs-patch removed
  • Milestone set to Future Release

Came across this one going through tickets missing a milestone. @rufein thanks for your work on this one previously, and sorry that it fell through the cracks!

I still think this would be a great addition to multisite installs. The patch definitely needs to be refreshed to apply and work with the current code base. If someone is willing to work on this, it can be considered.

Note: See TracTickets for help on using tickets.