Make WordPress Core

Opened 15 years ago

Closed 15 years ago

#10104 closed defect (bug) (fixed)

PCLZIP_ERR_BAD_FORMAT (-10) after changeset 11524

Reported by: demetris's profile demetris Owned by: dd32's profile dd32
Milestone: 2.8.1 Priority: normal
Severity: major Version: 2.8
Component: Upgrade/Install Keywords: needs-patch reporter-feedback
Focuses: Cc:

Description

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.

Attachments (2)

share-this.zip (129.7 KB) - added by aaroncampbell 15 years ago.
Messed up Share This archive (http://wordpress.org/extend/plugins/share-this/)
wp-postviews.1.50.zip (17.5 KB) - added by aaroncampbell 15 years ago.
Messed up WP Postviews archive (http://wordpress.org/extend/plugins/wp-postviews/)

Download all attachments as: .zip

Change History (25)

#1 @Denis-de-Bernardy
15 years ago

  • Keywords needs-patch added
  • Severity changed from normal to major

#2 @demetris
15 years ago

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

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

#3 @ryan
15 years ago

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?

#4 @demetris
15 years ago

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.

#5 @westi
15 years ago

  • Cc westi added
  • Keywords reporter-feedback added

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

#6 @dd32
15 years ago

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...

#7 @demetris
15 years ago

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.

#8 follow-up: @ryan
15 years ago

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.

#9 @Denis-de-Bernardy
15 years ago

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.

#10 in reply to: ↑ 8 @demetris
15 years ago

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.

#11 @dd32
15 years ago

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.

#12 @IndigoJo
15 years ago

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.

#13 @ryan
15 years ago

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));

#14 @ryan
15 years ago

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

#15 @ryan
15 years ago

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

#16 @radial
15 years ago

  • Cc radial added

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.

#17 @dd32
15 years ago

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..

#18 @aaroncampbell
15 years ago

  • Cc aaroncampbell added

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.

#19 @aaroncampbell
15 years ago

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

#20 @ryan
15 years ago

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.

#21 @Denis-de-Bernardy
15 years ago

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

#23 @automattor
15 years ago

  • Resolution set to fixed
  • Status changed from new to closed

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

Note: See TracTickets for help on using tickets.