WordPress.org

Make WordPress Core

Opened 11 years ago

Closed 11 years ago

Last modified 11 years ago

#15789 closed defect (bug) (fixed)

PCLZIP_ERR_BAD_FORMAT (-10) : Invalid block size : 40

Reported by: googol7 Owned by:
Milestone: 3.2 Priority: normal
Severity: normal Version: 3.0.2
Component: Upgrade/Install Keywords:
Focuses: Cc:

Description

When updating the core or the plugins i got the error:

PCLZIP_ERR_BAD_FORMAT (-10) : Invalid block size : 40

the problem was solved when I removed

mbstring.func_overload = "7"

from my PHP.INI and it workes now!

Philipp

Change History (11)

#1 @ocean90
11 years ago

  • Cc dd32 added
  • Component changed from General to Upgrade/Install

#2 @dd32
11 years ago

Upon investigating mbstring.func_overload = "7", it does seem likely that such a functionality could be causing the PclZip errors.

With the PHP requirement in WordPRess 3.2 being bumped to PHP 5.2, I'm hoping that more hosts will use the PHP Zip Extension, but i'm not 100% sure on how standard that is amongst installs.

It however, would be good to investigate this further to find out if it's possible to work around it.. if it's indeed what is causing PclZip to fail often.

#3 @nacin
11 years ago

  • Milestone changed from Awaiting Review to Future Release

#4 @dd32
11 years ago

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

(In [17592]) Set the mb_string internal encoding to ISO-8859-1 whilst uncompressing archives using PclZip. Fixes 'PCLZIP_ERR_BAD_FORMAT (-10) : Invalid block size' errors on systems utilising mbstring.func_overload. Fixes #15789

#5 @dd32
11 years ago

  • Milestone changed from Future Release to 3.2

I attempted to apply that to the PclZip class itself, but that just lead me down paths I'd rather not take..

#6 @scribu
11 years ago

Re [17592]: Are we going to respect the coding standards or should we just remove the part about whitespace?

#7 @scribu
11 years ago

Specifically, this part:

When calling a function, do it like so:

myfunction( $param1, funcparam( $param2 ) );

#8 @dd32
11 years ago

Are we going to respect the coding standards or should we just remove the part about whitespace?

When patching inside a larger function, it's more readable to utilise the same white space rules IMO; Any patches I write follows the standard used in that particular code, it reduces the amount of useless changes(ie. whitespace only) needed to surrounding code to make the change readable in the context.

The rest of the function does not use spaces inside a function call, unless the parameter is more than a single variable - Honestly, Thats how 95% of the WP_Upgrader & related code is written.

#9 @scribu
11 years ago

I know what you mean. I'm not particularly fond of it, either.

So, again I ask: should we remove that part of the standard? since we can't seem to enforce it, even for new code.

#11 @sivel
11 years ago

Replying to scribu:

I know what you mean. I'm not particularly fond of it, either.

So, again I ask: should we remove that part of the standard? since we can't seem to enforce it, even for new code.

Coding standards are more guidelines than rules. Do what works best in a certain context. I personally space out code that I touch during patches. Per a discussion at one point that was the goal. Apply the coding standards to the small pieces of code that we touch on a day to day basis in patches, to eventually migrate the whole of the code under the guidelines as stated in the coding standards.

Note: See TracTickets for help on using tickets.