TYPO3 Core

Susanne Moog wrote:

error reporting can be configured in TYPO3 via Settings > All Configuration > SYS > errorHandlerErrors - default is "E_ALL & ~(E_STRICT | E_NOTICE | E_COMPILE_WARNING | E_COMPILE_ERROR | E_CORE_WARNING | E_CORE_ERROR | E_PARSE | E_ERROR)". Please try adjusting the setting to your needs.

Hi Susanne,

thanks for your response. I'm aware of this setting. Unfortunately the setting isn't used in some parts of the core. Have a look here:
https://github.com/TYPO3/TYPO3.CMS/blob/e8d2e37199403554609d65f546f7cc76251e7a91/typo3/sysext/core/Classes/Core/Bootstrap.php#L444

There is also a description why this "basis configuration" is necessary. I'm not sure if one could simply use the configured value of

Settings > All Configuration > SYS > errorHandlerErrors

here or just change the hardcoded value to:

error_reporting(E_ALL & ~(E_STRICT | E_NOTICE | E_DEPRECATED | E_USER_DEPRECATED));

To suppress the E_USER_DEPRECATED values also while bootstrapping.

Uwe Trotzek wrote:

here or just change the hardcoded value to:

error_reporting(E_ALL & ~(E_STRICT | E_NOTICE | E_DEPRECATED | E_USER_DEPRECATED));

To suppress the E_USER_DEPRECATED values also while bootstrapping.

I'm trying to figure out where your problem actually comes from. The function you linked is used only once in \TYPO3\CMS\Core\Core\Bootstrap::initializeErrorHandling (on current master) - and directly afterwards the settings of $GLOBALS['TYPO3_CONF_VARS']['SYS'] are used to overwrite that. So as far as I can see from the code, setting those should also impact the TCA migration errors you get... that's what's confusing me at the moment.

Sorry, I somehow missed your comment to this issue.

Now I finally know whats going on here. After some more debugging I realized, that in my instance I had no value set for [SYS][errorHandler]. Because of that, the default php error handler handled the errors in my instance again. The error_reporting value (for the php handler) is locked to the value "22519" because of the \TYPO3\CMS\Core\Core\Bootstrap::initializeErrorHandling method. That's why I got the described deprecation warning in the log.

What was irritating me the whole time was, that no matter what value I set for [SYS][errorHandlerErrors] it didn't affect the error_reporting configuration in the php info page.

I wasn't aware of the https://www.php.net/manual/en/function.set-error-handler.php function which can obviously completely bypass the default php error handler.

Long story short:
After configuring the [SYS][errorHandler] configuration, everything works as expected.

Thanks for your help.

@Uwe Trotzek thank you for your quick and kind reply;

Do you think that this issue can be closed or is there still something that should be done here? Thanks !

I'm not really sure what TYPO3 should do here.

[SYS][errorHandler]
Classname to handle PHP errors. E.g.: TYPO3\CMS\Core\Error\ErrorHandler. This class displays and logs all errors that are registered as
[SYS][errorHandlerErrors]. Leave empty to disable error handling. Errors will be logged and can be sent to the optionally installed
developer log or to the "syslog" database table.

The description of the errorHandler suggests to disable the custom handler by leaving the value empty (which I did in my case). But then you have no chance to configure the error_reporting setting for the default php error handler as it will be overridden during the bootstrap.

In my opinion TYPO3 should either reset the value to the initial value of error_reporting from the php.ini or a separate configuration for the php default error handler should be provided.

The hardcoded value is obviously mainly necessary for the ext_localconf and ext_tables inclusion of extensions, which is described in the method:
https://github.com/TYPO3/TYPO3.CMS/blob/e8d2e37199403554609d65f546f7cc76251e7a91/typo3/sysext/core/Classes/Core/Bootstrap.php#L432

I can confirm that this is indeed still a problem.

I ran into quite a problem with a high performance website because monitoring on one node failed to spot that the diskspace was filled due to high traffic and a consistent flow of errors generated by the TYPO3 core itself (E_USER_DEPRECATED) which lead so quite some problems. Once I figured out that setting error_reporting globally to 0 did not solve the problem, since the core would set it to something else anyway and not recover, I decided to patch.

IMHO, the use case of disabling all error logging is valid, as you might not need to log such errors anywhere on a single node that just responds to small requests and the fact that TYPO3 code forces the use of 22519 is a bit disturbing.