[wp-trac] [WordPress Trac] #59375: Plugin_Upgrader assumption causes incorrect "Activate Plugin" link after plugin installation resulting in "The plugin does not have a valid header" error

[WordPress Trac]

#59375: Plugin_Upgrader assumption causes incorrect "Activate Plugin" link after
plugin installation resulting in "The plugin does not have a valid header"
error
--------------------------------+------------------------------
 Reporter:  michelleblanchette  |       Owner:  (none)
     Type:  defect (bug)        |      Status:  new
 Priority:  normal              |   Milestone:  Awaiting Review
Component:  Plugins             |     Version:  6.3.1
 Severity:  normal              |  Resolution:
 Keywords:  has-patch           |     Focuses:
--------------------------------+------------------------------

Comment (by michelleblanchette):

 Hi, Andy. Thank you for reviewing this ticket.

 I'm not sure what you mean by "nested plugin", but I am aware that the
 agreed upon practice is to use the `hello-pro/hello-pro.php` naming
 convention for the plugin's main file. That is, where the plugin's dirname
 slug matches the main PHP file's basename.

 I'm talking about an issue where a plugin included within a plugin
 (specifically at the main level) is being incorrectly recognized by the
 `Plugin_Upgrader` class's use of `get_plugins()`.

 Including a plugin within another plugin as a library is not uncommon,
 [https://www.advancedcustomfields.com/resources/including-acf-within-a
 -plugin-or-theme/ as described by the popular Advanced Custom Fields
 plugin].

 In my example case, I'm referring to a simplified example where you have
 the following file structure:

 {{{
 /plugin-name
      plugin-name.php
      /base-plugin
           base-plugin.php
      ...
 }}}

 `plugin-name/plugin-name.php` is the plugin to be installed and activated.
 `/plugin-name/base-plugin/base-plugin.php` is simply included within the
 main plugin file to execute its functionality. The reason for doing this
 is to include plugin dependencies at a guaranteed compatible version. But
 that's besides the point.

 The main point is that `Plugin_Updater::plugin_info()` produces the
 incorrect plugin basename when a plugin includes another plugin in this
 way, contrary to the `WP_Plugins_List_Table` "Activate" link which
 produces the correct basename.

 My linked patch prevents the "nested plugins" issue that you might be
 referring to, which `Plugin_Updater::plugin_info()` currently wrongly
 attempts to allow.

-- 
Ticket URL: <https://core.trac.wordpress.org/ticket/59375#comment:4>
WordPress Trac <https://core.trac.wordpress.org/>
WordPress publishing platform