Our stated goal for ClassicPress v2 is to move core functionality into core plugins. Obviously, this will require a plugin directory, which is now in the planning stages in this subforum.
Perhaps less obviously, we will need to support some form of plugin dependencies in our directory.
Why? To use a strawman example, let’s say that you install Jetpack on a ClassicPress site that has the XML-RPC module disabled or removed entirely. It won’t work.
The ideal user experience here would be to automatically register that “Jetpack has a dependency on ClassicPress Core XML-RPC”, and automatically install and activate the XML-RPC plugin before installing and activating Jetpack.
There are hundreds of other examples using existing plugins, and developers will also be able to make use of plugin dependencies to distribute common code only once.
Also, implementing this at the platform level will give all developers a standard way of re-using plugin code across their projects.
The directory servers will need to understand the basics of plugin dependencies, but most of the work will likely happen on the client side (the ClassicPress PHP code):
- ClassicPress should install and activate a requested plugin’s dependencies before installing and activating the plugin itself
- ClassicPress should prevent you from disabling a plugin that is depended upon by other plugins (or show a clear prompt indicating that multiple plugins will be disabled)
There are a number of existing solutions that we can draw from here. To name just a few:
composer for PHP,
apt on Debian-based Linux,
go get for Go.
Many of these solutions also handle dependency versions. We’re probably not ready to do this yet - just supporting all of the cases around “plugin X depends on plugin Y” will be difficult enough already. Also, some package management systems (like
npm) support having multiple versions of a plugin installed to satisfy different parts of a dependency tree, but this isn’t compatible with the way plugins work.
Plugin dependencies and the decisions we make around what works and how will affect many parts of the directory.
For one example: Any time we consider de-listing a plugin due to inactivity, security problems, or any other reason, we will also need to consider the effects on existing installations that have this plugin installed, as well as other existing plugins that depend on the plugin we’re trying to disable. Original discussion on this specific point here.