WordPress.org

Make WordPress Core

Opened 5 years ago

Last modified 5 weeks ago

#22287 new defect (bug)

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

Reported by: joehoyle Owned by:
Milestone: Awaiting Review Priority: normal
Severity: normal Version: 3.4
Component: Upgrade/Install Keywords: needs-patch dev-feedback
Focuses: Cc:

Description

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"

Attachments (1)

class-wp-upgrader.php.diff (1.0 KB) - added by joehoyle 5 years ago.

Download all attachments as: .zip

Change History (20)

#1 @joehoyle
5 years ago

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.

#2 @joehoyle
5 years ago

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

#3 @dd32
5 years ago

  • Component changed from Plugins to Upgrade/Install

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.

#4 @joehoyle
5 years ago

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

#5 @SergeyBiryukov
5 years ago

#21954 was marked as a duplicate.

#6 @SergeyBiryukov
5 years ago

From #21954:

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

#7 @SergeyBiryukov
5 years ago

  • Version changed from trunk to 3.4

#8 @jdgrimes
4 years ago

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.

#9 @jdgrimes
4 years ago

#26368 was marked as a duplicate.

#10 @toscho
4 years ago

  • Cc info@… added

#11 @johnbillion
4 years ago

  • Cc johnbillion added

#12 @jdgrimes
3 years ago

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.

#13 @jdgrimes
3 years ago

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).

#14 @chriscct7
22 months ago

  • Keywords needs-patch added

#15 @dd32
21 months ago

#35277 was marked as a duplicate.

This ticket was mentioned in Slack in #core by arunas. View the logs.


5 weeks ago

#17 @ideag
5 weeks ago

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.

#18 follow-up: @jdgrimes
5 weeks ago

  • Keywords dev-feedback added

@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.

#19 in reply to: ↑ 18 @ideag
5 weeks ago

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.

Note: See TracTickets for help on using tickets.