[Discussion] TGMPA as a feature plugin for WP core

[jrfnl]

Ref: https://make.wordpress.org/core/2015/07/10/feature-plugin-chat-on-july-14/#comment-26310

Overview of your feature plugin proposal.

Dependency management for themes and plugins the WordPress way.
Allow themes and plugins to indicate dependencies on (other) plugins and providing an easy way for admin users to install, update and activate those. Will include activation prevention if dependencies are not met and providing cascading deactivate of dependents when a providing plugin would be deactivated.

Current status

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.
A large refactor is planned and knowing what parts would be acceptable for core would be useful before starting the refactor.
Roadmap for refactor from before this proposal (open to change per scoping): #394

People involved

Thomas Griffin – Project Owner & creator of the original TGMPA library
Gary Jones – Project Lead
Juliette Reinders Folmer – Lead Developer

Suggesting this as a feature plugin is inspired by numerous users who keep suggesting it should be part of core.

Link

https://github.com/TGMPA/TGM-Plugin-Activation/

What you’d like help with

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.
Ref: https://docs.google.com/document/d/1abkiqT15SSboJVF8a16QDOL8o8Ocy4EHxsoZKwuwMFY/edit?usp=sharing

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.

[pento]

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:

1. When a plugin is activated, check to see if it has any dependencies listed
   1. Download and install those dependencies
   2. Check if the newly installed dependencies have any dependencies
      1. If so, return to 1.i.
2. Activate all the dependencies
3. Continue with the existing activation process

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.

[jrfnl]

@pento Thank you ever so much for your thoughts.

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'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.
Still, even if we would remove that part (external sources), the plugin download URL in core is filterable, so that would not take away the security risk.

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.

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.

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.
We are aware that the code base needs a proper rewrite, aka, the v3.0.0 roadmap #394.

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.

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.
I've considered that initially as the way to go, but believe that will not make the system robust enough.

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).

I also see value in the is_callable parameter we have implemented for which @zackkatz made a very good case in #205.

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.

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.

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.
This is one of the things which is already planned to be included #259 #278

So, here's a rough idea of how I think that would work, from a code perspective:

When a plugin is activated, check to see if it has any dependencies listed
Download and install those dependencies
Check if the newly installed dependencies have any dependencies
If so, return to 1.i.
Activate all the dependencies
Continue with the existing activation process

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.

[Stephen-Cronin]

I'll also comment on this part:

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'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.

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...

[ineagu]

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.

[jrfnl]

Some related trac tickets:
https://core.trac.wordpress.org/ticket/22316
https://core.trac.wordpress.org/ticket/30550
https://core.trac.wordpress.org/ticket/29603
https://core.trac.wordpress.org/ticket/24152
https://core.trac.wordpress.org/ticket/20241
https://core.trac.wordpress.org/ticket/20241 (loosely)
https://core.trac.wordpress.org/ticket/11308
https://core.trac.wordpress.org/ticket/10190

[aristath]

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!

We could add a notification next to the plugin "installed by theme Y as a dependency".

[aristath]

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.
I like the way plugin dependencies are defined in the Plugin Dependencies plugin... it's simple and intuitive. It does not require creating any custom functions etc...

The way I envision it is something like this:

Developer adds dependencies in the theme/plugin header
When the user installs a theme/plugin with dependencies, WP checks if these dependencies are already installed.
If they are not, then downloads the required plugin, installs & activates them. This of course will have to be done recursively.
A new entry is created in the wp_options table in the db, containing an array. Something like this for example:

$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. installed and existed could be boolean, not necessarily strings as descriptive as the ones used in that example.
This will keep track of which plugins were installed by our theme. If we deactivate our theme, then plugin1 & plugin3 will be deactivated automatically but not plugin2 since it already existed in the installation so we're assuming the user needed it before installing our theme.

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.

[weavertheme]

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...