Make WordPress Core

Opened 8 years ago

Closed 3 years ago

Last modified 3 years ago

#36373 closed defect (bug) (invalid)

Plugin update fails silently when using zipfile without subdirectory

Reported by: bjornw's profile BjornW Owned by:
Milestone: Priority: normal
Severity: normal Version:
Component: Upgrade/Install Keywords: close
Focuses: Cc:


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:


Failed zipfile contents:


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

Change History (8)

#1 @knutsp
8 years ago

  • Keywords needs-patch 2nd-opinion added


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.

#2 @knutsp
8 years ago

  • Version 4.4.2 deleted

#3 @dd32
8 years ago

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.

#4 @BjornW
8 years ago

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

This ticket was mentioned in Slack in #core-auto-updates by afragen. View the logs.

3 years ago

#7 @afragen
3 years ago

  • Keywords close added; needs-patch 2nd-opinion removed
  • Resolution set to invalid
  • Status changed from new to closed

This issue was likely closed in as an invalid plugin structure. Plugins are meant to be in containing directories.

This ticket was mentioned in Slack in #core-auto-updates by francina. View the logs.

3 years ago

Note: See TracTickets for help on using tickets.