Code Styling Project

After long retrieval, frustrating feedbacks about the previous made temporary patch, i had already published, finally i found the reason of this ugly issue! I have installed a fresh WordPress 2.6 at my local machines XAMPP system and reproduced it successfully. Intensive research at the web showed me a lot of massive problems related to this bug. I will show here the main facts about and will also change the WP Bug Trac entry with this informations. Hopefully this fix will occure in next release of WordPress and solves this topic for all the time.

First of all, i will show you again, what about i’m writing. The output below shows the error reproduced at my test environment after forcing it:

Warning: unpack() [function.unpack]: Type V: not enough input, need 4, have 0 in C:\xampp\_root_wordpress26\wp-includes\gettext.php on line 91
Warning: unpack() [function.unpack]: Type V: not enough input, need 4, have 0 in C:\xampp\_root_wordpress26\wp-includes\gettext.php on line 91
Warning: unpack() [function.unpack]: Type V: not enough input, need 4, have 0 in C:\xampp\_root_wordpress26\wp-includes\gettext.php on line 91
Warning: unpack() [function.unpack]: Type V: not enough input, need 4, have 0 in C:\xampp\_root_wordpress26\wp-includes\gettext.php on line 91
Fatal error: Maximum execution time of 60 seconds exceeded in C:\xampp\_root_wordpress26\wp-includes\streams.php on line 66
Fatal error: Maximum execution time of 60 seconds exceeded in C:\xampp\_root_wordpress26\wp-includes\wp-db.php on line 359

This error messages with hints to unpack(), gettext() and the well known maximum execution time and terminal abort of script execution should be known by any affected user. To force this behavoir in my locale XAMPP Installation (done with WP 2.6 but affects also WP 2.5.x and less i’m afraid), i changed at php.ini the following setting:

; overload(replace) single byte functions by mbstring functions.
; mail(), ereg(), etc are overloaded by mb_send_mail(), mb_ereg(),
; etc. Possible values are 0,1,2,4 or combination of them.
; For example, 7 for overload everything.
; 0: No overload
; 1: Overload mail() function
; 2: Overload str*() functions
; 4: Overload ereg*() functions
mbstring.func_overload = 7

The whole purpose of overloading string functions by multibyte corresponding ones should be the easy assistance of PHP for unicode dependend pages. But this can’t be done at this way and produces a lot of secondary issues and unwanted behavoir at execution time of PHP scripts (not only restricted to WordPress!).
As soon as the entry at php.ini has been set ro mbstring.func_overload = 0, all scripts works well as expected and the translation files can be used as normally intended.

Those of you thinking: “Thats the goal!” doesn’t realize the big 3 problems waiting behind:

1. Some Provider doesn’t allowed any changes at php.ini .
2. A local php.ini at your own domain need not to be supported.
3. Changing this value using .htaccess file has terrible impacts for you and your neighbor domains!

Let’s look at the adverse effects, if someone tries to make following changes at .htaccess file:

PHP_VALUE mbstring.func_overload 0

Doing so, if your provider supports this, should solve the bug and translation files should be work as expected. But since 2004 there is an unfixed Bug present between mod_php und Apache (Bug #27421 | mbstring.func_overload set in .htaccess becomes global), which forces this setting to act globally for all vhost’s at the affected Apache process !
This meens: if someone changes this value at domain A hosted by the Apache, the domain B at the same server gets immediatly the same value! If your provider normally runs this at value 0 but domain A switches the value to 7, then domain B got this 7 too instead of 0.

All affected Systems i know by error reports of user can be separated into 2 dedicated groups:

• group a) The error happens generally and my prevoius patch doesn’t work at all.
• group b) The error only happens sporadically and is gone after short period of time.

At group a) it looks like the provider has set this value in general for all users (domains) to 2,3,6 or 7 and strictly forces string functions to be overloaded at the affected Apache process. In this case you should talk to your provider if this can be set in general to value 0 or commenting this line (what defaults automatically to 0).

At group b) it is much more complicated to handle this. If you were member of group a), but you have had successful talked to your provider and he switched it off (value = 0), it is possible, that you are now member of group b) and get the error sporadically. This occures, because somebody hosted at the same server does set the value using his .htaccess to one of above show values != 0. If then a page request occures at this domain switching the value and your domain gets also a page request at the same moment, the error will occures because of the global behavoir forced by the Apache / PHP Bug. The bad behavoir of your domain will immediatly stop, if your request will be executed at an Apache instance not been manipulated or the manipulated Apache instance forces a restart. Against this terrible behavoir you have no solution, neigther PHP, Apache’s nor WordPress can provide a fix currently.

Unfortunately this bug has side effects for any PHP driven scripts not only for WordPress. Because of general overload of string function, regexp and mail you may encounter crashes at plugin code, failed or crashed regular expressions but also corrupted mail messages should be send with UTF-8 related content!

The best known solution is to deal with your provider to persist this setting at value 0 and force deny of any change by local php.ini and .htaccess files. This error also affects as example PhpMyAdmin but the code throws an error message and doesn’t allow work with databases, if this value has been set other than 0.

I hope, this descriptions may help you handle this issue. The previous provided patch is not longer nessessary if the value has been set to 0. If you have any feedback, wishes or suggestions, don’t hesitate to wite it. I will respond as soon as possible.

Update: 21.07.2008

I have again developed a new fix for affected streams.php, which i have patched already in previous article. Because i did not know the reason at the first try, it was only a temporary bypass. Now the issue will be handled in any case dependend at the value found for overloading (mbstring.func_overload) and ensures correct load/usage of translation files. I have tested the fix with all possible values of this setting (0 upto 7) and no more aborts or error has been occured regardless of which value has been set at php.ini .

WP 2.5.x / WP 2.6.0 streams.php Patch: streams.php-WP2.5.x_2.6.0.zip
(replaces current streams.php at folder /wp-includes/)