[wp-trac] [WordPress Trac] #26368: get_plugins() can return false positives (plugin files that cannot be activated)

[WordPress Trac]

#26368: get_plugins() can return false positives (plugin files that cannot be
activated)
--------------------------+-----------------------------
 Reporter:  johnbillion   |      Owner:
     Type:  defect (bug)  |     Status:  new
 Priority:  lowest        |  Milestone:  Awaiting Review
Component:  Plugins       |    Version:
 Severity:  major         |   Keywords:
--------------------------+-----------------------------
 A plugin of mine includes a file called `db.php` in a subdirectory. This
 is a [http://wpengineer.com/2500/ 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 [http://wordpress.org/plugins/query-
 monitor/ 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

--
Ticket URL: <http://core.trac.wordpress.org/ticket/26368>
WordPress Trac <http://core.trac.wordpress.org/>
WordPress blogging software