Join GitHub today
GitHub is home to over 28 million developers working together to host and review code, manage projects, and build software together.Sign up
[Discussion] TGMPA as a feature plugin for WP core #447
Dependency management for themes and plugins the WordPress way.
Existing external library which is widely used. +/- 6% of all themes in the repo use it, also used by a large number of premium themes and numerous plugins.
Thomas Griffin – Project Owner & creator of the original TGMPA library
Suggesting this as a feature plugin is inspired by numerous users who keep suggesting it should be part of core.
Scoping: the libary currently features some functionality which may or may not be acceptable for core. Advise on this would be helpful before starting the refactor.
Placement in the admin/user interface: currently plugins and themes can influence where the admin screen for TGMPA will show up. In the roadmap for 3.0 we’ve already included removal of this functionality and creating a set place for the admin page. Thoughts on where this should be and/or whether this should be integrated in an existing admin page would be helpful.
I've previously written some thoughts on plugin dependencies, please read that for some context of where I'm coming from.
The primary goal of plugin dependencies should be that it's invisible to the user. If there's ever a point where the user is asked to make a decision, then it's not ready for core.
I've had a quick read through the TGMPA code, I think it's solving the problem it needed to solve (providing a drop-in library for themes and plugins), but I think we'd need to tie it much more tightly into core for it to be a feature plugin.
I suspect the angle I'd go for is to add a "Dependencies" item to the theme/plugin header, which is just a comma separated list of plugin slugs. Don't specify version numbers (the end goal is that everything will always be at the latest version, anyway), it's up to the plugin author to ensure backwards compatibility is maintained. I'm not wild about optional dependencies - I don't think the user can be given enough information to make a decision as to whether they want it or not.
So, here's a rough idea of how I think that would work, from a code perspective:
That said, I haven't tested this in the real world, so I'm interested in hearing where this process can fall apart from your experience.
@pento Thank you ever so much for your thoughts.
I'm not sure I agree with this. So far we've leaned towards requiring at least some user interaction - see #242 - in part because of security and the fact that TGMPA currently allows installing from arbitrary external sources.
It has been made "easy" though with a one-page screen showing all dependencies for all installed themes and plugins which includes the option to bulk install/bulk activate.
One of the risks we've identified with having no user interaction for the installation of dependencies (quite apart from security) is that the user will be confronted with plugins on the plugins page which they have not consciously installed and will therefore uninstall, breaking their site.
That could of course be solved with visual indicators on the plugins page - think Plugin Dependencies plugin -. This is something which TGMPA currently does not offer but does intent to integrate.
A second way would be disabling the deactivate link. TGMPA v2.5.0 has started doing this, though that will not prevent the plugin being deactivated in a bulk deactivate action or code triggered action.
I could imagine a future implementation where on the theme/plugin screen, when the user clicks on 'activate', the user would be presented with a "This theme/plugin depends on plugin A, B, C which are currently not installed, would you like to install these ?" message to activate everything in one go.
Or even - but that would require changes in the API the theme/plugin library on wp.org too - a fold-out line-item which indicates "this plugin/theme has (unfullfilled) dependencies". Allowing the user to see what the dependencies are by folding open the line item and installing all in one go with the install button.
Could you elaborate a bit on that ? A lot of the code extends core classes to avoid code duplication and such already and we've done a clean up of those in 2.5.0.
That is the way the Plugin Dependencies plugin went, though they ended up going for Plugin Names rather than slugs due to plugin folders being renamed giving issues.
Version nr wise: I'd advocate allowing the setting of a minimum required version, nothing else. That should be easy enough to negotiate if different themes/plugins require different minimum versions and will encourage use of the latest version (more than setting a fixed required version or version range).
Having all that in a header line is not a good option, which is why my current line of thinking is a composer-like json file.
With a composer-like json file, a rationale parameter could be added for recommended plugins in which theme authors could indicate what extra functionality in the theme would be unlocked if the plugin would be installed.
That's part one, the other part - which is handled fabulously by the Plugin Dependencies plugin (another reason why we want to integrate the two) - would be cascading deactivation. I.e. if WooCommerce would be deactivated, all dependent plugins would be deactivated too.
And I can even imagine - though this is not currently planned - a use case for remembering if a plugin was installed because it was a dependency and if so, offering to uninstall it if the user would uninstall the last plugin which depended on that plugin.
I'll also comment on this part:
Very interesting point of view from @pento ...
On ThemeForest, we do not allow authors to automatically install and activate plugins without the user being prompted to confirm the action. It's not great UX, but it ensures that users know what is happening with their site.
I can appreciate that something in core needs to be as simple as possible for the average user (ie not developers!) and I can see the appeal of making this invisible for the users from a UX point of view. However, as @jrfnl points out, it won't actually be invisible - because you will be able to see what has been installed on the Plugins page.
That leads to a larger UX problem: User installs a theme and it invisibly installs 5 plugins for them - they feel happy about how simple it was to install the theme, but a week later they visit the plugin screen and find 5 plugins there that they didn't install and assume that they've been hacked!
Obviously there will be less intrusive ways to notify the user what's happening and Juliette has made some good suggestions that may be worth pursuing, but getting the balance right will be tricky.
Another issue may how to approach plugins that need to be set up after being installed. Not every plugin in the world will be using sane defaults and some will need user input to work (ie need to enter your Twitter handle for a follow me on Twitter plugin to work). If the user doesn't know it's been installed, then how will they know to set the plugin up? Maybe the plugin will display a nag message, maybe it won't. Maybe the theme documentation will have to tell them?
I'd say that as a minimum, if the theme (or plugin) installs plugins without user interaction, the user should be given a post installation list saying "The following plugins have been installed for you", perhaps with a link to the Settings page for each plugin.
Anyway, it's an interesting challenge...
This is an awesome idea, I think if we have pushed so much for the separation of the concepts in themes/plugins we need a way to deliver them to the user in a way that doesn't require anything from his side, from our experience with Zerif Lite theme, there is a big part of the users who want a 5 minutes site, without activating/reading/configuring 5 plugins etc.
Informing users is mandatory, allowing plugins from trusted sources for marketplaces like w.org/envato is a good decision, however I believe that simplicity in delivering complete solutions is what WP needs at this point to better fight agains competitors.
We could add a notification next to the plugin "installed by theme Y as a dependency".
I think that if something like this were to be merged in WordPress Core, it should only allow installing plugins from the w.org repository. However we could make the classes extendable so it's easy to allow installing plugins from 3rd-party sources.
The way I envision it is something like this:
Developer adds dependencies in the theme/plugin header
$dependencies = array( 'my_theme' => array( 'plugin1' => 'installed', 'plugin2' => 'existed', 'plugin3' => 'installed' ), );
I did that a bit more verbose than needed, but you get the point.
When the installation of dependencies finishes, the user should be informed that plugins 1 & 3 were installed on their site.
Plugins installed as dependencies should have an indication of some sort next to them in the plugins list, informing the user why they are there, and they should not be able to be deactivate those without first deactivating the "parent" theme/plugin.
There are serious political issues with including this in the core, no matter how appealing. There are important and influential members of the core theme who are VERY negative about TGMPA.
Don't put too much effort into this until you have some evidence there is support within the core team.
My theme is one of those 6% that uses TGMPA, and it is frustrating to keep finding new issues with ThemeCheck with TGMPA, so having it more official would be great. But...