Make WordPress Core

Opened 10 years ago

Closed 8 years ago

#16158 closed defect (bug) (worksforme)

3.0.4 Upgrade failed on localhost testbed, successful on public site

Reported by: dturvene Owned by:
Milestone: Priority: normal
Severity: normal Version: 3.0.1
Component: Upgrade/Install Keywords:
Focuses: Cc:

Description (last modified by ocean90)

Running: 3.0.1, Ubuntu, Apache

I'm still looking at this but wanted to report it while I have a break.

I got the holiday notice to upgrade to 3.0.4. When I did an auto-upgrade on my local testbed (http://localhost:9090/wp/wp-admin/update-core.php), WP reported that I have latest version. Plugin upgrades work fine. The auto upgrade was successful on my public sites. I have WP_DEBUG, etc. on for my local testbed and no errors were reported. I have upgraded my local testbed this way in the past, definitely for 3.0.1.

Below is a debug dump I hack in the WP_HTTP->request call coming from wp_version_check. I pasted the URL use into the browser bar it returned the correct information. Called from wordpress localhost, api.wordpress.com returns a HTML document with the <title>Page not found</title> and a bunch of info about wordpress.

[08-Jan-2011 20:42:48] URL='http://api.wordpress.org/core/version-check/1.5/?version=3.0.1&php=5.3.2-1ubuntu4.5&locale=en_US&mysql=5.0.83&local_package=&blogs=1&users=2&multisite_enabled=0'
[08-Jan-2011 20:42:48] r=array (
  'method' => 'GET',
  'timeout' => 3,
  'redirection' => 5,
  'httpversion' => '1.0',
  'user-agent' => 'WordPress/3.0.1; http://localhost:9090/wp/',
  'blocking' => true,
  'headers' => 
  array (
    'wp_install' => 'http://localhost:9090/wp/',
    'wp_blog' => 'http://localhost:9090/wp/',
    'Accept-Encoding' => 'deflate;q=1.0, compress;q=0.5',
  'cookies' => 
  array (
  'body' => NULL,
  'compress' => false,
  'decompress' => true,
  'sslverify' => true,
  'ssl' => false,
  'local' => false,

So two problems:

1) If the local site core check fails, it assumes what it is running is the most current. There is no indication that the core check failed. It seems like the "Page Not Found" page returned from api.wordpress.org should be displayed. See #16156, #16094 for similar issues.

2) What in the request is causing the HTTP get to fail? I think it must something in the header information. BUT, it USED to work. Is the server behaving differently?

Attachments (1)

garyc40.16158.diff (470 bytes) - added by garyc40 10 years ago.
validate content-type of response

Download all attachments as: .zip

Change History (12)

#1 @ocean90
10 years ago

  • Description modified (diff)
  • Version set to 3.0.1

#3 @dd32
10 years ago

The problem might be the timeout, When running on slower connections, or those with higher latency, less reliability, etc, the timeout can sometimes be too short.

Try increasing it and see if that helps?

Other than that, as pointed out, the error messages for lack of connectivity and failures need to be overhauled.

#4 @Denis-de-Bernardy
10 years ago

  • Cc Denis-de-Bernardy added

#5 @garyc40
10 years ago

I don't think it was a timeout though. Based on what was reported, seems like a response code of 200 was returned.

To dturvene: Could you also dump the request URL inside wp_version_check()?

10 years ago

validate content-type of response

#6 @garyc40
10 years ago

  • Keywords reporter-feedback has-patch dev-feedback added

Just in case the response code is 200, and a HTML response body is returned (due to some sort of error or something), we should probably validate the response body as well.

Right now the only way I can think of is checking content-type (see patch).

Perhaps switch API to returning json in API v1.6?

Last edited 10 years ago by garyc40 (previous) (diff)

#7 @nacin
10 years ago

Or serialized PHP.

We need to validate this somehow. I got the starbucks proxy page stuffed into a transient last week.

#8 @dd32
10 years ago

  • Keywords needs-patch 3.2-early added; reporter-feedback has-patch removed
  • Milestone changed from Awaiting Review to Future Release

Ah yes, I misread the ticket.. Validation needs to happen here, switching to a Serialized PHP return seems to be the most obvious solution, and it'll fit in with the rest of the API's default return types

#9 @dturvene
10 years ago

The upgrade seems to work from http://localhost:9090 now. Sorry for the false alarm.

Just to document the symptoms from last night:

Response code is 404 and the wordpress.com "Sorry, no posts match your criteria" page is returned in the body.

Here's the URL I dumped directly from the WP_Http::request call:



Also, I noticed that if get_core_updates fails then list_core_update isn't called and there is a hole on the update screen the text from list_core_update should be. So, at least, that's an indication that version retrieval from wordpress.org did not work for some reason.

Last edited 10 years ago by dturvene (previous) (diff)

#10 @dd32
8 years ago

  • Component changed from HTTP to Upgrade/Install

#11 @dd32
8 years ago

  • Keywords needs-patch dev-feedback 3.2-early removed
  • Milestone Future Release deleted
  • Resolution set to worksforme
  • Status changed from new to closed

Ah yes, I misread the ticket.. Validation needs to happen here, switching to a Serialized PHP return seems to be the most obvious solution, and it'll fit in with the rest of the API's default return types

The 1.6 version of the Core Update check API returns serialized data. The other items are fixed/worksforme

Note: See TracTickets for help on using tickets.