#008969: Char transform cache file is not valid PHP

Note that some chars in my cache code example were messed up in my error report, they were alright in the cache file.

#249665 by Kristof Coomans on September 6th, 2006 [Permanent Link]

Please attach the file as a gzipped file so that we can have a look at it.

#249666 by Derick Rethans on September 6th, 2006 [Permanent Link]

I checked, but this file parses fine with every php 5.1.x version and 5.2.0dev:

derick@tequila:/tmp$ php-5.1.1 -n -l g-identifier-2166825758-utf-8.ctt.php
No syntax errors detected in g-identifier-2166825758-utf-8.ctt.php

derick@tequila:/tmp$ php-5.1.6 -n -l g-identifier-2166825758-utf-8.ctt.php
No syntax errors detected in g-identifier-2166825758-utf-8.ctt.php

#249667 by Derick Rethans on September 6th, 2006 [Permanent Link]

You're right Derick, there's nothing wrong with the file, it 's probably my editor which does not know how to display it right.

Any idea why the content of the cache file is displayed instead of included with PHP5?

#249668 by Kristof Coomans on September 6th, 2006 [Permanent Link]

As a future reference:

It happens when PHP is compiled with --enable-zend-multibyte and the mbstring extension is enabled.

#251528 by Kristof Coomans on January 31st, 2007 [Permanent Link]

Reopening bug because this affects unstable PHP5 branch.

#253971 by Kristof Coomans on October 3rd, 2007 [Permanent Link]

This issue is still occurring (see duplicate http://issues.ez.no/11994), so reopening.

#254704 by Kristof Coomans on November 20th, 2007 [Permanent Link]

Fixed in trunk (4.0.0beta1) ver. 20862

#254825 by Vladimir Polyanin on November 26th, 2007 [Permanent Link]

Afraid this fixes the symptom, not the cause.

#254846 by Ole Marius Smestad on November 27th, 2007 [Permanent Link]

Fixed in trunk (4.0.0rc1) rev. 20911

#254904 by Vladimir Polyanin on November 28th, 2007 [Permanent Link]

I got a report from a partner that this bug still occurs with eZ Publish 4.0.0 on PHP 5.1.2, so reopening.

#255069 by Kristof Coomans on December 6th, 2007 [Permanent Link]

Fixed in trunk (4.1.0alpha1) rev. 21092
Merged to stable/4.0 (4.0.1) rev. 21093

#255249 by Vladimir Polyanin on December 26th, 2007 [Permanent Link]

Hi,
since this bug is fixed eZP4 behaves pretty strange.
A lot of question marks (which seems to be the substitude character) are generated in the output.
I figured out that the UTF8Map from eZCodePage is not stored correctly
to the cache file. Even though valid PHP5 is generated, it looks like:

$utf8map[0] = chr(0);
...
$utf8map[0] = chr(0);
$utf8map[0] = chr(0);
$utf8map[0] = chr(0);
$utf8map[0] = chr(0);
$utf8map[0] = chr(0);
$utf8map[0] = chr(0);
$utf8map[48] = '0';
$utf8map[49] = '1';
$utf8map[50] = '2';
$utf8map[51] = '3';
$utf8map[52] = '4';
...
$utf8map[0] = chr(0);

This output is caused by the following lines of code
(\lib\ezi18n\classes\ezcodepage.php ~433):

$item = $this->UTF8Map[$key];
if ( $item == 0 )
{ $str .= "\$utf8map[0] = chr(0);\n";
}

else ...

I guess this wont work because a character is compared against an integer, which is always true unless $item is 0,1,2,3,4....
I used the following code to verify this:

var_dump( 'a' == 0 ); output: bool(true)
var_dump( 'a' == null ); output: bool(false)

So probably its better to compare agains null:
if( $item == null ) ...

Im using PHP 5.2.5, mbstring is not enabled.
Regards,
Thomas

#255304 by Thomas Weustenfeld on January 2nd, 2008 [Permanent Link]

Again reopening, due to last comment.

#255346 by Kristof Coomans on January 8th, 2008 [Permanent Link]

I can confirm that the fix causes issues, I experienced some INI files not being parsed properly.

The problem is using the troublesome == operator in PHP, instead it should check using === and also check for the "\0" string.

Also the second check for \0 checks the wrong variable, it checks $item but it needs to be $key.

I've attached a possible fix for it.

#255496 by Jan Borsodi on January 17th, 2008 [Permanent Link]

- Attachments: » i18n-fix.diff

Current fix is surely wrong, at least on 2 levels:
- comparison operator
- index set to 0 when val is NULL char (and viceversa in utf8codemap array

while these can be easily fixed, I am not really sure the problem lies in the NULL char.

If the original error only happens with php installations using --enable-zend-multibyte, it is more likely that a BOM string inside php code (0xFE0xFF or 0xFF0xFE) is what is triggering the display-instead-of-including error in php.

The attached file is a simple test to generate php files similar to what the codepage caches look like and then including them.

#256296 by Gaetano Giunta on April 4th, 2008 [Permanent Link]

- Attachments: » z.php

Issue is still present in 4.0 (downloaded today).

#256561 by Till Klampaeckel on May 2nd, 2008 [Permanent Link]

After discussing with Derick it seems --enable-zend-multibyte is rather broken in current versions of PHP and will be removed in PHP 5.3. Patches from Vladimir should be reverted as they don't fix the problem.

#257132 by Ole Morten Halvorsen on June 19th, 2008 [Permanent Link]

Some more people that have this issue:
http://ez.no/developer/forum/general/site_is_rendered_correctly_only_if_var_cache_is_empty

#258550 by André R. on October 14th, 2008 [Permanent Link]