Activate SatisPress on blog level in multisite

[tyrann0us]

In multisite, Network: true prevents the plugin from being activated on blog level.

What's the reason for this? The alternative would be to distinguish with e.g. is_plugin_active_for_network() where to output settings pages and how to generate artifact permalinks etc. based on whether the plugin is network-wide active or on blog level.

I was able to activate and successfully use the plugin on blog level with only a few changes: Use_SatisPress_on_blog_level.patch.txt Note that this patch is not PR-ready because it simply reverts some changes from https://github.com/cedaro/satispress/commit/f964b13f0d464df84e6a6928eec72c51a3c1b3ea ("Add support for multisite installations.") and does not take into account on which "level" the plugin is active.

---

Background: With ~55 plugins activated (45 available in SatisPress), 8 themes (4 available in SatisPress) and more to come, the performance is very poor (Dashboard: ~7 seconds, Plugins: ~35 seconds). Also, the backend is cluttered with notices, menu items, admin bar items etc.

Because of this, we want to split SatisPress in multiple vendor instances (e.g. one for plugins from woocommerce.com, one for monsterinsights.com etc.) but don't want to maintain several independent installations. For this, we'd need the plugin to be able to be activated on blog level.

Do you think this could be added to the plugin? Thanks! This is related to #78.

[tyrann0us]

@bradyvercher, do you have an opinion on this?

[bradyvercher]

I've been out of town and under the weather for a few days, so I'm just now getting a chance to consider this.

SatisPress uses the Network: true header because plugins are only installed and updated at the network level and not on individual sites in a network. Also, for anyone running a network and using SatisPress in production, they probably don't want SatisPress to be accessible from individual sites.

While I think this is a clever way to work around the issues you described, I don't want to prevent multisite from being used the way it was intended and don't want to add a bunch of complexity if it can be avoided.

With that being said, is there any reason you can't already segment plugins the way you described to alleviate the performance issues. The only difference being that you would have a single Composer repository provided by SatisPress instead of a separate one for each site? One thing I'm not sure about is whether you would need to manually visit each site to be sure update requests are triggered.

Another approach you might consider is writing an MU plugin to filter the active plugins so you can conditionally disable the main performance offenders while you're logged in to the admin panel.

[tyrann0us]

Your answer brought me to a very simple idea: Activate SatisPress in a multisite on network level (default behaviour), but separate the packages (plugins/themes) on single subsites, e.g. by vendor. The only difference to the current setup would be that the update cronjobs need to run for each site. First tests have shown that this approach can work.

(I wanted to get back to you with this idea still this week but first after I would have talked about it and tested it in our company's monthly developer "jour fixe".)

[bradyvercher]

Thanks for the update, @tyrann0us! Let me know how your testing goes and if you run into any issues with that approach.

[tyrann0us]

Just a short update about the "multisite with vendor-based sites" approach for SatisPress: It works perfectly. The performance has increased dramatically; it is finally fun again to work with SatisPress.

Screenshot from the sites overview: