Bulk Upgrade Plugins

[ydekproductions]

I think it'd be LOVELY to have an option to either Update All plugins, or at least one of the Bulk Actions be to upgrade all selected plugins.

This caught my attention when I logged into my admin today to see that 10+ plugins have been updated for 2.7 and I let out a sigh because it's going to take a good 15 or more minutes to update all of these!

Maybe I'll get together a patch for this when I clear a bit of REAL work off my plate.

[csseur3]

do you use the oneclick plugin?

if yes, i think is a enhancement for the plugin, not wordpress.

but, because this plugins is very popular, it is interesting to integrate it by default, no? :p

bye.

[DD32]

if yes, i think is a enhancement for the plugin, not wordpress.

Plugin upgrades have been part of WordPress since 2.5

Plugin Installing, Theme Upgrades and WordPress Core upgrades have been introduced as of WordPress 2.7

As for this ticket, There are a number of reasons why this might not currently be viable, Downloading the zip takes a long time, on some hosts, that will take up the majority of the PHP Time limit (on some, you cant change it). The Zip extraction process uses a lot of memory, And AFAIK, its not all free'd afterwards, so extracting multiple zip's might use up more memory than is available, But those would need looking into, it could well be very feasible.

[ydekproductions]

What if we set up a queue in the session for what updates need upgraded. When one is complete, it refreshes the update page, the next item in the queue is handled. Error or not, it just automatically goes through the requests and makes it happen.

That way we're not downloading potentially 20 zips and extracting them all at the same time. Just some sort of wrapper around the existing architecture. On the normal update page, slap in a simple Javascript refresh to keep the process going.

Comments?

[DD32]

An auto-freshing frame could be used I guess, Error handling of upgrades which fail could be an issue, but one that could easily be worked around, I'll keep it in mind and see if anything ever pops into my mind :) (Not saying i'm going to implement this ticket, If someone else feels like it, go right ahead and do it your way :))

[ydekproductions]

What about completely restructuring the update process to use Ajax.

The actual update page will be the status like it is now, but it'll be making a request to an Ajax script instead with a little spinner for the status.

Then it'd be real simple to execute multiple updates. The update process could then also be more streamlined and broken up into arbitrary tasks, like: Download zip file is one request, then unzipping would be another request. Just more tasks would be thrown into the queue and potentially work in multiple streams.

I think doing this would help bypass some interference on servers with max script execution time as well as memory usage.

[DD32]

Reasons not to use ajax:

• AJAX is not the solution to everything, Nor does it make things 'cleaner'
• Requires JavaScript
• Breaking it into multiple chunks makes the code much more complex, and requires passing the FTP username back and forth from the blog multiple times (in your scenario, about 6-8 times over a likely non-encrypted link)
• Working in a non-JS version to handle every other case where JS is not available, or they choose not to use it, means its yet another function to link them all together.
• Keeping track of temporary files between pages

I've not seen any reasons that would cause the need for a JS version, So i'd personally recommend against it myself.. But a lot of the rest of WordPress is starting to use it.. but wherever its used, there is usually a fall-back.

[ydekproductions]

A requirement is not Javascript? Wow. I was fooled by all the jQuery present! Drag and drop reordering interface, drop down menus, drop down help panel, TinyMCE, blah blah blah.

You have some real good points about the security and the mess of things. I'll brainstorm some ideas for this. What would be wrong with storing their information in a PHP session variable? Doesn't seem too insecure.

For the non-JS version, we can just have the bulk upgrade option added via Javascript. So if they're using it, awesome, if not, they'll never know.

I think it's a pain when we hinder serious enhancements for a majority of people because the minority refuse to use Javascript.

[DD32]

A requirement is not Javascript?

Not at all.. As long as things can happen via non-JS method, then all is ok, Which i guess the single-update-plugin case covers.. While a lot of JS is used, nothing -requires- javascript to be done in WP, you can disable JS and still have access to everything (except Inline editing and bulk editing, which is fair enough, you can do single editing).

So, Nothing wrong with using Javascript at all, Just as long as it doesnt end up removing functionality from elsewhere. With the current upgrade code, It'd require duplicating 2 functions simply for ajaxified stuff, auto-reloading frames however would work fine.

WordPress doesnt use PHP Sessions, And i wouldnt see a need to simply for the plugin upgrade methods..

[Denis-de-Bernardy]

Personally, I like the idea.

@DD32: If it makes you feel more comfortable about it, I've a plugin that uses the WP core upgrader to upgrade Semiologic Pro instead, i.e. a 5M zip, which is 10MB+ when deflated. It upgrades WP, my theme, and 80 or so plugins, all in one go. I had to extend the default timeout a little, but it otherwise works fine.

I would make a recommendation if anyone tackles this, though: recursing through a long list of plugins means multiple http connections. This is the tricky/lengthy part, so it'll work better if the plugins are done one by one, in the background, through different processes.

[DD32]

Nah, I'm +1 for this, Just as long as the link/option to do a bulk upgrade is only visible when JS is available (So you can do everything via JS :)) Much like the Bulk edit functionality is

[Denis-de-Bernardy]

see #10197

WP 2.8 introduced separate views for plugins, including Upgrade Available.

On this screen, it makes sense to be able to select multiple plugins and upgrade them all at once.

Currently, ​Plugin Central does this using iframes.

[scribu]

Replying to ydekproductions:

What if we set up a queue in the session for what updates need upgraded. When one is complete, it refreshes the update page, the next item in the queue is handled. Error or not, it just automatically goes through the requests and makes it happen.

Here's how I think it could be implemented without requiring javascript and without reaching any resource limit:

1. User chooses multiple plugins for upgrade.
2. Store the plugins to be upgraded in an option (maybe use set_transient()).
3. For each plugin, do the normal upgrade.
4. If all went well, do a JS redirect to the next plugin, or show a "Continue..." button.

4*. If there was an error, show a "Continue upgrading other plugins?" button.

[scribu]

Oups... bad formatting. Here's the readable list:

1. User chooses multiple plugins for upgrade.

2. Store the plugins to be upgraded in an option (maybe use set_transient()).

3. For each plugin, do the normal upgrade.

4. If all went well, do a JS redirect to the next plugin, or show a "Continue..." button.

4*. If there was an error, show a "Continue upgrading other plugins?" button.

[dd32]

Here's how I think it could be implemented without requiring javascript and without reaching any resource limit:

Sounds good to me.

The other option is for UI like:

 Upgrading Plugin 1  / 4
----------------------
..Usual Plugin upgrade stuff....
----------------------
 Continue with next plugin (Hidden usually, just for non-js compat)

with the ---- section being in an iframe... its an option... But i like your idea more i think.

[hakre]

I just stumbeled over this and what I would love to see is a batch doing one after the other but creating a single log (not steps) sothat it can be triggered and then no other manual interception is necessary.

[scribu]

Related: #10973

[dd32]

Closing as duplicate of 10973