When installing a plugin and “Network Activating” it from the main network admin panel and then visiting a website dashoboard of the network the plugin should be inactive and each site admin should be able to “Activate” or “Deactivate” the plugin itself at will on the child site.
Current behavior
What happens is that “network activating” a plugin forces it to be active on every site of the network with no chance of deactivating it whatsoever.
Possible solution
I have the ClassicPress directory integration installed, no errors show in console or PHP debugging and the error affects both WP plugins and CP plugins. I suspect something in the directory integration is affecting this multisite feature.
Steps to reproduce
Install a multisite (folders setup, not subdomains) and install some plugins. Network enable the plugins and go to a child site of the network to visit the installed plugin page. There is no checkbox near the plugins to select them so no action can be taken on a child site to deactivate them.
Context
I am setting up a multisite to manage demos for my themes and eventually plugins, the inability to activate/deactivate plugins on a per site basis is essential.
Just tried, nothing changes, for context on this multisite I had only FX builder plugin, the switch to classicpress plugin and directory integration for now. Will try to remove the switch to classicpress but IMHO that one should not interfere…
Bingo, removing the migration plugin did solve the issue @Simone and now I am slightly astonished because THAT plugin should not interfere with plugin and theme activation on multisite
I was inspecting the code, and apparently before migrating the plugin checks for its activation status. Could it be that since it has to be active on all sites in a network when checking for this it prevents other plugins to behave the correct way? I mean, the migration plugin HAS to be force-activated on all sites of the network to perform its job, but somehow it appears as if it is extending this requirement to all other plugins, that instead should retain their normal behavior inside the multisite.
Am I confused?
I thought that without the network: true header a plugin can be ‘network activated’, which would force it to be used by all sites - or it could not be network active, then each individual site can be activated or not?
Themes work as explained above (where network decides which ones can be used)?
I have checked my sites, and even without the migration plugin that is how they seem to work (and always have? I thought that was what network activation of a plugin was for?)
I thought you needed a filter to prevent activation on individual sites when network activated.
In multisite the correct setup is:
Main site can install plugins and themes.
These become available for child sites ONLY when NETWORK ENABLED. This means that child sites do have all plugins DEACTIVATED by default when you create them, and from the list they can see (that corresponds to the network enabled) they can select which ones to activate. And if they activate some of them they can also deactivate them.
The migration plugin needs to be active on all the child sites, and in forcing itself enabled causes all other plugin to be forcefully enabled for all sites. That means that a child site admin can’t deactivate plugins or activate them for their site in the network.
Themes do work slightly different because a child site can only see the network enabled and only one theme can ba active at a time. The plugin only checks for “plugins activation status” and doesn’t check theme activation status because it only needs to check if all sites in the network have itself enabled and if not it forces itself active. And in this operation the mishap happens.
Hmm
My network theme page does have ‘enable’, plugins only have ‘activate’.
Maybe every one of my sites has always been broken, but when I ‘network activate’ a plugin, that is what happens, it is active on every site. If I only want it active on some sites, then I do not network activate, I individually activate.
Also, on mine, only the network admin / manager can install plugins (the main site probably redirects you there in some cases if you are the super admin, but even the primary site cannot actually install plugins).
Does your site have ‘network enable’ for plugins?
Mine do not that I can see.
Network enable and Network activate are two different things.
Network enable means "make it available on child sites that can then activate them or not at their choice) and Network activate instead forces the theme or plugin to be active by default on child sites and avoids its deactivation from child sites (Network activation of plugins and themes is a forced action, not the default multisite behaviour).
Removing the plugin restores things as per default behaviour where on child sites plugins can be activated/deactivated by the child site admin.
The thing that IMHO is messing things around for multisite is that the migration plugin in order to be able to migrate the entire multisite needs to be active ON ALL CHILD SITES AT ONCE. So when you network enable it from the main site IT CORRECTLY SHOULD FORCE ITSELF ACTIVE ON ALL CHILD SITES. However in doing so it also network activates forcefuly all other plugins that instead only need to be network enabled so that they can be deactivated/activated on a per child site basis.
Basically the plugin should only check itself, instead it is extending this check to all other plugins.
OK
But when I research this, I am not finding it to work like you suggest.
A filter or plugin would be needed to hide/deactive plugins that have been forced active at a network level (only themes work like you suggest). I have WP sites and CP sites not using the migration plugin that work the way I state, and always have, so I am a bit confounded by this.
ok, I am rechecking everything. Now the multisite indeed works like you describe. so plugins are installed in main and are considered enabled by default. and there is a check to network activate them.
Some time ago it was different, you needed to enable them in main site to be visible in child sites This meant there were three conditions to them:
only active on main site meant you had to leave them not network enabled and child sites never see the not enabled so that only main used them
network enabled were seen by child sites and could be activated/deactivated
network activated was when you forced some of them to be active on child sites with no possibility to deactivate them on child sites.
This way of doing it now does not allow for a plugin to be only visible to the main site. Now that I can confirm it is different, I can adapt to how it works now (because it is a change occurred somewhere in time in the past) but I am curious as to why it was changed that way. Because to me the previous way made more sense.
That is the current behavior. About 17 years ago (when WP was about v3) when I started playing with multisite fresh out of core inclusion (before it was a plugin!) it worked differently.
Themes and plugins had the very same rationale. enabling meant to make them visible and letting child sites enable or disable them and activating meant forcing them active (a super admin could force the same theme on all child sites and the same plugins or allow child sites to see a list of available themes and plugins and leave the choice to the child sites admins on what to activate).
There were basically three “modes” - first was plugins installed in main site and not activated, only main site could use them and were not available to the child sites. second was “enabled” that meant visible to every site and child sites could activate them or disable them at will. then last but not least there was network active, that meant they were forced active for all sites.
After some time I stopped playing around with multisite and now that I am coming back to it I find that changes have been implemented (thanks to @EliteStarServices who kindly took the time to explain to me) - the changes per se are not bad. Sincerely I am a little nostalgic of the way it used to be but the fact it evolved means that multisite is “alive” as a feature. I noticed that now it has only two states. installed and inactive on main site means available for activation/deactivation for all child sites, and active on main site means enforced for all sites. This was something that back in the days was achieved with a plugin that if my memory works as intended was called Multisite Plugin Manager. Now that plugin has no more use because multisite was changed to include that feature.
After thinking about this change for a while and doing some research I think I understand the rationale behind it. Many people used the plugin to manage the plugins and themes states in the network in the first place, also there was the need for people to restrict the capacity of child sites admin to be able to have a stable network (having a big list of plugins and giving the choice to activate them at will could destabilize the entire network). That meant that including that plugin features in multisite was needed.
I was mistakenly convinced that some plugins were altering multisite instead multisite is evolved. I am old and multisite is still young and growing up.
The Network: true plugin header means that the plugin must be activated network-wide if it is installed on a multisite installation. This header has no effect on Single Site installations.
Network: Whether the plugin can only be activated network-wide. Can only be set to true, and should be left out when not needed.
In fact, every plugin can be network activated by a Super Admin.
Plugins like Events Manager use that header, because they put network-wide settings in the Network Admin section. Also premium plugins tend to use this, because of external updates, which can only be run in the Network Admin.
And because the Network Admin extends/uses the main site, it can only read (execute) code of active plugins on the main site.
I used to do the latter myself as well, but I coded a new and light-weight updater class for my premium plugins that runs a must-use plugin. That way my premium plugins can be activated per sub blog, while the Updater Class hooks into the Network Update Check filter.
I never went on to explain that because it was not relevant, but I fully understand how the network header is used (as you said, when the plugin dev prefers that it can only be network activated, generally because settings or admin pages show up in the network admin area).
I’m not a big expert on multisite because I don’t use one (and I’ve never had to install one for anyone), but in my test local multisite installation, plugins can be activated at the network level, and these don’t they can be deactivated from subblogs. Or they can be activated only at the subblog level.
By default, when installing a plugin on the network, the plugin remains deactivated. It will be up to the superadmin to decide whether or not to activate it at network level. This power, however, must be exercised only for some specific plugins that must necessarily function at the network level: firewall plugins, antivirus for example. For the others, the choice must remain with the administrator of the individual subblog. Requiring the activation of plugins that perhaps aren’t necessary for a subblog is a stretch.
Now it works like you say. Many years ago when I used it and learned it there were three settings: deactivated (only for main site), enabled (for everyone and each child site could activate/deactivate), and activated forcefully on all sites.
Now all sites can see all installed plugins on the network, regardless of their ability to manage their activation. If a super admin doesn’t want to expose certain plugins to the child sites they need code to do that.
A little note, a super admin might want to hide the use or certain plugins because they do not want child sites to see/have access to them. This was possible in the past, and the plugin I mentioned offered an even more granular control over that allowing a “per site” setting of all plugins to the super admin.
As I said, the way it works now is not bad. It’s just different from the past and it is born from the way people use multisite. For the current way of using multisite this new approach simplifies things … and makes it slightly difficult to recreate a WP.com like structure… In the past creating a WP.com clone was a breeze, companies like Virgilio, Libero, Altervista and others in Italy and worldwide created their own clone and monetized it very easily. Now it can be done but it surely involves custom code, patience and much more money to develop and maintain/scale it.
