Make WordPress Core

Opened 11 years ago

Last modified 4 months ago

#9757 accepted feature request

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

Reported by: hakre Owned by: psykro
Milestone: Future Release Priority: high
Severity: normal Version: 2.8
Component: Upgrade/Install Keywords: dev-feedback has-patch early
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 (3)

upload_upgrade.diff (5.4 KB) - added by cyberhobo 9 years ago.
Refresh, improvements
9757.1.patch (23.5 KB) - added by imath 2 years ago.
9757.2.patch (403.1 KB) - added by imath 2 years ago.

Download all attachments as: .zip

Change History (96)

#1 @DD32
11 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
11 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
11 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
11 years ago

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

#5 @DD32
11 years ago

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

#6 @Denis-de-Bernardy
11 years ago

  • Keywords needs-patch added; 2.8 removed

thoughts about setting clear_destination to true in this case?

#7 @DD32
11 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
11 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
11 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
11 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
11 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
11 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
10 years ago

dup with patch: #11915

#15 @cyberhobo
10 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
10 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
10 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
10 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
10 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
9 years ago

Related: #16923

9 years ago

Refresh, improvements

#21 @cyberhobo
9 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
6 years ago

  • Description modified (diff)

Related: #27196

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

5 years ago

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

5 years ago

#26 @countrymusicchicago
4 years ago

This would be a huge time saver.

#27 @Doobeedoo
4 years ago

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

#28 @pingram3541
4 years 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 4 years ago by pingram3541 (previous) (diff)

#29 follow-up: @bfintal
4 years ago

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

#30 @ocean90
4 years ago

#38139 was marked as a duplicate.

#31 @kda406
3 years 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
3 years 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
3 years ago

Seems like a solid core feature for 4.8.

#34 @rinkuyadav999
3 years ago

+1 for add to core.

#35 @pcpro178
3 years ago

+1 for add to core.

#36 @zubaka
3 years ago

+1 to add this feature to core

#37 @swissspidy
3 years ago

#40561 was marked as a duplicate.

#38 @folletto
3 years 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
3 years 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
3 years ago

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

#41 @nimmolo
3 years ago

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

#42 @swissspidy
3 years 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
3 years 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.

3 years ago

#46 @melchoyce
3 years 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 3 years ago by melchoyce (previous) (diff)

#47 @pingram3541
3 years 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 3 years ago by pingram3541 (previous) (diff)

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

3 years ago

#49 @FolioVision
3 years 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
3 years 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
3 years 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.

3 years ago

#53 @melchoyce
3 years 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
3 years ago

Too much +1 for this :)

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

3 years ago

#56 @folletto
3 years 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
3 years 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
3 years ago

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

#59 @pento
3 years ago

  • Milestone changed from Future Release to 4.9

Soooo... this ticket hasn't made much progress this cycle. :-)

Unfortunately, the people who would usually work on these things (@dd32 and I, for example) are unavailable until late September, and that's way too late to be starting work on this feature. There are a lot of hidden complexities and edge cases to consider, it requires a deep dive into the update code, and I'd really like to see masses of unit tests (and maybe even some integration tests).

If someone can pick this up and run with it for the next 4 weeks, I can absolutely provide reviews and feedback until I'm available to join you more regularly. We have just under 6 weeks until the feature merge deadline, that should be sufficient to build this, and give it time to soak. If doesn't have any movement until late September, it almost certainly won't make it into 4.9.

If you're thinking about jumping in, but aren't sure where to start, here are some steps to think about.

  • Go through the install/upgrade related screens many times, so you know exactly how it currently works.
  • Take screen shots, post them to make/test, link the post here.
  • Write about exactly how you think the UX flow should work. We have plenty of UX experts subscribed to this ticket who can give you feedback.
  • Iterate on the flow. Think about the edge cases - what will make it weird? What will make it bad? What will make it break?
  • Write a prototype. A plugin would be easier to test, but harder to merge - don't worry about that now.
  • Post more screenshots and video to make/test.
  • Iterate.

If any of these aren't your strong point, don't sweat it - there are a bunch of people here who will help you. If you can only dedicate time to part of it, that's cool! There are a bunch of people here who can join you to keep things moving.

If the ticket gets this far, it's on track to get it merged in 4.9! Good work, friends! You're awesome people. :-D

#60 @dd32
3 years ago

As @pento said above, I'll review any attempts made here - but with the caveat that I can't do so until the last week of September at the earliest.
If this were a super-simple thing to add, I'd have added it a long time ago, unfortunately there are a lot of edge-cases that are not immediately obvious - IIRC it's not merely 'connector' code required, but something a lot deeper.

The update code also differs significantly from the install code - Install handles various archive structures and is far more forgiving than the update handler.
For example, currently updates require the ZIP file structure match *exactly* what W.org produces - however most non-W.org ZIP files do not match in every respect, and causes problems for 3rd-party updates occasionally (until they get the structure "right"). The installer code handles the various archive structures a lot better, but still gets complaints sometimes (for example, ending up with a directory of wp-content/plugins/plugin-name. under certain circumstances)

IMHO: Any change here will need to touch on the main update handlers to avoid code duplication, and the changes there will need deep testing, as there's no current unit testing, integration testing, or any other kind of testing in place there for any install/update actions.

(Some of the comments from 4+ years here will be completely irrelevant to any effort too, take them with a grain of salt, but verify any limitations mentioned)

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

3 years ago

#62 @JoshuaWold
3 years ago

In order to catch myself up on the problem that's happening here, I've created a user flow with screenshots: https://make.wordpress.org/test/2017/08/27/updating-plugins-with-zip-uploads/.

It took a while to understand the issue, so hopefully these screenshots will help others.

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

3 years ago

#64 @dnavarrojr
3 years ago

Ugh, getting punted again...

#65 @psykro
3 years ago

@pento @dd32 I'm keen to see if I can either own this, or do as much as possible in the next four weeks to push it forward. At this point I have some questions

  1. Does it make sense to start with only making this work if the user uploads an updated plugin zip from the Plugin update screen? There has been some discussion around implementing drag/drop functionality but that seems to me to be a good feature for a future release.
  2. The current process only checks for a matching folder structure, is this enough of a check? My thought is that it could do the following to determine whether to upgrade or install
    • check for a matching folder
    • if not ground check for an installed plugin with the same Plugin Name
  3. Does the upgrade process need to be more complicated than
    • delete old plugin files
    • extract new plugins files

#66 @Clorith
3 years ago

It should be more complicated than that, yes.

One thing is if you hit an "invalid" structure, as mentioned in a previous comment.

My concern that needs ot be addressed is when you take into consideration things such as like folder name (slug) matching. Someone made my-plugin as the slug for My first plugin, but there's already a my-plugin used by the Mittens by York Plugincompany who prefixed their plugin with my followed by plugin as the slug.

What happens if I accidentally grab an older version and upload it, should it automatically replace everything, should I be notified that I'm about to perform a downgrade (I think I should be).

#67 @psykro
3 years ago

@Clorith thanks for the feedback, noted regarding uploading older versions.

My question around the actual upgrade process was more along the lines of 'WordPress has already determined (by means to still be discussed) that this plugin can be upgraded'.

So once the something like 'can_plugin_be_updated()' returns true, does the physical action of upgrading the plugin need to be more complicated than something like

  • rename current plugin directory
  • upload and unzip new plugin
  • delete renamed plugin directory

I'm still going to follow @pento's suggestions of diving deep into the code and taking screenshots, but I'm just clarifying some initial questions/suggestions that pop into my head.

In my mind the checks for upgrading a plugin should be a combination of the plugin slug and Plugin header meta info for example

  • Plugin name
  • Version
  • Text Domain

However I realise that the only field that a plugin actually requires is the Plugin Name

My initial feeling is that if the plugin directory name and Plugin Name meta match, consider the plugin to be upgraded. If the plugin has a valid Version field, check against that, if not warn the user of a possible 'downgrade'.

#68 in reply to: ↑ 29 ; follow-up: @joyously
3 years ago

Replying to bfintal:

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

As stated a year ago, this plugin has existed a long time and works just great. Why not use what's already been tested?

#69 @psykro
3 years ago

@joyously thanks, I will install that as well and consider it based on the other concerns.

Out of interest sake, what does it take for someone to 'own' a ticket, does it require a chunk of work/discussion to be completed first, or is it just a case of someone making me the owner?

#70 follow-up: @Clorith
3 years ago

A ticket owner is really just someone who drives the ticket, you don't need to own it to work on it.

#71 in reply to: ↑ 70 @psykro
3 years ago

Replying to Clorith:

A ticket owner is really just someone who drives the ticket, you don't need to own it to work on it.

Gotcha, thanks @Clorith.

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

3 years ago

#73 @psykro
3 years ago

Right, first attempt at suggesting a possible way forward. To my mind, the simplest way would be to check the zip being installed against any existing possible matches, before the actual file is uploaded.


So on adding a new plugin and clicking the Install Now button

  1. Make a WP Rest API call to check if a plugin with either a full or partial slug match exists
  2. Display the 'This plugin you are attempting to install seems to exist' message to the user
  3. Display the matching plugin details (name, description and version number)
  4. Move the Install Now button under the 'confirmation' message and change it to 'Accept and install'
  5. On clicking the install button the usual upload and install process proceeds

Things to consider

  1. During the upgrade process, the plugin being overridden should probably be renamed/moved to a temporary location, in case the plugin install fails and a rollback is required (sometime like rename to _plugin_name
  2. Once the new plugin has successfully been installed, clean up the temporary location at step 1 above.

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

3 years ago

#75 in reply to: ↑ 68 @psykro
3 years ago

Replying to joyously:

Replying to bfintal:

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

As stated a year ago, this plugin has existed a long time and works just great. Why not use what's already been tested?

The plugin does handle the uploading of a plugin with the same (or similar) plugin slug, by moving and renaming the existing plugin and installing the new plugin.

So I suppose the question is, by adding the pre upload/install notification as outlined above, is that enough of a check against uploading a previous version of the same plugin or uploading a different plugin with the same or similar slug?

#76 @psykro
3 years ago

Further reading on the the current plugin suggests that it could simply be merged into core as is.

Attention: Version 2.0.0 changed the functionality of the plugin. You are no longer required to select “Yes” from a drop down before the theme or plugin can be upgraded. The need for an upgrade is now detected automatically. So, if you are used to the old functionality of the plugin, do not be concerned about the absence of upgrade details on the theme and plugin upload pages. Simply upload the theme or plugin as if you were installing it, and the plugin will automatically handle upgrading as needed.

However, setting up a real world test, with the same plugin slug but very different contents and the new plugin is uploaded over the old one. So the first plugin step check and verification by the user appears to be required.

Last edited 3 years ago by psykro (previous) (diff)

#77 @Clorith
3 years ago

Plugin slug check is definitely required, also remember that the name of a zip file may not be the plugin slug, the zips generally contain a folder with the plugin slug, so an API check before uploading won't be enough here.

#78 @psykro
3 years ago

Thanks @Clorith

If we uploaded the file asynchronously, using the same javascript library as the media library (which uses plupload as far as I know) this would give us the ability to perform the API check on the plugin slug.

So to update my proposal above, on clicking 'Install Now'

  1. Upload plugin zip asynchronously to a temporary location in the uploads directory, showing am 'upload' progress meter
  2. Once uploaded, unzip the plugin to use the plugin slug (folder name) to make a WP Rest API call to check if a plugin with either a full or partial slug match exists
  3. Display the 'This plugin you are attempting to install seems to exist' message to the user
  4. Display the matching plugin details (name, description and version number)
  5. Move the Install Now button under the 'confirmation' message and change it to 'Accept and install'
  6. On clicking the Accept and install button the plugin is installed

Things to consider remains the same.

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

3 years ago

#80 @westonruter
3 years ago

  • Priority changed from low to high

Bumping priority to high for visibility and alignment with 4.9 goals, and given proximity to beta 1 deadline.

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

3 years ago

#82 @johnbillion
3 years ago

  • Keywords early added
  • Milestone changed from 4.9 to Future Release

This is making good progress, but it needs to go into a release cycle earlier on for testing purposes. Punting to 5.0.

2 years ago

#83 @imath
2 years ago

  • Keywords needs-refresh removed


As i'm currently working on this feature for one of my plugin, i'm suggesting this alternative approach. I agree it would be interesting to upload / unzip / explore the uploaded plugin into another temporary folder then ask the user if he wants to update a matching existing plugin with the uploaded one, delete the old plugin, move the temporary folder etc... It would probably allow to check if the version is upper etc..

On the other hand, I think it's a lot of file manipulation and probably edits into the Plugin Upgrader class. The alternative approach is to consider a replace process instead of an update process. There can be cases when you updated a plugin, something's going wrong with your site's configuration and you need to come back to a previous version of the updated plugin to fix the issue with your site.

In 9757.1.patch, i'm using JavaScript to get the Zip filename and use this as the plugin's slug to check for existing plugin thanks to a Rest API request. If there is no match, it doesn't change anything to the process, if there's one, then it adds some information before the "Install Now" button and a "Cancel" button after it to reset the form, see screenshot beneath.


When the user clicks on "Install Now" the process is very similar to an update, and there is very few edits to Plugin_Upgrader::upgrade(). As the process is a bit different, strings need to be a bit different in this case though, because we don't know if the user is upgrading or downgrading the plugin. That's why the patch is taking this in account as you can see beneath :


"Replacing the installed version" & "Plugin replaced successfully" are the new strings.

NB: the patch is using the wp.apiRequest (introduced in 4.9, btw thanks a lot and congrats to people who worked on it 👍) And the script where is located this API is not loaded on multisite configs. There's probably a good reason for this but at the same time as some widgets are using it, i guess they could fail on multisite configs..)

If you think it's an interesting approach, I can give a hand during 5.0 dev cycle to carry on improving the patch and adding Themes support. Else, i'll be happy to give my feedbacks on @psykro 's approach.

#84 @ahortin
2 years ago

@imath Using the zip filename as the slug is not a great idea. A lot of 'premium' plugins typically have the version number as part of the zip filename. As an example, two very popular plugins Elementor Pro and Gravity Forms, have the following filenames for their most recent versions, elementor-pro-1.9.3.zip and gravityforms_2.2.5.8.zip, respectively.

Using these filenames as the slug would mean that when you checked for an existing version, it would be looking for the wrong slug as the actual folder names within each of those zip files I mentioned, are elementor-pro and gravityforms.

#85 @imath
2 years ago


Thanks for your feedback, yes i know WordPress & GitHub are also doing so. I trust site admins and i think they are smart people :)

  • They can rename a package,
  • Plugin Authors can add a line in their description/documentation "If you want to update manually rename the package to elementor-pro.zip"
  • The help tab of the administration screen can also include a section to explain how to rename a zip file containing the plugin version.

We could also sanitize the filename from the JavaScript file. But if you think it's not a great experience and it's best to do all the file manipulations on the server, i'm fine with it and i totally understand.

#86 @Clorith
2 years ago

We can't expect users to rename their files to do an update, that's a bad experience for the average user just looking to update their theme or plugin like they were told to do.

Your concern for reverting a plugin if an update is bad is legitimate though, we could possibly replicate the new code editor behavior of making a call to the site and checking if it fails, at least you won't end up with a white screened site then?

2 years ago

#87 @imath
2 years ago


Ok then we could use the FileReader API with the external JSZip library as i'm suggesting in 9757.2.patch. This way the real file structure contained into the zip package could be checked, no matter the name of the zip file. In the following test I've renammed preferred-languages.zip to RandomName.zip :


#88 @ahortin
2 years ago

I don't think renaming the zip file is a very good user experience. If someone selects preferred-languages.zip to upload, and then you go and rename this to RandomName.zip, it's going to cause confusion. The user isn't going to be expecting their filename to get changed and if they see a different filename being displayed and uploaded, from the one they selected, it's going to cause them concern.

#89 @imath
2 years ago


It was an example to show that the real zip content was taking in account so of course it works with preferred-languages-1.2.4.zip etc... The patch doesn’t rename the file at all. Feel free to test it btw :)

Sorry i caused a confusion here.

#90 @bloggingthemes
2 years ago

I certainly hope this ticket will keep progressing. One of the biggest user experience one could hope for is to give them the method of updating an existing theme and/or plugin simply by re-uploading using the installer. Most users are scared of FTP (I don't blame them), but using a third party plugin is not ideal because who knows how long it will be kept up-to-date and supported.

This is definitely important to exist within the core and should have been there since the beginning. I get so many users say to me:

  • How come I can't update my theme using the installer?
  • How come I can update with 1-click themes and plugins I get from wordpress but not yours?
  • Or they use the installer and get that "already exists" message and get frustrated.

Overall, I hope this gains ground for an upcoming WordPress release because people need this.

I've been using Joomla for 10 years and they've always had this capability. It also doesn't matter what the zip file name is either because it looks at the file's xml info. In the case of WordPress, I would assume this would be a similar equivelent of the text-domain and version number of the theme or plugin. Ultimately, it shouldn't matter if the theme or plugin was installed from .org or elsewhere, the fact is that for a much better user experience, we need this.

Hopefully this makes it in an upcoming release.

#91 @pento
14 months ago

#46223 was marked as a duplicate.

#92 @psykro
8 months ago

  • Owner set to psykro
  • Status changed from new to accepted

#93 @galbaras
4 months ago

From what I can see, there are at least 110,000 active installs of plugins overriding the install function in the quick and dirty manner. The above proposal will give them a better solution.

Also, why not leave the install alone and ADD a function to upload a file for the purpose of updating the plugin/theme? Then, WordPress can assume this is an update and act accordingly, and there's no confusion anywhere.

There can be a new page for selecting a plugin to update and a file to upload, but the easiest way would be to add an "update from file" link on the Installed Plugins page, making it clear in advance what's being updated.

Note: See TracTickets for help on using tickets.