PCLZIP_ERR_BAD_FORMAT (-10) after changeset 11524

[demetris]

Incompatible archive PCLZIP_ERR_BAD_FORMAT (-10) : Invalid archive structure

It starts with r11524. Up to r11523 plugin upgrades work OK.

I’m seeing this when upgrading plugins in two of my three test installations. One upgrades via FTP, the other directly.

Relevant ticket/changeset:

​http://core.trac.wordpress.org/ticket/9998

​http://core.trac.wordpress.org/changeset/11524/trunk

Please let me know if you need more information.

[demetris]

Same problem reported on wp.org forum by member arzlonga:

​http://wordpress.org/support/topic/278487

[ryan]

Here's a link to download a version of http.php that does not have the suspect change.

​http://core.trac.wordpress.org/export/11450/trunk/wp-includes/http.php

Download that and install it over wp-includes/http.php. Does that help?

[demetris]

Yes. Using http.php from r11450 solves the problem.

One other thing to note:

After I first reported the issue, the problem was intermittent on the install that upgrades directly (that is, not via FTP) -- sometimes upgrades worked, sometimes they did not work.

In any case, http.php from r11450 solves the problem for direct upgrades as well as for FTP upgrades.

[westi]

It would be good to see what the malformed zip file looks like.

If you hack wp-admin/includes/class-wp-upgrader.php to change the code so as to not delete the downloaded file on unpacking:

	function unpack_package($package, $delete_package = true) {
...

		// Unzip package to working directory
		$result = unzip_file($package, $working_dir); //TODO optimizations, Copy when Move/Rename would suffice?

		// Once extracted, delete the package if required.
		if ( $delete_package )
			unlink($package);

And then share the corrupted file.

Cheers

[dd32]

like westi said, The corrupted file is needed to find out what is causing it..

A side note for other dev's tho, Check that anything thats writing the file to disk is binary safe...

[demetris]

I think I’ll disappoint you all, but both setups work fine now. :-D

(That’s with the current http.php, of course, not with the one from r11450.)

Is it possible that the issue originated in wp.org, because of, say, the increased load during the first hours of the release?

I can see nothing else in common between the two cases: both installs could not upgrade plugins 12 hours ago, and both work OK now.

In any case, if the issue reappears, I’ll do what westi suggested and I’ll upload the ZIP packages.

[ryan]

A timeout will result in a zero length or partial file that will cause the unzip to fail. We've seen that before when we had timeouts too low. Perhaps wp.org was slow enough to cause timeouts for some transports.

[Denis-de-Bernardy]

Might be 32/64-bit related issues, though. In my version checker plugin, I ended up needing to zip my plugins on my server (BSD) rather than my Mac to make things work.

[demetris]

Replying to ryan:

A timeout will result in a zero length or partial file that will cause the unzip to fail. We've seen that before when we had timeouts too low. Perhaps wp.org was slow enough to cause timeouts for some transports.

This hypothesis, if true, would also explain why no tester saw the issue before the final release.

[dd32]

Might be 32/64-bit related issues, though.

Doubtful, they'd be seen consistently with more people.

timeout will result in a zero length or partial file that will cause the unzip to fail

The download shouldnt succeed in that case, The transports should probably check the Content-Length vs. recieved data.

Alternativly, The API could return a CRC32 or md5 of the file.. that way the client can compare and alert straight up that the file is corrupted.

[IndigoJo]

I have been having the same problem when trying to upgrade plugins or install themes since upgrading to WP 2.8. I managed to do the WordPress upgrade itself using this mechanism in v2.7.1, but nothing since.

Worse, the theme browser contains no links to the actual download location or homepage for the themes, which makes the browser into a useless ornament.

[ryan]

Does increasing the timeout in download_url() help? Look for the download_url() function in wp-admin/includes/file.php. Change this line:

$response = wp_remote_get($url, array('timeout' => 30));

to

$response = wp_remote_get($url, array('timeout' => 60));

[ryan]

(In [11587]) Increase download_url() timeout from 30 to 60. see #10104

[ryan]

(In [11588]) Increase download_url() timeout from 30 to 60. see #10104 for 2.8.1

[radial]

I have this same issue, with wordpress 2.8. I have 2 plugins that show I can update, TinyMCE Advanced and wp-dbmanager. When I click automatically upgrade on either of them I immediately get :
Downloading update from ​http://downloads.wordpress.org/plugin/tinymce-advanced.3.2.4.zip.

Unpacking the update.

Incompatible archive PCLZIP_ERR_BAD_FORMAT (-10) : Unable to find End of Central Dir Record signature

I made the timeout change suggested but still occurs. I also commented out the delete package lines as such
if ( $delete_package )
unlink($package);

but I'm not sure where to look for the downloaded package to submit. I look in wp-content/upgrade and its empty

I have other wp 2.8 sites on the same web host that are working just fine.

[dd32]

but I'm not sure where to look for the downloaded package to submit. I look in wp-content/upgrade and its empty

Under most circumstances it'll be under wp-content/ however.. It could also be stored in the servers /tmp directory, which you probably cant access..

[aaroncampbell]

I'm having the original issue (Incompatible archive PCLZIP_ERR_BAD_FORMAT (-10) : Invalid archive structure)

The http.php from r11450 fixes the issue for me. I put my original http.php file back and it immediately broke again. I hacked it to keep it from deleting the archive, and I'll attach a couple to this ticket. The server is a brand new dedicated box from Layered Tech with:
cPanel 11.24.4-RELEASE Build 36167
Apache 2.2.11 (Unix)
PHP 5.2.9
MySQL 5.0.81-community
Kernel 2.6.18-128.1.14.el5

Running CentOS 5. I've only moved one site to it so far, and I'd be happy to supply any additional information or even give a regular here access to it if they think it would help diagnose. The site (​http://geekreprieve.com) is a personal site of no consequence that I moved to the server just to test it.

[aaroncampbell]

Messed up Share This archive (​http://wordpress.org/extend/plugins/share-this/)

[aaroncampbell]

Messed up WP Postviews archive (​http://wordpress.org/extend/plugins/wp-postviews/)

[aaroncampbell]

I almost forgot to mention that I tried the 60 second timeout from [11588] first and that DID NOT fix the problem.

[ryan]

I'm thinking we should revert [11524]. DD32?

I think those expecting http.php to be able to fetch authenticated urls were also bitten by no longer preferring curl. Granted, we really need to have a capability for this and create a list of auth capable transports, but the old way happened to work for lots of people.

[Denis-de-Bernardy]

@Ryan: Yeah, it's way more important to get the unzip from wordpress.org working.

[ryan]

[11630]

[automattor]

(In [11631]) Revert [11524]. curl has its problems, but so does everything else. see #9998 fixes #10104 for 2.8.1