[TYPO3-core] RFC #6415: Bug: preg_replace error on php5.2 sometimes resulting in empty pages.

[Ernesto Baschny [cron IT]]

Jan-Erik Revsbech wrote: on 21.01.2008 08:56:

>>> on one of my sites. The regular expression is not correct, and should
>> in my
>>> opinion be '/(<(a|area).+href=")(#[^"]*")/i'
>> -1. Your expression will match to the second href while original will
>> match to the first in this string:
>>
>> <a href="#x1"> href="#x2">
>>
>> Result for original regexp:
>>
>> <a href="http://path/#x1"> href="#x2" </a>
>>
>> Result for your regexp:
>>
>> <a href="#x1"> href="http://path/#x2" </a>
>>
>> Question mark in the first expression is used to find shortest match.

> Indeed you are right, I stand corrected (Always good to lean new stuff,
> thanks). But I still think that there should at least be some error
> checking. The attached patch now has the original regular expression, but
> has the required error_checking (Still php 5.2 only).

Yes, while I haven't seen this bug behaviour in "action" (haven't seen 
so many links on one page), I think we must handle that. To further 
consider this patch, Jan-Erik, can you please provide us a setup where 
this issue arises? Maybe an exported t3x file.

The error checking in the patch looks all right, haven't tested it, 
thou. The phpdoc comment change for the return value is not correct, as 
it still returns "void" and modifies $this->content.

Apart from that, we might also just issue:

	ini_set('pcre.backtrack_limit', 1000000);

(1 million) somewhere when starting the TYPO3. The default PHP 
backtrack_limit is 100000 (100k), meaning that it won't backtrack after 
100k bytes of data (which is used because of the non-greedy modifier in 
".*?").

Also we must have that value checked and a warning spit out in the 
Install Tool.

Cheers,
Ernesto