You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
Plugins are currently globally activated and thus apply to each website in a single Matomo installation. There are features delivered via Plugins which might not be required or wanted on a single website. This is kind of the case with the built-in "ecommerce" features which can be enabled on a per site base.
I propose to add the ability to add Plugins on a per site base in addition to the current only existing default of a "global" activation. This would allow Matomo Admins to optimize larger installations by limiting additional features only to those websites which actually require them. In theory this should allow peformance boosts in the processing as well as the UI. As less features should result in better processing and loading times.
I would suggest to allow Plugin devs to determine whether their plugin supports a "global", a "single website" or "both" modes. Whereas a globally activated plugin cannot be disabled for a single website.
There are concepts like these in major systems like WordPress. Which allows a much more granular control of the code being executed in the context of a single website. As I do see strong parallels of a WordPress Multisite setup to the way Matomo works for several websites, it would be a beneficial addition to add this level of control.
This would also raise the awareness of developers that there is a differentiation required between global settings and per site settings. We just came across such an issue with one of the official Matomo Premium plugins where this was kind of "overlooked" and site specific configs were setup and stored globally. Thus leading to data being globally accessible by admins of a single site who should not have access to the information of other sites.
The text was updated successfully, but these errors were encountered:
Thanks for your suggestion. I guess for now we need to leave that as it is, and plugin developers need to decide if they want to make their features site specific. Changing that would be a fundamental change in the logic we are currently using plugins. But our product team might consider this for future releases.