In version 4.2.1, I can only update one plugin at a time by clicking on "Update Plugin" link

[ancawonka]

This may be related to #32135

When I go to the plugins page, (wp-admin/plugins.php) I can update plugins by clicking on the "Update Plugin" link, which does it in-page using Ajax. So easy!

But, when I try to update a SECOND plugin, it always fails. If I refresh the plugins page, I can then update the second plugin.

If I try to update multiple plugins at the same time, the "loading" animation just keeps going, but nothing happens.

I've tried this on multiple sites with different active plugins, and on different hosts.

[ancawonka]

Short video showing the problem

[ancawonka]

I did some further testing. Looks like this is happening on MULTI-site installs only - I was able to upgrade multiple plugins on single-site installs. HMM.

[romaiden]

Since WP 4.2.1 pt-BR I get a warning message in place of the new link functionality to update plugins on plugins page: "Warning: printf(): Argument number must be greater than zero in /hsphere/local/home/a896230/immiflex.com/br/wp-admin/includes/update.php on line 289", probably who translated, have deleted the arguments to show the link when the counter notices that 1 update is available. I just updated to 4.2.2, but still facing the issue. My other WP installations using EN are not affected by this.

[lianzinho]

Replying to romaiden:

Since WP 4.2.1 pt-BR I get a warning message in place of the new link functionality to update plugins on plugins page: "Warning: printf(): Argument number must be greater than zero in /hsphere/local/home/a896230/immiflex.com/br/wp-admin/includes/update.php on line 289", probably who translated, have deleted the arguments to show the link when the counter notices that 1 update is available. I just updated to 4.2.2, but still facing the issue. My other WP installations using EN are not affected by this.

Yes, me too. The same issue, pt-BR is missing arguments. I went to the file and edited the function, to show just the arguments:

printf( '%1$s %2$s %3$s %4$s %5$s', $plugin_name, esc_url( $details_url ), esc_attr( $plugin_name ), $r->new_version, wp_nonce_url( self_admin_url( 'update.php?action=upgrade-plugin&plugin=' ) . $file, 'upgrade-plugin_' . $file ) );

And it works flawlessly.

I then went to the admin-pt_BR.po file to see if the translation was missing, and it was there! So I have no idea why it's not outputting the result of the translate function.

If I change the translate function to _e() instead of __() it works but the placeholders like %1$sdo not get rendered.

Any ideas then?

[dd32]

I have a feeling this ticket is a duplicate of #32110 or another similar one that I can't find right now.

@lianzinho - The pt-br translation team can be contacted through ​https://make.wordpress.org/polyglots/teams/?locale=pt_BR and incorrect translations can be suggested through ​https://translate.wordpress.org (I've just ​fixed this bad translation).

[dd32]

#32650 was marked as a duplicate.

[dd32]

Replying to ancawonka:

I did some further testing. Looks like this is happening on MULTI-site installs only - I was able to upgrade multiple plugins on single-site installs. HMM.

Upon testing with a Multisite install, I can't duplicate this.

I suspect it's coming from a 3rd-party update script clearing the update transients too aggressively (or clearing it, and not refreshing it).
If anyone can duplicate this, are you running a plugin which gets it's updates from a non-wordpress.org source?

[ancawonka]

Both the sites where I've seen this happen have Gravity Forms installed, though that's not the plugin that gets the update.

This issue persists in 4.2.2. I've been using the update-core.php page to run updates for a while, so that's an okay workaround.

[dd32]

Replying to ancawonka:

Both the sites where I've seen this happen have Gravity Forms installed, though that's not the plugin that gets the update.

It doesn't have to be the plugin receiving the update, just an active plugin on the site that uses it's own update routines. I'll follow up with Gravity Forms and see if that's causing it.

[ancawonka]

Ah-hah! I've replicated the error on a local, single-site install (with Gravity forms 1.9.10 installed), and a number of plugins that need to be updated. Now I can track it down in a little more detail. Ack.

Replying to dd32:

Replying to ancawonka:

Both the sites where I've seen this happen have Gravity Forms installed, though that's not the plugin that gets the update.

It doesn't have to be the plugin receiving the update, just an active plugin on the site that uses it's own update routines. I'll follow up with Gravity Forms and see if that's causing it.

[dd32]

I've been unable to duplicate with the latest Gravity Forms (1.9.11.1 is latest - I've also tried 1.9.10.15), and the reasons I expected don't appear to hold up.

The main thing I can think of, is that the call to wp_update_plugins() is taking longer than (3 + 1 second per 10 plugins), which could be the cause of this.

32198.diff​ works around this in two ways

1. Adds an extra check to the update transient, if there's no updates (yet we're performing an update request) double-check there's no updates
2. Treats the ajax requests the same as the cron requests for timeouts, both set it to 30s

The fact that refreshing the page allows the update to occur suggests that it's not this at all.. but it's all I could see so far.

[obenland]

@dd32, is this close to completion?

[dd32]

Have been able to duplicate this finally.

The issue is that checking empty($current) isn't enough, as some custom updaters inject their update into an empty/non-existent transient, which results in a malformed transient.

Currently patching.

[dd32]

In 33257:

Updates: When performing an ajax plugin update, rely upon wp_update_plugins() to check the contents of the transient and return early if no request needs to be made.
This works around a bug where custom update handlers are injecting an update into an empty transient, malforming the transient and causing update failures.
Fixes #32198 for trunk

[dd32]

In 33258:

Updates: When performing an ajax plugin update, rely upon wp_update_plugins() to check the contents of the transient and return early if no request needs to be made.
This works around a bug where custom update handlers are injecting an update into an empty transient, malforming the transient and causing update failures.
Merges [33257] to the 4.2 branch.
Fixes #32198 for 4.2