Bug #39232
closed
PHP 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 12 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 12 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 12 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 12 years ago
- Status changed from New to Resolved
- Priority changed from Should have to Must have
Duplicates #35154
Updated by Bernhard Eckl over 11 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) about 10 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.
Updated by