Guidance on plugins that install other plugins

There are plugins in the directory that ask to install other plugins. This can happen for various reasons, and there are different contexts and cases.

What do the current guidelines say?

The current guidelines have different indications regarding the context in which other plugins are installed. For example: no tracking without consent, guidelines regarding executable code, dismissible notices, trialware, etc.

There are two specific cases we want to mention because they will be useful in analyzing the different casuistries:

• Inform users and ask for permission: Users must be adequately informed of the actions they are taking and be able to decide whether they want to perform that action or not, otherwise that would be considered dishonest towards the users.
• The guideline regarding executable code via third-party systems, mentions this specific case which won’t be allowed: “Serving updates or otherwise installing plugins, themes, or add-ons from servers other than WordPress.orgWordPress.org The community site where WordPress code is created and shared by the users. This is where you can download the source code for WordPress core, plugins and themes as well as the central location for community conversations and organization. https://wordpress.org/’s”. This simply means that a plugin will not be able to perform the installation of another plugin that is not in the directory. The way to install plugins that are not part of the directory will be a manual installation by the user.

Why install other plugins?

We have narrowed it down to two main reasons: Extended plugins and Recommendations.

Extended plugins

There are plugins that extend other plugins. Technically, they need the extended plugin to work.

A common example of this is a payment gateway integration for WooCommerce, which of course requires the WooCommerce plugin as it’s extending it.

In this case, the installation of that other plugin is a requirement, since the plugin won’t be able to work without it.

For plugins available in the directory, this just got a lot easier since the WordPress core now includes support for required plugins. If you have a plugin that extends another plugin in the directory, we recommend that you use it.

Recommendations

There are many different cases within this classification, here are some:

• Cooperating plugins: There are plugins that can do more when used with other plugins; they are designed to integrate and work well together. They do not need the other plugin to work, but if they have it, they can integrate its functionality.
  An example of this is Contact Form 7, which integrates with Akismet to detect spam when available.
• Plugin ecosystems: There are plugins that, even if they are not integrated and they do different things, they may be from the same author, same set of plugins, they offer the same experience to the user, and they just recommend the user to try these other plugins that are in this so-called ecosystem.
• Other recommendations: Just nice and friendly recommendations of other plugins, in some cases also paid recommendations.
• Pro / Premium versions of the plugin: Another version of the plugin or an add-on for the plugin that provides additional functionality.

In any case, after reading this list, you can probably forget about it completely, because while there are different reasons behind it, they all fall into the same categoryCategory The 'category' taxonomy lets you group posts / content together that share a common bond. Categories are pre-defined and broad ranging.: a plugin recommendation and their installation should be optional.

How are other plugins installed?

We have narrowed this down to the following 4 cases in essence.

Manually

The plugin informs the user that another plugin is recommended or required. Then the plugin must be manually installed by the user, either using the search plugins feature (if the plugin is in the directory), uploading a zip file, or uploading it to the /plugins/ directory.

Using the CoreCore Core is the set of software required to run WordPress. The Core Development Team builds WordPress. UXUX UX is an acronym for User Experience - the way the user uses the UI. Think ‘what they are doing’ and less about how they do it.

This also informs the user that another plugin is recommended or required, but instead of asking the user to manually install it, it uses the interface that the WordPress core already provides to install it.

In this case, the user seems to be well informed right out of the box. They can see the plugin’s name, description, version, etc. and the call to action is a clear button with the text “Install Now”.

Using a Custom UX

In this case, the install functionality is built into a custom interface that takes care of displaying information about the plugin being installed and asking the user for permission to install it. This is often embedded in an options page and in setup wizards or onboarding processes.

In this interface it’s important to get the user’s consent after providing them with sufficient information about what’s being installed.

No-asking

Automatically install plugins without informing the user and/or asking for their permission. This is expressly not allowed.

Let’s summarize

Ok, too much information: typologies, interfaces, guidelines. Let’s narrow this down.

Why install other plugins?	Extended plugins	Recommended plugins
As a requirement	✅	❌
Optionally	N/A	✅

How are other plugins installed?	Manually	Core UX	Custom UX	No-asking
Plugins in the directory	✅	✅	✅	❌
External plugins	✅	❌	❌	❌

What do we need your help for?

Now that we’ve clarified what is and isn’t allowed in terms of installing other plugins under the current guidelines, let’s take a closer look at a common case that we know is causing confusion for both plugin authors and users: information and consent regarding plugins that are installed using a Custom UX.

This is because while the general rule is “get the user’s consent after providing them with sufficient information about what’s being installed”, we recognize that this is on a case-by-case basis, and is somewhat subjective.

This team does not have specific details about what these interfaces should contain or how they should work, which leads to different criteria. We also realize that interfaces are complicated to regulate; it’s challenging to define specific details for them that are applicable in all cases, sufficiently clear, easily understandable and applicable and durable over time.

The number one goal we want to achieve with your help is to improve user information and consent, so that users have all the information they need to make a decision about installing a plugin, and a clear and easy way to give their consent. The lack of information or processes where the user was not aware of the action they were taking is an issue that users have reported to us and, after investigation, we believe needs to be addressed.

We have some suggestions on what plugin authors can do to achieve this goal (if applicable to their case). Please feel free to mix and match these suggestions and make your own, any feedback towards this goal is welcome. Note that there are suggestions that can be combined with each other.

Suggestion 1: Make clearer that it’s going to install a plugin

We have found cases where it is mentioned that a plugin will be installed, but it is done in a way that is not clear to the user, as it is mentioned in a smaller font, separated from the option, and/or using other techniques that in practice do not make it clear what the main action will be.

One suggestion would be to make the information about installing a plugin the most prominent information in the area where the user chooses to install it.

Suggestion 2: Avoid pre-selected options

We have found cases where the option to install a plugin is pre-selected and the user has to explicitly uncheck it to avoid installation.

A suggestion would be to make that option not selected by default, so that the user has to take explicit action regarding that particular plugin in order to install it.

Suggestion 3: Avoid multi-install, install one at a time instead

There are cases where several different plugins are installed at the same time during the process.

One suggestion would be to require plugins to be installed one at a time in a process that requires explicit user action to install them, by clicking a button that clearly states what it does.

Suggestion 4: Provide additional information about the plugin

We see cases where the information about the plugin is pretty much limited to the name, there is other information that could be really useful for the user to make an informed decision about the plugin they are about to install.

One suggestion is to provide access to all information about the plugin, and perhaps the easiest way to do that would be to clearly link to the WordPress.org plugin page for that plugin.

Suggestion 5: Use the Core UX to install the plugin.

The WordPress core includes an interface that can be used to install a plugin, and it meets most of the suggestions already mentioned: It’s clear, it’s not pre-selected, install them one by one and it gives all the information. Also, it would be a really clear definition of what’s allowed (the definition: only this).

The downside is that users lose the integrated interface and experience that a plugin could provide to perform those operations. There are some plugins that create really great onboarding forms, and users can lose a bit of that experience by having a modal window with a different aspect when asked to install another plugin.

The suggestion in this case would be to route any plugin installation process through this interface.

Next steps

This post will be updated after getting your feedback and the team makes a decision.

After that, there will be a 3-month period during which plugin authors will be able to make the necessary changes to meet this common goal of improving user information and consent.

Please share your feedback in the comments. Thanks!