[TYPO3-core] Strategy for deprecation log

Steffen Müller typo3 at t3node.com
Tue Apr 2 16:23:02 CEST 2013


Hi.

On 01.04.2013 15:57 Markus Klein wrote:
> It MIGHT lead to serious troubles in the (unknown) future, especially when it comes to database functions being deprecated. Somewhat a chicken - egg problem.

This is a valid argument.

There are already some places where the Logging API runs in endless
recursions when used: Autoloader, GeneralUtility::makeInstance() and
parts of the Logging API itself.

ATM the deprecation functions depend on t3lib_lock and
t3lib_utility_Debug::debugTrail() where we already would have a
chicken/egg situation.

Alternatively we could deliver a lightweight and independent solution
for deprecation log:

trigger_error($msg, E_USER_DEPRECATED);

ATM this is catched by error/exception handler and would need to be
excluded.

This could cure the pain of superfluous deprecation log files. I expect
php error_log being logrotated by default on 99.9% of all hosting
environments.

-- 
cheers,
Steffen

TYPO3 Blog: http://www.t3node.com/
Twitter: @t3node - http://twitter.com/t3node


More information about the TYPO3-team-core mailing list