WordPress.org

Make WordPress Core

#25788 closed enhancement (fixed)

Increase timeout for `plugins/update-check` API request

Reported by: johnbillion Owned by: johnbillion
Milestone: 4.0 Priority: normal
Severity: normal Version:
Component: Upgrade/Install Keywords: has-patch commit
Focuses: Cc:

Description

On my various local test installs I have a single directory rammed full of plugins that is shared between installs. This directory often has over 100 plugins in it, and this often causes the plugin update check to time out (due to the number of plugins that are being checked I presume).

We should increase the timeout for the api.wordpress.org/plugins/update-check requests. We could increase it based on the number of plugins being checked. For example, count( $plugins ) / 10 might be a good timeout, meaning an increase of one second for every ten plugins on the site (with the current three seconds as a minimum).

Thoughts?

Attachments (1)

25788.diff (1.3 KB) - added by dd32 21 months ago.

Download all attachments as: .zip

Change History (15)

comment:2 @dd3221 months ago

  • Keywords needs-patch added
  • Milestone changed from Awaiting Review to 3.8

Basing the timeout on the number of plugins seems like a decent idea to me.

Not completing the request during a pageload is incredibly annoying (as you know there's an update, but it's timing out) and if an extra second can be added for a large number of plugins (for a page that is already slow from that number of plugins) then it seems worth it.

On the other hand, this does mean an extra second (or two) until the request times out in the event the server has poor connectivity.

Moving to 3.8 pending discussion

@dd3221 months ago

comment:3 @dd3221 months ago

  • Keywords has-patch 2nd-opinion added; needs-patch removed

Still on the fence, but can't do any harm. Any objections?

comment:4 @dd3220 months ago

  • Milestone changed from 3.8 to Future Release

comment:5 @SergeyBiryukov18 months ago

#27091 was marked as a duplicate.

comment:6 @johnbillion14 months ago

  • Keywords commit added; 2nd-opinion removed
  • Milestone changed from Future Release to 4.0

comment:7 @johnbillion14 months ago

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

In 28782:

Increase the timeout for plugin and theme update checks based on how many are being checked. Props dd32. Fixes #25788

comment:8 @kovshenin13 months ago

Re r28782: not a big deal, but it seems like (int) $v is ~ 200 times faster than intval( $v ), especially if you're not expecting strings and you're working in base 10.

comment:10 @SergeyBiryukov13 months ago

In 28823:

Use direct typecasting instead of intval() for better performance.

props kovshenin.
see #25788.

comment:11 @Denis-de-Bernardy12 months ago

Fwiw, this is still timing out for me. Due to a slow connection, I imagine, since I've only 10 plugins on my localhost install.

comment:12 follow-up: @SergeyBiryukov12 months ago

#20002 would probably resolve this completely.

comment:13 in reply to: ↑ 12 @Denis-de-Bernardy12 months ago

  • Resolution fixed deleted
  • Status changed from closed to reopened

Replying to SergeyBiryukov:

#20002 would probably resolve this completely.

Doubtful. The problem occurs at lines such as these:

Why we're triggering an E_USER_* error on this is beyond me, btw. This fires up the Symfony debugger, and leaves you staring at a screen full with the details of the exception.

Methinks the correct fix would be to get rid of that, and trigger the error only when the cron is running for the sake of logging it. On the front end, it should instead display an appropriately colored (warning) message in the admin UI and trigger no PHP error at all.

Moreover, and as stated in a separate ticket, I can't hep but point out why anyone privileged with an SSL-enabled HTTP transport gets to see this kind of warning but not those who don't.

Lastly, I'd like to highlight that the timeout is either ignored or not honored, or the wordpress.org API times out earlier than whatever is specified. Because, well, I increased it to a ridiculously high value (30 seconds) for 10 plugins, and it's still timing out -- long before thirty seconds elapse.

comment:14 @johnbillion12 months ago

  • Resolution set to fixed
  • Status changed from reopened to closed

Denis, these are valid points (and I agree on the unwanted E_USER_* errors) but let's open a new ticket for them as the particular issue in this ticket was fixed.

Note: See TracTickets for help on using tickets.