-
-
Notifications
You must be signed in to change notification settings - Fork 2.7k
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Plugins: support "require" other plugins #4485
Comments
yes this is looking very very useful to me too. => maybe we should implement this as early as possible (2.1?) because this is one of the great features which guarante e a hassle-free user experience for everyone btw: do you see more of this features helping for a hassle-free user experience? |
I must have closed it by mistake. This feature is actually very useful to let plugin manager be aware of plugin dependencies and erroring when trying to install a plugin with missing requirements. |
yes -"erroring when trying to install a plugin with missing requirements." |
The goal is that when we activate a plugin via the UI it will ask to first activate all other plugins (and lists here also the list of dependencies of those plugins recursively if any). It will also be practical to use with In MVP we can simply error if the required plugins are missing from |
I haven't tested it today but it might be already implemented as MVP: https://github.com/piwik/piwik/blob/master/core/Plugin/Dependency.php#L81 and +1 as suggested by @hpvd to later also check on deactivate etc. |
FYI: When trying to upload a plugin that requires another plugin I do already get the following error: "Please update Transitions 2.9.0 to a newer version, Transitions >=5.6.0 is required." or if plugin is not installed "Please update Transitionsd to a newer version, Transitionsd >=5.6.0 is required." (Error message should be like "Please install Transitionsd >= 5.6.0 as it is required by the XYZ plugin"). I presume the same is happening for Marketplace |
Just had a look and it is done whenever a plugin is installed or updated via Marketplace or Zip-Upload. Not sure if still needed to check on activate for MVP as such a plugin cannot be installed in theory (unless someone copies it manually into plugins directory which is maybe not recommended? Rather we maybe offer a command to install a plugin from a zip file or so?) . As said earlier 👍 for also checking on deactivating any plugin in case another plugin needs it etc |
we need to check on activate, because putting plugins in the filesystem is still one of the documented ways to install a plugin |
See comment above. Maybe it makes sense at some point to no longer recommend it (remove it from documentation) and replace it with a console command or whatsoever. Could maybe make sense long term to let all plugin installations go over one code path in the end to have less bugs, less code, less complexity etc. |
Copying the links I shared on Slack here: |
I'm not sure if mentioned here but if there is an update for a plugin that requires another plugin or if there is an update for a plugin that is required by another plugin we need to make sure to ideally update both at the same time in one go or to perform a check upfront whether afterwards both plugin still will work with each other. If they aren't compatible with each other we should inform the user upfront about this problem. Example: If one updates first If one updates first the plugin |
FYI: On the Marketplace we will soon check whether a required plugin actually exists. This means if plugin FooBar requires FooBaz we will check whether FooBaz is either a core plugin or a plugin on the Marketplace. If it is not we will throw an error and inform the developer about the unknown plugin FooBaz via email and won't create/update this plugin. Once we work on this feature #4485 we should update the Marketplace as well to check for the version constraints which can be quite complex since one could specify version dependencies like this |
…to install plugins and to find possible problems / conflicts
FYI: I spent about 90 minutes looking into Composer and worked on a proof of concept. Problem: There is basically no documentation about using composer as a library (apart from outdates PHP doc online but the classes etc are not documented anyway). Next problem: The classes are quite big and lots of code is hidden in big private methods, many of them untested. However: I believe I understood how it works and how we could use it to resolve the dependency graph see https://github.com/piwik/piwik/tree/4485_composer or better https://github.com/piwik/piwik/compare/4485_composer#diff-41646e8df310953f164f51bb15036224R41 I haven't tested a single line but I think it makes sense like this and it could work. We'd just need to create a couple of good tests as composer is basically not tested and we cannot trust it. Maybe we could work on this during Piwik 3.0 |
In #4183 support is added for "require" piwik and / or a php version.
As a result, it will be clean and almost error-free to use a plugin, as long as the developer set the "require" flags properly. This would be a subtle yet useful new feature.
The text was updated successfully, but these errors were encountered: