Make WordPress Core

Opened 8 years ago

Last modified 5 days ago

#9757 new feature request

Allow Plugin/Theme updates from a uploaded .zip file.

Reported by: hakre Owned by:
Milestone: Future Release Priority: low
Severity: normal Version: 2.8
Component: Upgrade/Install Keywords: dev-feedback has-patch needs-refresh
Focuses: Cc:

Description (last modified by SergeyBiryukov)

Plugin administration lacks of an update possibility by uploading zip files. This feature is only half-done in 2.7, you can only upload plugins as zip to install them, not to update them.

Zip file uploads should be treated the same as the other install/update possibilities like remote.

#9708 provides a testcase that can be used to test such am update by zip.

currently a over-upload in the install page does throw an error that the directory already exists:

Installing Plugin from uploaded file: 9708-plugin-testcase-9708-plugin-a-v-0.2.zip

Unpacking the package.

Installing the plugin.

Destination folder already exists. [...]worpress-trunk/wp-content/plugins/9708-plugin-testcase/

Plugin Install Failed.

Attachments (1)

upload_upgrade.diff (5.4 KB) - added by cyberhobo 6 years ago.
Refresh, improvements

Download all attachments as: .zip

Change History (59)

#1 @DD32
8 years ago

  • Component changed from Plugins to Upgrade/Install
  • Milestone changed from Unassigned to Future Release
  • Priority changed from normal to low
  • Summary changed from Install of plugin as zip is possible but update is not. to Allow Plugin/Theme updates from a uploaded .zip file.
  • Type changed from defect (bug) to enhancement

Moving to a Future release, If its so chosen to be integrated at some stage.

Personally. I'd prefer to leave it to plugin material (I may even write something for that).

If a trac admin could edit that description to remove the huge code block, that'd be nice.

#2 @hakre
8 years ago

If this is rated as plugin material then I would suggest to move the current remote installer in the plugin domain as well. I mean, it's more important to be able to install from zip then from third party remote even that is wordpress.org.

And for clearing the mess in the code example above: please, yes.

#3 @DD32
8 years ago

My reasoning was this:

  • For Installs: You've only got a source to deal with, its a straight up install.
  • For Upgrades: You're upgrading a specific plugin, It'd need to be set to select the plugin/theme to upgrade. The automatic upgrades are more suited to an automatic thing IMO. Theres nothing stopping plugins from adding their own update notifications + automatic upgrades.

Other items which such a plugin could implement include Installation from a remote user-specified URL. Currently it only allows uploaded files.

I personally see upgrades and Installations as vastly different things, A user might install plugins from multiple locations, WordPress.org, A remote URL(which WP doesnt support) or a plugin they've downloaded. Upgrades are different though, the user needs to be notified of an upgrade, and then the user would need to identify the plugin which the package is supposed to upgrade.

It'd be a simple patch though, If someones interested in making a UI for it (And a dev likes it) I'll write in the stuff for the backend-upgrade if need be (Only since i understand it pretty well, And realise some people might be better suited at UI programming)

#4 @Denis-de-Bernardy
8 years ago

just checking... can't the install screen already be used to upgrade?

#5 @DD32
8 years ago

No. Thus the error message which was provided above in the ticket.

#6 @Denis-de-Bernardy
8 years ago

  • Keywords needs-patch added; 2.8 removed

thoughts about setting clear_destination to true in this case?

#7 @DD32
8 years ago

thoughts about setting clear_destination to true in this case?

a -1 from me there.

IMO zips should be trusted less than whats already on the system, Auto-installed Plugins have the catch that all folder names are unique, and therefor, dont conflict, but if i download a plugin called "something Cool by Denis" should it overwrite "Something cool by DD32" which i installed from elsewhere?

Another option for this, Is to wp_unique_filename() (well..dirname) on the dest. folder, That'd have the benefit of no conflicts, However, It does have the downside that the plugin upgrader (still) doesnt respect the plugin folders name (ie. it creates a new folder based on the zip name, or the .org slug in the .zip rather than using the current folder (eg. core-control installed in my-plugin-cc/ will be renamed))) - So that basically rules that out at this stage..

Maybe for uploaded plugins a unique_name.. else if its from .org.. not.. But that doesnt feel right to me, since it varies depending on the use-case

#8 @Denis-de-Bernardy
8 years ago

how about this: we check if the folder exists. If so, we validate that the new plugin files return similar data as the old one (i.e. same plugin name, higher version being uploaded, not necessarily same author since it may have been maintained by someone new). If true, it's pretty safe to set the clear_destination to true.

#9 @DD32
8 years ago

  • Type changed from enhancement to feature request

how about this:

Hm. Sounds like a good idea, Basically the same thing api.wordpress.org does behind the scene..

But if thats the case, Might also need a checkbox "This is an upgrade for ...." or something. Eitherway, Its a potential candidate for a future release.

(Marking as feature request until a patch comes in)

#10 @Denis-de-Bernardy
8 years ago

I mostly see it as a means to easily update a theme or a plugin that is *not* in the repository. :-)

#11 @DD32
8 years ago

I mostly see it as a means to easily update a theme or a plugin that is *not* in the repository. :-)

Yeah, Thats what i meant, BUT my point was that what your idea is, Is exactly what the API does for wordpress hosted plugins.

#12 @hakre
8 years ago

Additionally it would be nice that it's possible to upgarde the whole WordPress installation by providing a zipfile. Is somehow related to the original suggestion. Just overwriting every file that already exists to get a clean start-over.

#14 @Denis-de-Bernardy
8 years ago

dup with patch: #11915

#15 @cyberhobo
8 years ago

  • Cc cyberhobo@… added
  • Keywords dev-feedback has-patch added; needs-patch removed

The dup was mine. I updated my patch after reading this discussion to incorporate some extra checks. But more important, I think, it's an illustration with a bare minimum UI that I find helpful for getting a feel for the possible pros and cons of this feature.

My one addition to the need for the feature is related to #11850. Briefly, a user with a ZIP who fails to upgrade a plugin via upload might be tempted to delete the existing plugin, which might have an uninstaller that deletes their data.

So, without getting into the implementation, I wonder if this illustration can help us decide for or against this feature? I myself am for it, but I'd just like the bare minimum to address my above concern.

#16 @scribu
7 years ago

@cyberhobo: As long as the UX is identical to the normal update process, I don't see the problem.

+1 for this feature.

#17 @scribu
7 years ago

By the way, I think it wouldn't be that hard to allow multiple plugin/theme upgrades through a single .zip file.

Here's how it could work (for plugins):

  1. Unzip archive.
  2. Scan all extracted files for plugin headers.
  3. Match any found plugins with the currently installed plugins.
  4. Show a confirmation screen to the user about which plugins would be upgraded.
  5. Do normal upgrade procedure for matched plugins.

#18 follow-up: @cyberhobo
7 years ago

I'll see if I can find some time to look at this again.

Re: Step 4, I recall thinking it would be harder to add an extra exchange like a confirmation (in addition to being a UX change). My compromise was to add an "upgrade existing plugin(s)" checkbox to the initial upload form instead (also a UX change).

The other question I recall having is that I needed data like get_plugins() returns, but get_plugins() won't run on the unzipped archive in the working directory. I'm not entirely clear why that is, or if it would be worth adapting that code to this purpose rather than repeating much of it.

#19 in reply to: ↑ 18 @scribu
7 years ago

Replying to cyberhobo:

The other question I recall having is that I needed data like get_plugins() returns, but get_plugins() won't run on the unzipped archive in the working directory. I'm not entirely clear why that is, or if it would be worth adapting that code to this purpose rather than repeating much of it.

Better to make get_plugins() more general than have duplicate code.

#20 @hakre
6 years ago

Related: #16923

6 years ago

Refresh, improvements

#21 @cyberhobo
6 years ago

Got some work done at WordCamp Reno today:

  • updated to current trunk - still works!
  • modified get_plugins() to take an alternate plugin root. I skip caching in that case because it doesn't seem likely to be done more than once.
  • doesn't do multiple upgrades from a zip, but that still seems within reach

#22 @SergeyBiryukov
3 years ago

  • Description modified (diff)

Related: #27196

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

3 years ago

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

3 years ago

#26 @countrymusicchicago
16 months ago

This would be a huge time saver.

#27 @Doobeedoo
15 months ago

7 years ago, it's still impossible to update a plugin with the .zip ?

#28 @pingram3541
15 months ago

+1 on this. Still very much a painful process to update plugins not in repo or don't have their own update mechanism, not every site has wp-cli and its just that much more work added to our lives to move from already being logged into the back end to using a third party client to update plugins. I'm actually surprised a plugin for this doesn't already exist =)

Last edited 15 months ago by pingram3541 (previous) (diff)

#29 @bfintal
11 months ago

Perhaps we can merge parts of this plugin into core: https://wordpress.org/plugins/easy-theme-and-plugin-upgrades/

#30 @ocean90
11 months ago

#38139 was marked as a duplicate.

#31 @kda406
7 months ago

I cannot believe this is not already in the core, and hasn't been added for all these years. This would be a huge time and bandwidth saver. No need to download the same plugins for every one of my sites over and over.

#32 @nimmolo
6 months ago

+1 for add to core. The plugin mentioned by @bfintal works great, but this seems like a necessary core feature. Sites hosted on servers without FTP access are too much of a chore to update.

#33 @lukecavanagh
6 months ago

Seems like a solid core feature for 4.8.

#34 @rinkuyadav999
6 months ago

+1 for add to core.

#35 @pcpro178
6 months ago

+1 for add to core.

#36 @zubaka
6 months ago

+1 to add this feature to core

#37 @swissspidy
4 months ago

#40561 was marked as a duplicate.

#38 @folletto
4 months ago

+1 to this.

I'd also add that the lack of this feature makes impossible to update an active theme without disabling it first and deleting it, and disabling a theme means creating a gap for the site, plus it might lose customizations settings (widgets dropped / moved to a different sidebar).

If a user doesn't have SSH/SFTP access and wants to update an active theme, the lack of this feature makes it impossible without disrupting the site.

#39 @ahortin
4 months ago

Good to see this getting some traction after 8 years. This would be a huge time-saver, not to mention how much more convenient it would make updating themes & plugins. It's ridiculous that it's not already in core.

#40 @theMikeD
2 months ago

+1 to this. Is anyone "owning" this feature?

#41 @nimmolo
2 months ago

@rockwell15 PLEASE can we schedule this for the next point version. (Plugin and theme updates from .zip upload)

#42 @swissspidy
2 months ago

  • Keywords needs-refresh added

@nimmolo Unfortunately it's not that easy.

This ticket definitely needs a refreshed patch and lots of testing (perhaps even a unit test).

If anyone wants to work on this, feel free. Right now, this doesn't have priority though as it's not one of the current focuses of the project.

#43 @kda406
2 months ago

@swissspidy You are missing the point. Many people need this and have been requesting it for 8 years now. Enhancements - no I'm going to call this a fix because it should have been in there from the beginning. Fixes with wide spread need which have been long awaited, should have developer precedence.

When a new version of WordPress comes out, I always read to see if they have fixed this problem yet. Then I am disappointed when I learn they have wasted precious coding time and resources for unimportant "improvements".

Security related patches are the only things that should have higher priority over widely needed, log awaited fixes like this one.

This ticket was mentioned in Slack in #core-customize by melchoyce. View the logs.

8 weeks ago

#46 @melchoyce
8 weeks ago

Proposed workflow:

  • Drag and drop an updated zip file for the theme you're updated directly onto themes.php. Get an Shiny Updates notice on the theme being updated. Boom, updated!
  • Also, add some sort of "update theme from zip" button to the theme details modal.

I'll sketch out a flow for this.

Last edited 8 weeks ago by melchoyce (previous) (diff)

#47 @pingram3541
8 weeks ago

So excited this is finally getting traction! I just wanted to add that there is also great value in the ability to also roll back a version via zip upload as well, not just update so maybe this can be considered as well?

Also, should there be any consideration for retention of what is overwritten? A download link?

Last edited 8 weeks ago by pingram3541 (previous) (diff)

This ticket was mentioned in Slack in #core-customize by westonruter. View the logs.

8 weeks ago

#49 @FolioVision
8 weeks ago


Reduces dependency on WordPress.org plugin directory and at this point that's a good thing. As plugin developers in an area of constant change (video), we are regularly asking customers to delete the existing plugin to install a custom beta version. Zip updates would definitely make customers lives easier.

As swisspidy notes, it's harder than it looks although the code to do updates right must exist on WP.org's server and could be made to work locally.

#50 @ronalfy
7 weeks ago

Definitely a +1 here.

We recently ran into this situation with a client site and the only workaround was renaming the folder and deleting the old theme.

#51 @StephenCronin
7 weeks ago

+1 for this.

It seems to be quite common that real users try to update using the zip upload (install) feature and therefore get the "destination folder already exists" message.

If you do a Google search, you'll see there are a bunch of articles about this, including FAQs from theme and plugin authors, which shows they get lots of users asking their support teams about this. Likewise there are a bunch of topics on the Support Forums.

At minimum we should warn users that this won't work before they attempt it. Ideally, we'd make it work, or come up with a solution such as the one Mel proposed.

All those articles tell users to update via FTP and although that will work, I'm sure core can offer a better user experience than that.

This ticket was mentioned in Slack in #design by melchoyce. View the logs.

7 weeks ago

#53 @melchoyce
7 weeks ago

Relevant Twitter conversation:



(I wish these embedded...)

I definitely think we should allow both uploading new themes, and updating existing themes, via drag-and-drop (#24579), but maybe we don't need to add new UI for updating — maybe having people go through the existing upload flow is fine.

#54 @rinkuyadav999
7 weeks ago

Too much +1 for this :)

This ticket was mentioned in Slack in #design by folletto. View the logs.

7 weeks ago

#56 @folletto
7 weeks ago

I agree, the drag'n'drop flow is going to be useful regardless of the specific flow as it's a speed/advanced feature, and we can start by allowing update with the same UI for the rest, and iterate later if we prefer to improve the design further.

#57 @ahortin
7 weeks ago

The ability to upload/update an existing theme & plugin, even using the existing workflow would be a million times better than not being able to do it, which is what we have now.

So excited that this is finally getting some traction! *Squeeeee!*

#58 @alex-ye
5 days ago

It would be nice feature to add into the core.
I had built those two simple plugins 1 year ago, hope it helps. :)

Note: See TracTickets for help on using tickets.