Bug #39232
closedPHP error_reporting cannot be set properly, E_STRICT errors shown on PHP 5.4
0%
Description
Hi
I tested this with- TYPO3 v4.5.17
- PHP 5.4.4
- Ubuntu 10.04 LTS
Running the TYPO3 website with PHP 5.3.x runs fine. As soon as it's ran on PHP 5.4.4, several "Strict Standards"-errors are shown in the frontend, many of the following (with different files and line numbers):
Strict Standards: Non-static method t3lib_TSparser::checkIncludeLines() should not be called statically, assuming $this from incompatible context in /path_to_directory/typo3_src-4.5.17/t3lib/class.t3lib_tsparser.php on line 642
Setting error_reporting to 30711 (equivalent to E_ALL without E_STRICT and E_NOTICE) directly in php.ini does not solve the problem, altough a simple test-script shows the correct value (echo error_reporting()).
After some hours of trial and error, I got it to be silent:
The only way that I found to silence this TYPO3 installation, was to set the error_reporting level via the Apache vHost-Configuration. So in my config file, I have the following entry:
<Directory /var/www/vhosts/test54.ch/httpdocs> php_admin_value error_reporting 30711 </Directory>
As soon as this value is in, the E_STRICT notices are gone from the FE output.
Another way to achieve the same thing, is to have this in the global configuration (e.g. in /etc/apache2/conf.d/php_error_reporting.conf), this way it can be done once per server instead of adding it to the config of each single vHost:
<Directory /var/www/vhosts> php_admin_value error_reporting 30711 </Directory>
While this might be a PHP bug, I was not able to reproce any E_STRICT warning at all, while being on that server, but not within TYPO3. It looks like the TYPO3 internal "let's override the error_reporting level"-functionality (or something else within TYPO3) bring up this behaviour - but I'm really not sure what's wrong here.
I would understand it, if it would be the other way round, e.g. that things from php.ini cannot be overriden that easy - but here it's the exact oposite direction...?
This is probably somehow related to #35154 and #38691 and maybe also #38645