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

[johnbillion]

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?

[SergeyBiryukov]

Related: #20002

[dd32]

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

[dd32]

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

[SergeyBiryukov]

#27091 was marked as a duplicate.

[johnbillion]

In 28782:

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

[kovshenin]

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.

[SergeyBiryukov]

Some (int) vs. intval() performance tests: ​http://hakre.wordpress.com/2010/05/13/php-casting-vs-intval/.

[SergeyBiryukov]

In 28823:

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

props kovshenin.
see #25788.

[Denis-de-Bernardy]

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.

[SergeyBiryukov]

#20002 would probably resolve this completely.

[Denis-de-Bernardy]

Replying to SergeyBiryukov:

#20002 would probably resolve this completely.

Doubtful. The problem occurs at lines such as these:

• https://core.trac.wordpress.org/browser/trunk/src/wp-includes/update.php?rev=28823#L117
• https://core.trac.wordpress.org/browser/trunk/src/wp-includes/update.php?rev=28823#L292
• https://core.trac.wordpress.org/browser/trunk/src/wp-includes/update.php?rev=28823#L447

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.

[johnbillion]

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.