Fatal error: Maximum execution time of 60 seconds exceeded in C:\xampp\_root_wordpress28_be\wp-includes\pomo\streams.php on line 26

[codestyling]

The re-write of localization feature again introduces a well know issue already handled based on my prior patch suggestion and re-arranged by westi at ​http://core.trac.wordpress.org/attachment/ticket/5599/5599.alternate.diff

Because you wrote a new streams.php inside the POMO folders, the same crash happens again, if the php.ini has a function overload defined:

; 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 = 2

Please re-apply this patch or write a workarround, but keep in mind, that at least some languages form asian/pacific market will have this overload enabled !

[Denis-de-Bernardy]

see #10165

[codestyling]

Replying to Denis-de-Bernardy:

see #10165

I have tested this suggested replacement a bit, here are some intermediate results:

1.) memory consume
the current implementation utilizes 3.83MB on Windows machines
the suggested replacement utilizes 2.54MB on Windows machines
both values are average about 100 runs each.

2.) the speed
not yet tested and measured but feels to be a bit faster.

3.) the compatibility
It seems to work only with the main *.mo file from WordPress itself if replacement put on 2.8 version. All translatable plugins working with current file remain untranslated with new one class.

Could be a base for a fix but not fully suitable as an adhoc replacement. And uses only PHP 5 construction and also protected / public / private modifier not available at PHP 4.

4.) crash test
It doesn't crash (fatal error) but it also doesn't show a translation. Also the WP main translation has been skipped in overload case.

Conclusion
The file may be a suggestion for what can be changed to preserve memory and also speed but nevertheless the overload also affects the str* functions of this suggestion and won't solve the issue!

[nbachiyski]

The overload issue was fixed in ​http://trac.glotpress.org/changeset/138

Could a committer sync the php files from glotpress/pomo with wp-includes/pomo? That should do the trick.

As a side note. I couldn't reproduce the execution time exceed in a CLI script. I added a unit test, to keep track of the issue:

​http://trac.glotpress.org/browser/trunk/t/test_mo.php#L112

However, even if using the same file which causes problems when accessed from a browser, the CLI test runs fine and reads the MO file properly.

[codestyling]

Replying to nbachiyski:

The overload issue was fixed in ​http://trac.glotpress.org/changeset/138

Could a committer sync the php files from glotpress/pomo with wp-includes/pomo? That should do the trick.

As a side note. I couldn't reproduce the execution time exceed in a CLI script. I added a unit test, to keep track of the issue:

​http://trac.glotpress.org/browser/trunk/t/test_mo.php#L112

However, even if using the same file which causes problems when accessed from a browser, the CLI test runs fine and reads the MO file properly.

It requires to reboot Apache Server after changing this setting.
Without a reboot the php.ini is cached and Apache doesn't notice this change.

[nbachiyski]

Replying to codestyling:

It requires to reboot Apache Server after changing this setting.
Without a reboot the php.ini is cached and Apache doesn't notice this change.

I reoot apache on every change of php.ini. The problem isn't with apache. It works (fails) as expected. The interesting thing is that in the CLI it never fails. I am sure the overload option is set to 2, there.

[codestyling]

Replying to nbachiyski:

Replying to codestyling:

It requires to reboot Apache Server after changing this setting.
Without a reboot the php.ini is cached and Apache doesn't notice this change.

I reoot apache on every change of php.ini. The problem isn't with apache. It works (fails) as expected. The interesting thing is that in the CLI it never fails. I am sure the overload option is set to 2, there.

This sounds interesting and should also be inverstigated. Maybe the CLI takes a different php.ini than Server (different environment path lookup) ?
I think, the unit test may also require a "live" testing mode using a real servered page by Apache.

[nbachiyski]

I checked -- the CLI uses the same php.ini and all the values are the same. And, most importantly, the functions are actually overloaded.

[codestyling]

I found also, this overload option contains additionally a bug inside PHP ​http://bugs.php.net/bug.php?id=27421 and much more important, can be used to exploit or crash domains on the same server ​http://www.securityspace.com/smysecure/catid.html?id=800373

This looks like dynamic runtime overload of other vhost's from neighbor vhost at same server using .htaccess file option.
Sounds to me like more buggy code scenarios are inside because of difference between CLI and Apache run.

[ryan]

(In [11626]) Merge latest pomo. Works around mbstring.func_overload. Props nbachiyski. fixes #10236 for trunk

[ryan]

(In [11627]) Merge latest pomo. Works around mbstring.func_overload. Props nbachiyski. fixes #10236 for 2.8.1