Can you list by which plugins they are used and maybe for what? Like I would not make 2, 3 and 4 a public API unless there's a good usecase for it.

When talking about plugins you mean plugins that are not in piwik/piwik repo right?

These are used by LoginLdap. I haven't checked what other plugins.

I see there's eg a TODO note that it shouldn't disable the Login plugin here: https://github.com/piwik/plugin-LoginLdap/blob/4d7804fb97b5cfe8824a0b8da0a4587f6e960f0e/LoginLdap.php#L82

Once we make those PluginManager methods an "API" it will be hard to remove it again. The Plugin activate/deactivate looks like something we should rather fix in core. This will also avoid that other plugin developers have to do something like this. If it is not yet possible with DI, maybe there's another solution.

Just noticed Piwik\Updates is needed as API indeed. Not sure though if we should make isMajorUpdate(), disableMaintenanceMode(), enableMaintenanceMode() and deletePluginFromConfigFile() an API. Would prefer to not do this unless there's actually a use case for it / requested by someone or so.

Regarding activatePlugin/deactivatePlugin, pro plugins use it as well (specifically EnterpriseAdmin and others).

Regarding 2 and 3 (activate/deactivate plugins) I don't see a problem with providing a way to do that. Some of the use cases in EnterpriseAdmin seem legit (except the activatePlugin command that duplicates the command that now exists in core). But for these I think we should wait until #7656 is done and tag @api the methods on the new (renamed) class.

Does it maybe make sense to have two different "API" levels? Meaning one public API that we support/maintain etc and one for Piwik/PiwikPRO? I'm not 100% sure about it but I don't feel good about making Plugin\Manager (or the 2 methods) a public API.

Does it maybe make sense to have two different "API" levels? Meaning one public API that we support/maintain etc and one for Piwik/PiwikPRO?

having two levels of API is maybe too complicated for now.

I'm not 100% sure about it but I don't feel good about making Plugin\Manager (or the 2 methods) a public API.

Personally I don't mind to make two methods activatePlugin / deactivatePlugin as @api as enabling/disabling plugins will always exist and we could easily maintain BC in the future.

I've modified the PR so only Updates::getMigrationQueries() and Updates::doUpdate() are marked as @api. Plugin manager methods are still marked. Can be reviewed again.

Personally I don't mind to make two methods activatePlugin / deactivatePlugin as @api as enabling/disabling plugins will always exist and we could easily maintain BC in the future.

I'm ok with marking it as API but prefer when other plugins do not mess up with activating / deactivating plugins. I wonder about possible use cases apart from the EnterpriseAdmin? I'd personally like to keep the number of API's as small as possible and focused around analytics stuff. I really feel like we're almost going into a wrong direction or have to change some things but need to think about it at some point. Anyway, as I said I'm ok with it for now. We will be able to deprecate it.

could easily maintain BC in the future.

Never say something like this ;)

I'm ok with marking it as API but prefer when other plugins do not mess up with activating / deactivating plugins. I wonder about possible use cases apart from the EnterpriseAdmin?

I agree it doesn't really make sense for plugins to activate/deactivate other plugins. I tried to look at the EnterpriseAdmin use cases for activate/deactivate, but I'm not sure exactly what they're used for. Looks just like it's for convenience (ie, if the plugin is there, activate it now so we don't forget). Perhaps it can be modified to use the plugin:activate command instead.

EDIT: I guess we'd have to create an issue for the EnterpriseAdmin team for this.

Created issue for activatePlugin/deactivatePlugin: https://github.com/PiwikPRO/plugin-EnterpriseAdmin/issues/71

Updated this PR for less @api methods.

LGTM, @ others is it good for you?

It's a great feeling to make progress on the important issue #7569 👍