3.0.4 Upgrade failed on localhost testbed, successful on public site — at Version 1
|Reported by:||dturvene||Owned by:|
|Severity:||normal||Keywords:||needs-patch dev-feedback 3.2-early|
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?