WordPress.org

Make WordPress Core

Opened 3 years ago

Closed 2 years ago

Last modified 2 years ago

#32198 closed defect (bug) (fixed)

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

Reported by: ancawonka Owned by: dd32
Milestone: 4.2.3 Priority: normal
Severity: normal Version: 4.2.1
Component: Upgrade/Install Keywords: has-patch
Focuses: javascript Cc:

Description

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.

Attachments (2)

update_failed.swf (1.5 MB) - added by ancawonka 3 years ago.
Short video showing the problem
32198.diff (2.7 KB) - added by dd32 2 years ago.

Download all attachments as: .zip

Change History (19)

@ancawonka
3 years ago

Short video showing the problem

#1 follow-up: @ancawonka
3 years ago

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.

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


3 years ago

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


3 years ago

#4 follow-up: @romaiden
3 years ago

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.

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

#5 in reply to: ↑ 4 @lianzinho
2 years ago

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?


EDIT: Solved!

The problem was in the translation first placeholder. It was written %$1s instead of %1$s so it was breaking the printf. Just edit the admin-pt_BR.pofile and it's good to go. Are there some other place where I could tell the translators about this mistake?

Last edited 2 years ago by lianzinho (previous) (diff)

#6 @dd32
2 years ago

  • Component changed from Plugins to Upgrade/Install
  • Milestone changed from Awaiting Review to 4.3

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).

#7 @dd32
2 years ago

#32650 was marked as a duplicate.

#8 in reply to: ↑ 1 @dd32
2 years ago

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?

#9 follow-up: @ancawonka
2 years ago

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.

Last edited 2 years ago by ancawonka (previous) (diff)

#10 in reply to: ↑ 9 ; follow-up: @dd32
2 years ago

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.

#11 in reply to: ↑ 10 @ancawonka
2 years ago

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.

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


2 years ago

@dd32
2 years ago

#13 @dd32
2 years ago

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.

Last edited 2 years ago by dd32 (previous) (diff)

#14 @obenland
2 years ago

  • Keywords has-patch added

@dd32, is this close to completion?

#15 @dd32
2 years ago

  • Milestone changed from 4.3 to 4.2.3

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.

#16 @dd32
2 years ago

  • Owner set to dd32
  • Resolution set to fixed
  • Status changed from new to closed

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

#17 @dd32
2 years ago

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

Note: See TracTickets for help on using tickets.