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
Updated by Mario Rimann over 11 years ago
- PHP is ran as mod_php on Apache
- I've checked with phpinfo() from the install tool, that the proper php.ini file is loaded and processed (changing the error_reporting value in there also showed an effect when echo'ing error_reporting() - but didn't solve the problem)
Updated by Ernesto Baschny over 11 years ago
Without analysing your report in depth, one comment:
mod_php's php_admin_value
can only be set on a "virtual host" (or global) webserver context, and is a setting which cannot be overridden by either .htaccess (where you only can set php_value) or PHP error_reporting() method. This it is a setting an admin can enforce upon a user of a virtual host, which he cannot override (which makes sense for memory_limit, max_execution etc..).
So in this case setting this won't let TYPO3 manipulate error_reporting, which it does in it's start-up scripts, for example tslib/index_ts.php.
Updated by Markus Klein over 11 years ago
Just a note: all pending PHP 5.4 patches were now submitted by Helmut, therefore the Core should now always set the correct error_reporting.
Maybe you can retry your tests now.
Updated by Ernesto Baschny over 11 years ago
- Status changed from New to Resolved
- Priority changed from Should have to Must have
Duplicates #35154
Updated by Bernhard Eckl over 10 years ago
I also had the same problem and tried so many things for a few hours. I cloned a T3 system to a new Debian 7 server with PHP 5.4. I have set via .htaccess:
php_flag display_startup_errors off php_flag display_errors off php_flag html_errors off php_value docref_root 0 php_value docref_ext 0 php_value error_reporting 0 php_value display_errors 0 php_value display_errors Off php_value error_reporting 0 php_value display_errors 0 php_value error_reporting 30719
And via localconf.php:
$TYPO3_CONF_VARS['SYS']['exceptionalErrors'] = '30711'; $TYPO3_CONF_VARS['SYS']['errorHandlerErrors'] = '30711';
But it did not help. Opening phpinfo via install tool gives mie:
error_reporting local = 22519
error_reporting master = 30719
But when I set php_admin_value error_reporting 30711 in the apache configuration, the errors are gone and I have error_reporting local = 30711.
Like this:
<Directory /var/www/vhosts/host/> Options Indexes FollowSymLinks MultiViews php_admin_value error_reporting 30711 AllowOverride All Order allow,deny allow from all </Directory>
So I think TYPO3 overwrites that values. If I ran phpinfo separately (not via Install Tool), it displays the same local value as the master value.
TYPO3 version ist 4.7.12.
Updated by Dan Kleine (Untenzu) over 9 years ago
Stumbled upon the same bug today on a machine with Ubuntu 14.04, PHP 5.5.9-1ubuntu4.5, PHP OPcache Version: 7.0.3FE
Same story as Bernhard Eckl described → »PHP Info« in Install Tool is showing the value »22519« for local error_reporting, regardless of any settings in Install Tool, or htaccess.
Therefore several »Strict Standards«-errors are shown in the frontend and backend (since they are part of E_ALL in PHP > 5.3).
Forcing the error_reporting parameter to a value using »php_admin_value« in the virtual host configuration buried the problem, since TYPO3 is not able to override the value afterwards. But of course, this isn't a good solution, since setting the option in the Install Tool if the prefereed method.
Btw: I searched for possible spots in the code for this behaviour, just as Tizian Schmidlin did in #51493, but can't find anything usefull.