August, 2013 | Ady's Blog

I used to upgrade WordPress manually using FTP. I would update a local copy of the website, make sure everything works on my laptop and then upload it to the server. Not that I don’t trust WordPress automatic upgrade but I am paranoid that my custom plugins and changes will break the site.

However, starting from early 2012 I began to use the upgrade functionality within WordPress. Everything went really well until after I upgraded to 3.5

I wasn’t able to upgrade to 3.5.1 but I was able to upgrade another blog with earlier version than 3.5 to 3.5.1. So I thought it might be a problem with the settings or permissions on this site.

Today, I looked at the issue again. What I found is that there is a discrepancy between the upgrade code and the data returned by API.

The code failed here wp-admin/includes/class-wp-upgrader.php:

111   function download_package($package) {
116     if ( empty($package) )
117       return new WP_Error('no_package', $this->strings['no_package']);
127   }

Called within the same file:

878     $download = $this->download_package( $current->package );
879     if ( is_wp_error($download) )
880       return $download;

There are a lot more tracing done, but ultimately line 878 will always fail because $current does not have the property package:

stdClass Object
(
    [response] => upgrade
    [download] => http://wordpress.org/wordpress-3.6.zip
    [locale] => en_US
    [packages] => stdClass Object
        (
            [full] => http://wordpress.org/wordpress-3.6.zip
            [no_content] => http://wordpress.org/wordpress-3.6-no-content.zip
            [new_bundled] => http://wordpress.org/wordpress-3.6-new-bundled.zip
            [partial] => 
        )
 
    [current] => 3.6
    [php_version] => 5.2.4
    [mysql_version] => 5.0
    [new_bundled] => 3.6
    [partial_version] => 
    [dismissed] => 
)

I wanted to create a Trac ticket but realized that this should have been fixed, and this is a backward compatible issue anyway. Looking at the new code http://core.trac.wordpress.org/browser/trunk/wp-admin/includes/class-wp-upgrader.php?rev=24474 I am able to see that the packages properties has been handled.

A quick look at 3.5.1 also suggests that the new data returned has been handled correctly.

   1036     // If partial update is returned from the API, use that, unless we're doing a reinstall.
   1037     // If we cross the new_bundled version number, then use the new_bundled zip.
   1038     // Don't though if the constant is set to skip bundled items.
   1039     // If the API returns a no_content zip, go with it. Finally, default to the full zip.
   1040     if ( $current->packages->partial && 'reinstall' != $current->response && $wp_version == $current->partial_version )
   1041       $to_download = 'partial';
   1042     elseif ( $current->packages->new_bundled && version_compare( $wp_version, $current->new_bundled, '< ' )
   1043       && ( ! defined( 'CORE_UPGRADE_SKIP_NEW_BUNDLED' ) || ! CORE_UPGRADE_SKIP_NEW_BUNDLED ) )
   1044       $to_download = 'new_bundled';
   1045     elseif ( $current->packages->no_content )
   1046       $to_download = 'no_content';
   1047     else
   1048       $to_download = 'full';
   1049 
   1050     $download = $this->download_package( $current->packages->$to_download );
   1051     if ( is_wp_error($download) )
   1052       return $download;

My quick and dirty hack is to edit wp-admin/includes/class-wp-upgrader.php

    878     $download = $this->download_package( 'http://wordpress.org/wordpress-3.6-no-content.zip' );

Just like that, and upgrade was quick. If you’re stuck in 3.5 you can try it out.

Month: August 2013

WordPress Update: Upgrade package not available (3.5)