Multiple plugins in the single folder can cause unexpected situations with Upgrades

[hakre]

Some Plugins are a set of Plugins in one directory which might get update one for each other.

To test if that works with the WordPress Plugin Install/Update API and Backend, a testcase is needed.

[hakre]

Plugin Testcase

[hakre]

Plugin Testcase with Plugins A and B with two Versions each (0.1 and 0.2).

Test:

# Install Plugin A 0.1

# Activate Plugin A 0.1

# Install Plugin B 0.1

# Activate Plugin B 0.1

# Update Plugin A with Version 0.2 via ZIP Upload

Plugin A 0.2 and Plugin B 0.2 should be activated.

[Denis-de-Bernardy]

while possibly desirable for some reasons, I'm pretty certain this'll get closed as wontfix -- the WP.org scripts will need an update as a result, and a quick look at the wordpress.org component will reveal that even the simplest of tasks related to wordpress.org aren't fixed before *ages*.

[hakre]

Denis, this a Testcase. Not a Feature to be implemented nor was said that the current version has a Bug.

[Denis-de-Bernardy]

Genau, aber... it work work. For things to work as you'd want, it'll need wordpress.org script upgrades on wordpress.org. I know, because I wrote a script to automatically upgrade wp, packaged with a couple of plugins, on my server recently. The only needed argument in the upgrade API is:

$package/$package.php' => array('Name' => '$package')

And unless I'm mistaking it's the second bit that is important, rather than the first. (Else, you'd get odd results in the plugins repository.)

To get some idea of how fast wordpress.org tickets get closed:

​http://core.trac.wordpress.org/milestone/Unassigned

So Future seemed right.

[DD32]

Thanks for the utterly useless OP in the ticket.. (Seriously, Trac is not for testing things out, Do it yourself and report it as a bug if it doesn't work for you)

There is a slight rare case in this however, Which I've been aware of, But havnt had anyone actually have an issue with yet.

If multiple plugins exist in a directory, And one of the plugins is then selected for upgrade this will happen:

• The selected plugin will be deactivated
  • Not the other plugins in the directory, They stay activated during the upgrade
• The selected plugin gets upgraded to the latest
  • Note: If the other plugins didnt exist in the upgrade package, they're completely removed.
    • Not changing this fact anytime soon
• The upgrade suceeds
  • Selected plugin is upgraded
    • As well as any other plugin which existed within the archive.
  • The selected plugin goes through the re-activation error-check
    • The upgrader assumes the FIRST plugin it finds is the actual plugin that got upgraded (The reasoning for this is, That the plugin filenames DO change between upgrades sometimes. A better method is to check the plugin header "Name" and base it off that if possible, else revert to the first plugin)
    • The other plugins do NOT get run through this, since they were never deactivated.

This has NOTHING to do with the WordPress.org side, it makes NO difference no matter what angle you look at it from. Nor is trac for Test cases.

An example of a plugin which did this, Was NextGen Gallery, However, Its no longer doing it that way - For whatever reason. ​http://plugins.svn.wordpress.org/nextgen-gallery/trunk/nggwidget.php suggests something to do with the fact the widget plugin could be changed/different from what was actually included in the upgrade archive.

There are not many plugin which have multiple plugins per directory, Most are now in separate archives.

Changed Title to reflect the actual issue.

Changed Milestone to Future pending a patch (Thats tested). But Any patch will be for 2.9 at this stage, Its simply too late to change it in 2.8 & get adequate testing for whatever process is chosen.

Personally i'd prefer to say "NO! Only one plugin per directory!" and close this as wontfix, One-plugin-per-directory has been the way that has been prefered for awhile now, But isnt actually enforced at a code-level, or WordPress.org Plugin hosting either.

[Denis-de-Bernardy]

+1 to that.

[hakre]

DD32, thanks for the detailed clarification.