Make WordPress Core

Opened 3 years ago

Last modified 2 years ago

#53979 new defect (bug)

Non-valid plugins should be removed from the 'active_plugins' option

Reported by: tommusrhodus's profile tommusrhodus Owned by:
Milestone: Awaiting Review Priority: normal
Severity: normal Version:
Component: Plugins Keywords: has-patch
Focuses: Cc:


Issue as found

Failed auto-update of WooCommerce resulted in an empty /woocommerce/ plugin folder, but woocommerce/woocommerce.php remaining inside the active_plugins option resulted in a dependent plugin throwing a fatal error, since its internal checks against the active_plugins option still returned true.

To recreate this issue, a default install with WooCommerce & WooCommerce Subscriptions plugins installed is enough. Empty the contents of the /woocommerce/ plugin folder to simulate a failed auto-update, there will now be a fatal error on front-end and admin.

Note that whilst I ran into this issue with WooCommerce & WooCommerce Subscriptons, this issue could theoretically happen with any plugin and extension plugin combination that uses the active_plugins option to determine if dependency has been met.


Plugins which fail to validate inside wp_get_active_and_valid_plugins() should also be removed from the active_plugins option to avoid further clashes and potential fatal errors. Currently the function excludes the plugins from loading, but leaves the plugin key inside the active_plugins option which can be problematic if dependant plugins are checking that option for the parent plugin key.

Expected outcome would be that a plugin which fails to validate for any reason should also be removed from the active plugins option.

Proposed solution

If a plugin fails to validate it should not just be excluded from loading at runtime, but also its key removed from the active_plugins option to avoid loading attempts in the future, and further issues caused by dependant plugins. I have tested a patch within wp_get_active_and_valid_plugins() which resolves this, should this bug report be accepted.

Acknowledgement of plugin specific issue

I appreciate that at first glance this appears like a plugin specific issue in that without the parent / dependant plugin structure using active_plugins as a dependency check then there would be no issue here.

However given the ubiquitous nature of something like WooCommerce and their developer docs pointing toward using active_plugins as a dependency check, it's clear that WordPress users getting a WSoD from a failed plugin update could be avoided with a core patch.

Change History (5)

#1 @sabernhardt
3 years ago

  • Component changed from General to Plugins

#2 @SergeyBiryukov
3 years ago

Hi there, welcome to WordPress Trac! Thanks for the report.

Just linking to some related tickets here: #27994, #52048.

Failed auto-update of WooCommerce resulted in an empty /woocommerce/ plugin folder

This should hopefully occur less often once the PR in #51857 is committed.

This ticket was mentioned in PR #1618 on WordPress/wordpress-develop by tommusrhodus.

3 years ago

  • Keywords has-patch added

Updates wp_get_active_and_valid_plugins() to remove invalid plugins from the active_plugins option. This help to avoid two things:

  1. Constantly checking a broken plugin on load.
  2. Dependent extension plugins which use the active_plugins option as a dependency check can get a false positive if the main plugin has broken. This breakage can happen on a plugin auto update and can result in fatal errors if the dependant plugins are only using active_plugins as a dependency check.

Trac ticket:

#4 @TimothyBlynJacobs
3 years ago

Something I'd be worried about is when it is a temporary error. For instance files are being replaced so on one page load, the plugin won't be "valid" and it will end up getting deactivated. Right now, this only occurs if the user visits the plugins page. In other words this is functionally changing wp_get_active_and_valid_plugins into validate_active_plugins.

#5 @audrasjb
2 years ago

  • Version trunk deleted

I'm removing the trunk version since the issue described in this ticket was not introduced in WP 5.9.

Note: See TracTickets for help on using tickets.