Plugin update fails silently when using zipfile without subdirectory

[BjornW]

While ​extending github-updater for use with Bitbucket Server aka Stash I've noticed that the WordPress upgrader/updater needs a plugin update in a zipfile within a subdirectory named after the plugin slug. E.g.

Working zipfile contents:

plugin_slug
  plugin.php 
  another_file.php
  some_directory/

Failed zipfile contents:

plugin.php 
another_file.php
some_directory/

notice the missing subdirectory

Without the correct zipfile structure the WordPress plugin update process looks successful, but it will silently fail and the plugin you wanted to update just disappears. Instead of failing silently, I'd suggest to inform the user that an incorrect update format was supplied. Btw the manual 'upload new plugin' in wp-admin/plugin-install.php?tab=upload does not care about having a subdirectory or not.

Steps to reproduce this issue:

• create a zipfile with the plugin files in the root
• use an external updater such as github-updater to deliver the zip file to WordPress (as if using api.wordpress.org)
• update your plugin
• the plugin update process will state it was successful, but your plugin will be de-activated due to it being removed by the update process without the updated replacement.

[knutsp]

Alternatively:

I guess it could succeed if a folder named after the zip file base name was created in %plugins-dir%, and the zip file contents extracted to this folder.

[dd32]

I don't have a reference, but there's discussion of this elsewhere in Trac somewhere.

It's also worth noting that plugin installs which don't include the plugin name will at present create a directory called plugin-name-zAdo4mx5 (basename of the zip, plus 8 characters of random data).

Folder-less zips are not officially supported, but installing from them works as it simply does the best it can to deal with the random data present in the zip (as it's a user-supplied zip). That same mechanism proved not ideal for updates for various reasons (which I can't recall).

IMHO, this is a wontfix. There's been a discussion of this previously on Trac for updating with Github, and I provided the filter details which the custom updater could use to achieve the intended result, unfortunately I can't find that ticket.

[BjornW]

@dd32 In my tests it did not create a directory with 8 characters when using the updater process. It just failed silently. Installing the same zip using 'upload new plugin' in wp-admin/plugin-install.php?tab=upload did work, although I can't remember it creating a plugin directory with 8 random chars. If this is a wontfix, I'd suggest to at least generate an error message so that users (and future developers) are not left in the dark. Perhaps an early check on the zipformat / result can yield this?

[SergeyBiryukov]

Related: #35217

[afragen]

This issue was likely closed in ​https://github.com/afragen/github-updater as an invalid plugin structure. Plugins are meant to be in containing directories.