Project

General

Profile

Actions

Bug #39232

closed

PHP error_reporting cannot be set properly, E_STRICT errors shown on PHP 5.4

Added by Mario Rimann over 11 years ago. Updated over 5 years ago.

Status:
Closed
Priority:
Must have
Assignee:
-
Category:
Miscellaneous
Target version:
-
Start date:
2012-07-25
Due date:
% Done:

0%

Estimated time:
TYPO3 Version:
4.5
PHP Version:
Tags:
Complexity:
Is Regression:
Sprint Focus:

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


Related issues 4 (0 open4 closed)

Related to TYPO3 Core - Bug #38645: New error_reporting settings cause notice "undefined constant E_DEPRECATED " with PHP 5.2Closed2012-07-04

Actions
Related to TYPO3 Core - Bug #38691: Exclude E_STRICT on PHP 5.4ClosedPhilipp Gampe2012-07-05

Actions
Related to TYPO3 Core - Bug #51493: Error Reporting always set with E_WARNINGClosed2013-08-29

Actions
Is duplicate of TYPO3 Core - Bug #35154: Exclude E_STRICT from exceptionalErrors in PHP 5.4Closed2012-03-22

Actions
Actions #1

Updated by Mario Rimann over 11 years ago

Additional Information:
  • 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)
Actions #2

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.

Actions #3

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.

Actions #4

Updated by Ernesto Baschny over 11 years ago

  • Status changed from New to Resolved
  • Priority changed from Should have to Must have

Duplicates #35154

Actions #5

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.

Actions #6

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.

Actions #7

Updated by Benni Mack over 5 years ago

  • Status changed from Resolved to Closed
Actions

Also available in: Atom PDF