PCLZIP_ERR_BAD_FORMAT (-10) : Invalid block size : 40

[googol7]

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

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.

(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

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

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

Specifically, ​this part:

When calling a function, do it like so:

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

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.

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.

No.

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.