Merge Announcement: Plugin Dependencies ![rw-book-cover](https://make.wordpress.org/core/files/2024/02/image-10.png) ## Metadata - Author: [[Make WordPress Core]] - Full Title: Merge Announcement: Plugin Dependencies - Category: #articles - Document Note: ## Table of Contents: - Index Creation - Summary - Main Content - References - Paraphrase - Hypotheses - Methodology - Questions - Future Research - Implications - Logical validity - Conclusion ## Index Creation: - Extensibility of WordPress through plugins and the Hooks API - Inconsistent implementations of informing users about plugin dependencies - Implementation details of the Plugin Dependencies feature - Viewing, installing, and activating dependencies - Automatic deactivation of dependent plugins - UI changes in the Plugins > Installed plugins and Plugins > Add New screens - User testing and outcomes - Security considerations - Accessibility concerns - Unit tests and test coverage ## 📝 Summary: The Plugin Dependencies feature aims to improve the consistency and ease of use when installing/activating addons and their dependencies in WordPress. The feature allows plugin authors to declare their dependencies in a new header, and users can easily view, install, and activate the required plugins. Automatic deactivation of dependent plugins has been removed, and third-party plugins not hosted on WordPress.org will have to be manually installed. The UI has been updated to display dependencies and their status in the Plugins > Installed plugins and Plugins > Add New screens. ## 📖 Main Content: The main idea of the Plugin Dependencies feature is to enhance the extensibility of WordPress through plugins and the Hooks API. Currently, plugin authors use different methods to inform users about the dependencies of their plugins, resulting in inconsistency and incompleteness. The feature introduces a new header called "Requires Plugins" in a dependent plugin's main file, where authors can declare their dependencies using WordPress.org slugs. Version management support, such as specifying minimum and maximum versions, is not supported at the moment. To view, install, and activate dependencies, users can go to the Plugins > Add New screen where dependencies are listed in the dependent plugin's card. Clicking on the "View Details" link opens a modal with information about the dependency and buttons to install and activate it. The modal remains persistent, allowing users to install and activate multiple plugins without leaving the current context. However, automatic redirection upon activating a plugin from Plugins > Add New is no longer available. Dependent plugins with unmet dependencies are no longer automatically deactivated. Instead, plugins not hosted on WordPress.org will have their dependencies displayed, but manual installation is required. The UI changes include listing dependencies in the Plugins > Installed plugins screen and providing links to their information modals. The Activate, Deactivate, and Delete actions for plugins are enabled/disabled based on the status of their dependencies and dependents. ### 🗒️ Notes - The Plugin Dependencies feature improves the consistency and ease of installing/activating addons and their dependencies in WordPress. - Plugin authors can declare their dependencies using the "Requires Plugins" header in their main file. - Dependencies are listed in the Plugins > Add New screen with buttons to install and activate them. - The modal for dependency information remains persistent and allows for installing and activating multiple plugins without leaving the current context. - Automatic redirection upon activating a plugin from Plugins > Add New is no longer available. - Dependent plugins with unmet dependencies are no longer automatically deactivated. - Third-party plugins not hosted on WordPress.org can be declared as dependencies but require manual installation. - UI changes include listing dependencies in the Plugins > Installed plugins screen and providing links to their information modals. - The Activate, Deactivate, and Delete actions for plugins are enabled/disabled based on the status of their dependencies and dependents. ## 📖 References: - No references provided in the source material. ## 🗣️ Paraphrase: 1. The Plugin Dependencies feature aims to make it easier for users to install and activate addons and their dependencies in WordPress. Currently, plugin authors use different methods to inform users about dependencies, leading to inconsistency. The feature introduces a new header for declaring dependencies and provides a consistent way for users to view, install, and activate required plugins. 2. Plugins that depend on other plugins can now declare their dependencies using the "Requires Plugins" header. This header contains a comma-separated list of WordPress.org slugs for the dependencies. However, version management support is not yet supported. ## 🧪 Hypotheses: - Future studies could investigate the impact of the Plugin Dependencies feature on user experience and plugin adoption rates. - Research could explore the best practices for declaring and managing dependencies in plugins, including version management and compatibility considerations. - Studies could evaluate the effectiveness of the new UI changes in improving user understanding and interaction with plugin dependencies. ### 📊 Methodology: - Conduct user surveys or interviews to gather feedback on the Plugin Dependencies feature and its impact on user workflows. - Analyze plugin repositories and user reviews to identify patterns in how dependencies are declared and managed by different plugin authors. - Perform usability testing on the new UI changes to assess their effectiveness in guiding users through the installation and activation of plugins with dependencies. ### ❓ Questions: - How might the Plugin Dependencies feature impact the plugin development ecosystem in terms of plugin compatibility and version management? - What are the potential challenges or limitations of the Plugin Dependencies feature when dealing with third-party plugins not hosted on WordPress.org? - How can plugin authors be encouraged to consistently declare and manage their plugin dependencies to improve the user experience? ### 🔮 Future Research: - Further research is needed to explore the impact of the Plugin Dependencies feature on the overall stability and performance of WordPress websites. - Future studies could investigate the potential security implications of the Plugin Dependencies feature and recommend best practices for plugin authors. - Research could also explore the scalability of the Plugin Dependencies feature, particularly when dealing with a large number of plugins and dependencies. ### 💡 Implications: - The Plugin Dependencies feature has the potential to greatly improve the user experience of installing and activating plugins in WordPress by providing a consistent and easy-to-use mechanism for handling dependencies. - This feature could also lead to increased plugin adoption as users are more likely to install and activate plugins that clearly declare their dependencies and provide an intuitive way to install them. - From a development perspective, the Plugin Dependencies feature highlights the importance of consistent and standardized methods for declaring and managing dependencies in plugin development. ### ✅ Logical validity: The main arguments presented in the source material are logical and coherent. The Plugin Dependencies feature addresses the inconsistent methods of informing users about plugin dependencies and provides a standardized way for plugin authors to declare and manage their dependencies. The implementation details, UI changes, and outcomes have been carefully considered and discussed. There are no apparent logical fallacies employed in the article. ## 🎯 Conclusion: Overall, the Plugin Dependencies feature aims to enhance the extensibility of WordPress through plugins and provide a consistent and easy-to-use mechanism for handling dependencies. The feature allows plugin authors to declare their dependencies using a new header, and users can view, install, and activate the required plugins from the Plugins > Add New screen. The UI changes in the Plugins > Installed plugins screen provide a clearer overview of dependencies and their status. While automatic deactivation of dependent plugins has been removed, users can still manually install missing dependencies. The Plugin Dependencies feature has undergone user testing, security reviews, and accessibility considerations. It has the potential to improve the user experience, increase plugin adoption, and promote consistent plugin development practices. - Summary: The Plugin Dependencies feature in WordPress aims to make the process of installing and activating addons and their dependencies consistent and easy to use. Currently, plugin authors have their own ways of informing users about the plugins they depend on, which can be inconsistent and incomplete. With the new feature, plugin dependencies can be declared using a new Requires Plugins header in the main file of the dependent plugin. The feature also includes changes to the user interface on the Installed Plugins and Add New screens to list dependencies and allow for the installation and activation of dependencies. The feature has undergone user testing and security and accessibility reviews, and unit tests have been written for the public API. - URL: https://make.wordpress.org/core/2024/02/15/merge-announcement-plugin-dependencies/?ref=dailydev *Note: This post was updated to add the “Third-party plugins not hosted on WordPress.org” section. 15th February, 2024 – [@costdev](https://profiles.wordpress.org/costdev/)* #### Purpose & Goals Extensibility of WordPress through plugins and the Hooks API is one of its most beneficial features. There are many plugins that act purely as extensions of others, building functionality on top. The Plugin Dependencies feature aims to make the process of installing/activating addons (dependents) and the plugins they rely on (dependencies) consistent and easy to use. Plugin authors are currently implementing their own ways of informing users about other plugins that they depend on. The implementations are inconsistent and sometimes incomplete. Users are often left to search for and install the other required plugins themselves. The feature does not intend to replace the need for defensive coding within dependent plugins, or ensure version compatibility with their dependencies; nor does it seek to mitigate the vast array of potential plugin interactions. For WordPress and/or PHP incompatibilities, Core already has handling for preventing installing, updating, or activating plugins with unmet requirements. #### Implementation Details A plugin’s dependencies can be declared by the use of a new `Requires Plugins` header in the dependent plugin’s main file. This must contain a comma-separated list of WordPress.org slugs for its dependencies, such as `jetpack` (`jetpack/jetpack.php` is not supported). It does not support commas in plugin slugs. **Example** ``` /**  * Plugin Name: Bridge for Foo and Bar  * Requires Plugins: foo, bar  */ ``` Version management support, such as providing specific minimum and maximum version numbers through the `Requires Plugins` header value, is not currently supported. ##### Requirements Declaring a plugin dependency places the following requirements: 1. **Bridge for Foo and Bar** can only be installed once **Foo** and **Bar** have been installed. 2. **Bridge for Foo and Bar** can only be activated once **Foo** and **Bar** have been activated. 3. **Foo** and **Bar** can only be deactivated once **Bridge for Foo and Bar** has been deactivated. 4. **Foo** and **Bar** can only be deleted once **Bridge for Foo and Bar** has been deleted. ##### Viewing, installing and activating dependencies In the **Plugins > Add New** screen, dependencies are listed in the dependent’s plugin card. Next to these is a *View Details* link to open a dependency’s information modal. The dependency can be installed and activated using the buttons in the modal’s footer. Previously, the modal would close upon clicking the *Install Now* or *Activate* button. The feature makes the modal persistent, and the buttons used in the plugin cards and modal now use the same underlying markup and functionality for consistency and reduced maintenance burden. The side effect of this shared functionality is that automatic redirection upon activating a plugin from **Plugins > Add New** is no longer available. This has the benefit of not redirecting a user away from the **Plugins > Add New** screen for each plugin, removing them from their current context. Users can therefore install and activate multiple plugins without leaving their current context. For plugins with onboarding experiences, they often have additional logic in case a plugin is installed and activated through a tool such as WP-CLI, so that the user is still presented with the onboarding experience upon navigating to a screen deemed an appropriate starting place. ##### Automatic deactivation of dependent plugins As currently implemented, plugins with unmet dependencies are automatically deactivated. While this was the approach suggested in initial discussions, there were valid concerns raised about this behavior after merging into `trunk`. **These have been weighed and discussed, and a decision was made to remove this behavior.** ##### Third-party plugins not hosted on WordPress.org Defining plugins not hosted on WordPress.org as dependencies will enforce and display the dependencies to the user. However, there will be no ability to install the missing plugins through the UI changes, and these will need to be installed manually. #### UI changes The feature makes changes to the UI on two screens: **Plugins > Installed plugins**, and **Plugins > Add New**. ##### Design Feedback Design feedback was requested on the ticket and responses were received from [@azaozz](https://profiles.wordpress.org/azaozz/), [@paaljoachim](https://profiles.wordpress.org/paaljoachim/) and [@karmatosed](https://profiles.wordpress.org/karmatosed/) on [the ticket](https://core.trac.wordpress.org/ticket/22316#comment:277) and on [the Feature Plugin repository](https://github.com/WordPress/wp-plugin-dependencies/issues). ##### Plugins > Installed plugins The following changes are made: 1. Dependent plugin rows now contain a list of their dependencies, linked to the respective plugin modal to install and activate the dependency. 2. Dependency plugin rows now contain a list of their dependents. 3. If a plugin has dependencies that are not installed and active, the *Activate* link is disabled. 4. If a plugin has dependents that are active, the *Deactivate* and *Delete* links are disabled. [![Plugin rows without listing any dependents or dependencies.](https://make.wordpress.org/core/files/2024/02/image-9.png)](https://make.wordpress.org/core/files/2024/02/image-9.png)No dependents or dependencies are listed. [![Plugin rows for a dependent and its two dependencies. The plugin row for a dependency shows a list of plugins that depend on it, and a dependent's plugin row shows a list of plugins that it depends on. The dependent's plugin row links the names of each dependency to a modal with buttons to install and activate the dependency.](https://make.wordpress.org/core/files/2024/02/image-10.png)](https://make.wordpress.org/core/files/2024/02/image-10.png)Dependents and dependencies are listed, and actions are enabled/disabled based on the status of requirements. ##### Plugins > Add New The following changes are made: 1. If a plugin has unmet dependencies, the *Install Now* and *Activate* buttons are disabled, both in their plugin card and their plugin information modal. 2. Dependent plugin cards now contain a notice listing their dependencies, with a *View Details* link to the dependency’s information modal which contains *Install Now* or *Activate* buttons based on their current installation status. 3. Plugin information modals are now persistent after button clicks, and modal-based plugin installation and activation are now performed through AJAX directly within the modal. [![A plugin card that does not list dependencies for the plugin, and allows installation even if the dependencies are not installed first.](https://make.wordpress.org/core/files/2024/02/image-3.png)](https://make.wordpress.org/core/files/2024/02/image-3.png)Plugin card with no dependencies listed and an active Install Now button despite unmet dependencies. [![A plugin card with a notice containing a list of dependencies and a link to open a modal with buttons to install and activate the dependency](https://make.wordpress.org/core/files/2024/02/image-1.png)](https://make.wordpress.org/core/files/2024/02/image-1.png)Plugin card with dependencies listed with modal links to install and activate each dependency, and the “Install Now” button disabled while dependencies are unmet. #### User Testing The feature team released calls for testing in [October 2022](https://make.wordpress.org/core/2022/10/12/call-for-testing-plugin-dependencies/) and [March 2023](https://make.wordpress.org/core/2023/03/28/call-for-testing-plugin-dependencies-ux/). Additional user testing was performed during design and technical feedback with reports on the ticket and in the [#core-upgrade-install](https://make.wordpress.org/core/tag/core-upgrade-install/) Slack channel up to the day of commit. ##### Outcomes Based on responses to calls for testing, and design and technical feedback, the following UI changes were made: 1. Admin notices for each unmet dependency were reduced to a single notice informing the user that there were plugins with unmet dependencies. 2. A dedicated *Dependencies* tab was removed from the **Plugins > Add New** screen in favour of an integrated solution in plugin rows on **Plugins > Installed plugins** and plugin cards on **Plugins > Add New**. 3. The plugin row on **Plugins > Installed plugins** had a *Manage Dependencies* action link removed, which linked to the removed *Dependencies* tab. 4. Messaging was improved to inform the user about missing dependencies. ##### Security A security review was performed by [@costdev](https://profiles.wordpress.org/costdev/) during the development of the feature following WordPress security best practices of escaping output, sanitizing input (slugs, *POST, etc.*), verifying AJAX referrers and using nonces where appropriate. Comparisons were also done with existing functionality to avoid missed opportunity for hardening the feature. ##### Accessibility The feature was reviewed by the team for accessibility concerns. In addition, [@costdev](https://profiles.wordpress.org/costdev/) reached out to [@joedolson](https://profiles.wordpress.org/joedolson/) regarding the use of links (`<a>`) as buttons, rather than `<button>` elements. It was deemed that this approach, though likely not ideal, is consistent with the patterns throughout the code base today. A wider conversation is needed before a decision can be made about this specific accessibility pattern at a later date. `wp.a11y.speak()` is implemented where appropriate in Javascript, consistent with prior functionality in Core. ##### Unit Tests In addition to user testing, testing by Core developers, and the feature team, unit tests have been written for the feature and the public API is covered. There are plans to continue increasing test coverage during the 6.5 Beta period., Merge Announcement: Plugin Dependencies, Make WordPress Core, 01hppmfm3q3yabc9ch0gqh5eq1.