WordPress.org

Make WordPress Core

Opened 6 years ago

Closed 6 years ago

Last modified 6 years ago

#26368 closed defect (bug) (duplicate)

get_plugins() can return false positives (plugin files that cannot be activated)

Reported by: johnbillion Owned by:
Milestone: Priority: normal
Severity: normal Version:
Component: Plugins Keywords:
Focuses: Cc:
PR Number:

Description

A plugin of mine includes a file called db.php in a subdirectory. This is a Drop-in which gets moved into WP_CONTENT_DIR upon activation. Other plugins do similar things, for example caching plugins that include an object-cache.php or domain mapping plugins which include a sunrise.php.

The db.php file in my plugin includes a plugin header so users know exactly what the file is when they view the Drop-ins tab on the Plugins screen in WordPress. This file can never be activated as a regular plugin though, because the get_plugins() function does not traverse into second-level subdirectories when scanning the plugins directory for plugin files.

So far, so good.

The problem arises when a plugin is installed using WordPress' built-in plugin installer (from the Plugins -> Add New screen). After installing a plugin, the user is presented with the option to activate the plugin immediately. The get_plugins() function is used here to scan just the newly installed plugin directory for plugin files and present the option to activate the first file with a plugin header that it finds (alphabetically).

The difference is that in this situation get_plugins() gets passed the directory name of the newly installed plugin as a parameter, and it traverses into subdirectories of the plugin when scanning for plugin files. It therefore finds the db.php file in the subdirectory, and offers it up for activation if the plugin's name comes before the actual plugin alphabetically.

The end result is that when the user clicks on "Activate plugin" they're presented with an error stating "The plugin does not have a valid header". WordPress is attempting to activate a plugin which cannot be activated.

The affected plugin in my case is Query Monitor. I've gotten around the issue by giving the Drop-in a name which comes after the actual plugin alphabetically. Many hours of head scratching were spent before I got to this point.

TL;DR the get_plugins() function should not traverse into subdirectories when it's passed a single plugin's directory name as the $plugin_folder parameter.

Steps to reproduce:

  • Create a plugin that includes a Drop-in plugin contained within a subdirectory
  • Give the Drop-in a plugin header and a name that comes before the actual plugin alphabetically
  • Try to install and activate the plugin using WordPress' built-in plugin installer (eg. zip it up and use the Upload tab)
  • Note that WordPress attempts and fails to activate the Drop-in instead of the actual plugin

Change History (3)

#1 @toscho
6 years ago

  • Cc info@… added

#2 @jdgrimes
6 years ago

  • Resolution set to duplicate
  • Status changed from new to closed

Duplicate of #22287.

#3 @ocean90
6 years ago

  • Milestone Awaiting Review deleted
  • Priority changed from lowest to normal
  • Severity changed from major to normal
Note: See TracTickets for help on using tickets.