WordPress.org

Make WordPress Core

Opened 5 years ago

Last modified 5 months ago

#31184 new defect (bug)

Plugin update API times out too easily in practice, and is not handled gracefully

Reported by: rkaiser0324 Owned by:
Milestone: Priority: normal
Severity: normal Version: 4.1
Component: Plugins Keywords:
Focuses: Cc:
PR Number:

Description

In wp_update_plugins() the timeout is set to "Three seconds, plus one extra second for every 10 plugins" when not doing a cron job. I did some testing (with reasonable bandwidth) and in practice I need about twice that to be safe. I realize you need to arbitrarily choose something, but the problem is that if timeouts do occur, there are unhandled warnings like

Warning: An unexpected error occurred. Something may be wrong with WordPress.org or this server&#8217;s configuration. If you continue to have problems, please try the <a href="https://wordpress.org/support/">support forums</a>. (WordPress could not establish a secure connection to WordPress.org. Please contact your server administrator.) in /media/sf_shared/digipowers/www.digipowers.com/httpdocs/wp-includes/update.php on line 297

which doesn't alert you to the real problem, which is that api.wordpress.com took too long to resolve.

To repro this, clear your transients to force an update check, and then force the timeout in class-http.php:96 to something short like 1s:

			/**
			 * Filter the timeout value for an HTTP request.
			 *
			 * @since 2.7.0
			 *
			 * @param int $timeout_value Time in seconds until a request times out.
			 *                           Default 5.
			 */
			'timeout' => 1, //apply_filters( 'http_request_timeout', 5 ),

Recommend you do 2 things:
1) increase the default timeout for the plugin check from say 5 to 10.
2) handle this condition more gracefully by stating what's wrong in this case, e.g., : "WordPress could not connect to the API server to check for plugin updates; please try again later.". And needless to say, don't throw PHP warnings as they break the headers if you have error_reporting and display_errors set to be loud.


Change History (2)

Note: See TracTickets for help on using tickets.