Its been well over 10 years since this Trac ticket was created discussing plugin dependencies. There’s a few tickets around the same subject that are even older.
More recently, there’s been renewed interest in adding support for plugin dependencies with a Make P2 post and a Github repository. This post takes a look at this new feature with a few design suggestions for how it could work from the perspective of a WordPress user.
Plugin Card
When browsing the Install Plugins screen within WordPress available plugins are shown as a list of cards with details for each plugin.
With the new functionality, Plugins with requirements will display a new “Requires Plugin name” line below the author’s byline. There can many many requirements, and the interface will truncate the list with an “x more” button if it becomes too long. Pressing this button expands the list and shows all the required plugins. I expect that for more plugins, the list of requirements will be a single plugin but the design accounts for outliers.
I’m actually not sure if this new Requires line is necessary in this context; Is this information helpful when browsing and choosing to install a new plugin?
Plugin Details
In the plugin card above, you can press the More details button to open a modal with the WordPress.org plugin details page. This screen already lists a PHP and WordPress version requirement. The new design groups these requirements along with the new plugin requirements.
Installing a Plugin with Dependencies
The flow for installing plugins from the Add Plugins screen is as follows:
- Clicking the Install Now button changes it’s state to indicate the progress.
- Once completed a new Activate button appears.
- Clicking this new button (by default) loads the Installed Plugins screen with a notice stating Plugin activated.
Its important to note that the last step in this flow can be customized by the plugin being activated; Plugins can “hook” into the activate step and redirect the user anywhere they’d like — often to a plugin setup wizard or settings screen.
In the Github repository previously mentioned, a notice banner is displayed at the top of the Install Plugins screen that explains additional plugins are needed. There is then a link to a new Dependencies page.
I found this behavior confusing for a few reasons:
- There’s no visual connection or information regarding which plugin has requirements. I can assume from context that it’s the plugin I just installed, but that may not always be the case.
- There’s no indication of what a dependency is or where the link will take me.
- This adds additional work for me, the user, who is simply trying to use a new plugin. I expected WordPress to reduce the number of steps needed to allow me to use my newly installed plugin.
My first thought was to clarify the notice and place it near the plugin with the requirements.
This feels more informative and helpful, but as its not at the top of the page it might be harder to see. It also could lead to a scenario with multiple notices when there are multiple plugins with missing requirements — I don’t think this scenario will be very common, so I only mention it as an edge-case.
Another option that came to mind was to simply list required plugins at the top of the Installed Plugins screen.
Its also possible that we could avoid the need for notices or extra installation steps by introducing some friction to the beginning flow. For example, perhaps we display a dialog before the flow begins.
This dialog would inform the user about the need for additional plugins and enforce installing all requirements, redirecting users to the Installed Plugins screen when complete.
Installed Plugins
Similar to the plugin card, the list of installed plugins will show information about requirements including any plugins that may have a “parent,” or dependent plugin.
The current proposal (again, in the GH repository mentioned previously) simply disabled the ability to deactivate a plugin that is a dependency of another. We could improve this with a tooltip explaining why its disabled.
Ideally when deactivate a plugin that is required by another plugin, a new dialog could display to inform the user about the requirement and allow them to deactivate multiple, related plugins.
This could get tricky if there are stacked dependencies — dependency-inception, if you will. This is true for most of the design work in this post; If there are plugins that require plugins that require plugins, things get really complex fast.
Block Plugin Installs
The last piece of the puzzle here is related to the editor experience. Currently, when searching for blocks WordPress will also show blocks that are available to install. Many blocks might require additional plugins. The dialog option shared above could be useful when installing block plugins, making it easy to install and activate required plugins without leaving the editor’s interface.
One complication here is that many plugins — like WooCommerce in the image above — often require users to complete a setup flow or otherwise set some options before the plugin will work as expected. This could mean that the block plugin may still not work until this setup is complete.
A small idea that could help resolve that is to include a new section to the Installed Plugins screen to highlight plugins that require additional setup steps.
There’s likely a whole lot of complexity I’m glossing over, but I hope these designs can help improve and shape the direction of this new functionality for WordPress. Feel free to drop any thoughts in the comments. I’m looking to bring some of these ideas to the Github repository as well, so be sure to keep an eye there.
Leave a Reply to Fahim Murshed Cancel reply