Make WordPress Core

Opened 7 years ago

Last modified 3 years ago

#29719 new defect (bug)

Connection error to when HTTP calls disabled

Reported by: grapplerulrich Owned by:
Milestone: Priority: normal
Severity: minor Version: 4.0
Component: Upgrade/Install Keywords: needs-patch
Focuses: administration Cc:


When the HTTP calls are disabled with either the filter or constant there is an connection error on /wp-admin/update-core.php

add_filter( 'pre_http_request', '__return_true', 100 );
define( 'WP_HTTP_BLOCK_EXTERNAL', true );

The error comes from wp-includes/update.php#L457

Attachments (2)

29719.patch (1.2 KB) - added by grapplerulrich 6 years ago.
29719.1.patch (3.4 KB) - added by grapplerulrich 6 years ago.

Download all attachments as: .zip

Change History (14)

#1 @francescolaffi
7 years ago

  • Component changed from HTTP API to Upgrade/Install
  • Severity changed from normal to minor

I could reproduce the error that only is visible if errors output is enabled and does not break the generation of the page. Of course I guess nobody expects updates to work if http requests are disabled but it could be handled better.

At the end of update.php you linked several update related functions are hooked around, there is a condition to esclude it in some cases (es: subsites in multisite), it could be a good idea be a conditional to avoid it if its not possible to do the checks (something like if (block_request('')) ...)

Also the updates admin page could say that its not possible to check for updates instead that saying that there are no updates.

#2 @SergeyBiryukov
7 years ago

  • Summary changed from Connection error to when HTTP calls disabled to Connection error to when HTTP calls disabled

#3 @jesin
7 years ago

#31023 was marked as a duplicate.

#4 @jesin
7 years ago

How about setting the WP_Error code for the if ( $this->block_request( $url ) ) condition to something meaningful other than http_request_failed. This can be checked inside update.php before throwing a PHP warning.

#5 @najamelan
7 years ago

These are a few of the fixes I made for this:

It might not be the best way, and it's definitely not complete. I discovered another error message the other day somewhere in the dashboard, but I don't remember where right at the moment.

In general the problem is the design choices of wordpress, I think it wasn't build with flexibility in mind (eg. it assumes an internet connection, it assumes your domain doesn't change, it assumes mysql as a db, it assumes a clear separation between frontend and backend so it checks is_admin all over the place...) and I think it has never been rewritten from scratch to make it proper object oriented (eg. way less if else checks all over the place).

All that to say I couldn't make you a formal patch because I don't understand nor agree with the current design choices of wp and I don't know how this would best be fixed other than rewriting the entire core to make less assumptions all over the place.

Hope it helps someone forward. I will try to hunt down that error I had the other day and add it to that github branch for other people trying to have a reference of all places where the core assumes internet.

Last edited 7 years ago by najamelan (previous) (diff)

#6 @SergeyBiryukov
7 years ago

This became more prominent with [30696], see #31011.

#7 @arhak
7 years ago

this issue might be "minor" from a WP admin perspective, but it is a total blocker for the development of a "firewall plugin" which might offer UI to administer which outgoing requests are allowed to get through

it is really annoying to get errors in the admin once you select a whitelist scheme, which by default starts blocking *everything* (and therefore is out)

it is very nasty to present such error to (lets say) a developer which starts using such plugin for the first time

OTOH, if display errors is off (for a non-developer), then this might be considered a security weakness, because admins get the "up to date" green flag, which isn't the case, therefore, giving a false sense of security, and no action will be taken to change a problem that doesn't seem to be there

#8 follow-up: @grapplerulrich
6 years ago

  • Keywords has-patch 2nd-opinion needs-testing added

I have added a patch that I hope should fix it.

#9 in reply to: ↑ 8 @arhak
6 years ago

it is nice to take WP_HTTP_BLOCK_EXTERNAL constant into consideration
but what about pre_http_request filter?

#10 @grapplerulrich
6 years ago

The error message that I was getting was "<b>Warning</b>: An unexpected error occurred. Something may be wrong with or this server’s configuration. If you continue to have problems, please try the <a href="">support forums</a>. (WordPress could not establish a secure connection to Please contact your server administrator.) in <b>/wp-includes/update.php</b> on line <b>122</b><br>"

I am mentioning it as I could not find the issue when I started looking at it again.

The check if ( $ssl && is_wp_error( $raw_response ) ) { does not seem right as it is only activated when ssl is supported and there is an error. Another problem with current code is that only a standard SSL error is displayed when the error could be something else. With the current setup the error return new WP_Error( 'http_request_failed', __( 'User has blocked requests through HTTP.' ) ); in wp-includes/class-http.php is never displayed.

The new patch 29719.1.patch​ should fix it. I am not sure if we should be showing a PHP error when external http requests are disabled. Perhaps a notification would be better.

#11 @ocean90
6 years ago

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

The if ( $ssl && is_wp_error( $raw_response ) ) { check is designed for sites where wp_http_supports( array( 'ssl' ) ) returns true but in reality it can't connect because of cURL/certifcate issues, see #25716.

#12 @grapplerulrich
6 years ago

@ocean90 - Thank you for explaining the history.

The problem is that the following code makes the assumption that the error is an SSL error but there a number of different error messages in class-http.php. Theoretically we would need to check that it is a error specific to SSL and not an error like return new WP_Error( 'http_request_failed', __( 'User has blocked requests through HTTP.' ) );

	if ( $ssl && is_wp_error( $response ) ) {
		trigger_error( __( 'An unexpected error occurred. Something may be wrong with or this server&#8217;s configuration. If you continue to have problems, please try the <a href="">support forums</a>.' ) . ' ' . __( '(WordPress could not establish a secure connection to Please contact your server administrator.)' ), headers_sent() || WP_DEBUG ? E_USER_WARNING : E_USER_NOTICE );
		$response = wp_remote_post( $http_url, $options );

I am not sure how best to solve this.

Note: See TracTickets for help on using tickets.