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

[hakre]

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:

    *


      Dashboard
    *

    *


      Posts
      Posts
          o Edit
          o Add New
          o Post Tags
          o Categories
    *


      Media
      Media
          o Library
          o Add New
    *


      Links
      Links
          o Edit
          o Add New
          o Link Categories
    *


      Pages
      Pages
          o Edit
          o Add New
    *


      Comments 0
    *

    *


      Appearance
      Appearance
          o Themes
          o Widgets
          o Editor
          o Add New Themes
          o Custom Header
    *


      Plugins 0
      Plugins 0
          o Installed
          o Add New
          o Editor
    *


      Users
      Users
          o Authors & Users
          o Add New
          o Your Profile
    *


      Tools
      Tools
          o Tools
          o Import
          o Export
          o Upgrade
    *


      Settings
      Settings
          o General
          o Writing
          o Reading
          o Discussion
          o Media
          o Privacy
          o Permalinks
          o Miscellaneous
    *

Help
Documentation
Support Forums
Help

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.

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.

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.

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)

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

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

thoughts about setting clear_destination to true in this case?

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

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.

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)

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

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.

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.

Related: #10596, #11281

dup with patch: #11915

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.

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

+1 for this feature.

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.

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.

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.

Related: #16923

Refresh, improvements

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