Plugin in another plugin folder causes Activate link to be wrong on Download

[joehoyle]

I am not sure if shipping a plugin within another plugin is officially supported, but there is an inconsistency between the activate links in the Manage Plugins page, and the Activate Plugin on the Plugin Downloaded success page.

This is because on the Manage Plugins page, the get_plugins() is going to scan the plugins dir and all dirs within it, however, on the Upgrade page, it calls get_plugins() specifying the plugin dir as the base (see ​https://github.com/WordPress/WordPress/blob/master/wp-admin/includes/class-wp-upgrader.php#L579)

That will cause the "embedded" plugin to be picked up, and if it's alphabetically above the main plugin file (presumably) see code comment " Assume the requested plugin is the first in the list"

[joehoyle]

Perhaps this could be fixed by adding a second param "$search_directories" to get_plugins() which is set to false in the Upgrader step?

I am happy to write a patch with some direction on this.

[joehoyle]

I added a patch that will order the array from get_plugins( $plugin ) with files not in directories to the top.

[dd32]

Duplicate of #21954, not closing as the other ticket doesn't have a patch.
I like the patch, and it's the preferred solution I suggested in that ticket too.

[joehoyle]

Yes, seems we had the same idea on both accounts, who do I need to bug to try get this committed?

[SergeyBiryukov]

#21954 was marked as a duplicate.

[SergeyBiryukov]

From #21954:

This issue also applies when deleting the plugin as it lists both plugins on the confirmation page.

[jdgrimes]

What is the benefit of this solution over not looking the the subdirectories unnecessarily? Adding a second parameter as suggested above would be backward compatible (if set to true be default), and wouldn't require the site to do unnecessary work.

[jdgrimes]

#26368 was marked as a duplicate.

[jdgrimes]

Interestingly, in Plugin_Upgrader::check_package(), the directory is just globed for .php files: https://core.trac.wordpress.org/browser/tags/3.9.1/src/wp-admin/includes/class-wp-upgrader.php#L686

So it seems there is an inconsistency with whether get_plugins() is even used.

[jdgrimes]

Somewhat unrelated sidenote: glob() ​may actually be faster than the current opendir()/readdir() method used in get_plugins(), in addition to being much less code (and therefore more readable).

[dd32]

#35277 was marked as a duplicate.

[ideag]

Hi! I just ran into this issue and I'd like to help closing it, but I am wondering what would be the preferred solution for it. I would probably prefer modifying get_plugins to optionally ignore sub-directories, but I've also seen suggestions to modify the order of output to make sure files directly in plugin directory are at the top of the list.

[jdgrimes]

@ideag Yeah, it seems that there are really three solutions:

• Sort the results from get_plugins().
• Add a parameter to get_plugins() to skip checking in subdirectories.
• Don't use get_plugins() at all, as in Plugin_Upgrader::check_package().

I favor the second option, since it avoids looking into the subdirectories unnecessarily. (The third option would do that as well, however, it would require duplicate logic.)

But maybe @dd32 and @SergeyBiryukov would like to give their opinion.

[ideag]

Replying to jdgrimes:

I favor the second option, since it avoids looking into the subdirectories unnecessarily. (The third option would do that as well, however, it would require duplicate logic.)

I also think the second option would be the best way to go and has the least chance of having unintended side-effects. I'll try to put together a patch and some unit tests over the weekend.

[ocean90]

#48398 was marked as a duplicate.

[ocean90]

Both, Plugin_Installer_Skin and Plugin_Upgrader_Skin, are using Plugin_Upgrader::plugin_info().

[pbiron]

22287.diff​ refreshes class-wp-upgrader.php.diff​ so that applies cleanly after all these years :-)

While patch solves the case of the plugin in #21954 (i.e., when the "additional" plugin is in a sub-directory), it's also possible to have multiple files with plugin headers directly in the plugin's dir...and the "main" plugin in that case may not necessarily be the one that is alphabetically first.

One example of a plugin that has 2 files with plugin headers at the "root" of the plugin's directory is ​https://meta.trac.wordpress.org/browser/sites/trunk/wordpress.org/public_html/wp-content/plugins/handbook

So, maybe a heuristic for that case would be to first check for a file named {$slug}.php, where $slug is the plugin's directory name. If that file exists, use it; if not, then do the sort and return as in the patch.

Thoughts?