New in Symfony 5.3: Logging Improvements

Symfony 5.3 is backed by JoliCode. JoliCode is a team of passionate developers and open-source lovers, with a strong expertise in PHP & Symfony technologies. They can help you build your projects using state-of-the-art practices.

Reset Loggers on Messenger Workers

Contributed by
Laurent Voullemier
in #40761.

One of the most important elements of the Messenger component are the workers that handle and process the messages. In Symfony 4.4 we improved workers to automatically clear the Doctrine entity manager after each message is processed (or failed) to avoid having issues with outdated entities.

In Symfony 5.3 we’ve improved workers again to reset loggers automatically after each message is handled (or failed). This will prevent issues like keeping previous log messages in memory when using buffered log handlers. Upgrading your application to Symfony 5.3 will enable this feature automatically, so you don’t need to configure anything in your application or change your code.

Log Deprecations into a Separate File

Contributed by
Michael Käfer
in #39098.

Symfony’s backward compatibility promise ensures that you can update your applications between minor and patch versions of Symfony without having to change your code to make it work with the new or changed Symfony features.

The key of this policy are the deprecations, which are messages that warn you early about the features that will change/disappear in future major versions of Symfony. When running tests with the Symfony PHPUnit bridge you see the list of deprecations in the console output. However, in complex applications this list is so long that is not practical.

That’s why in Symfony 5.3 you have the option to log deprecations into a separate file when running tests. To do so, use the new logFile option of the SYMFONY_DEPRECATIONS_HELPER environment variable:

1
$ SYMFONY_DEPRECATIONS_HELPER='logFile=/path/to/deprecations.log' ./vendor/bin/simple-phpunit
Help the Symfony project!

As with any Open-Source project, contributing code or documentation is the most common way to help, but we also have a wide range of sponsoring opportunities.

Comments

You can also map PHP error level to PSR log level:

```
# config.yml or framework.yaml
framework:
php_errors:
log:
!php/const \E_DEPRECATED: !php/const Psr\Log\LogLevel::ERROR
!php/const \E_USER_DEPRECATED: !php/const Psr\Log\LogLevel::ERROR
!php/const \E_NOTICE: !php/const Psr\Log\LogLevel::ERROR
!php/const \E_USER_NOTICE: !php/const Psr\Log\LogLevel::ERROR
!php/const \E_STRICT: !php/const Psr\Log\LogLevel::ERROR
!php/const \E_WARNING: !php/const Psr\Log\LogLevel::ERROR
!php/const \E_USER_WARNING: !php/const Psr\Log\LogLevel::ERROR
!php/const \E_COMPILE_WARNING: !php/const Psr\Log\LogLevel::ERROR
!php/const \E_CORE_WARNING: !php/const Psr\Log\LogLevel::ERROR
!php/const \E_USER_ERROR: !php/const Psr\Log\LogLevel::CRITICAL
!php/const \E_RECOVERABLE_ERROR: !php/const Psr\Log\LogLevel::CRITICAL
!php/const \E_COMPILE_ERROR: !php/const Psr\Log\LogLevel::CRITICAL
!php/const \E_PARSE: !php/const Psr\Log\LogLevel::CRITICAL
!php/const \E_ERROR: !php/const Psr\Log\LogLevel::CRITICAL
!php/const \E_CORE_ERROR: !php/const Psr\Log\LogLevel::CRITICAL
```
I'd go one step further, and make deprecations be logged to their own separate file all of the time ;-P
Actually Symfony 5.3 is not sufficient to enable loggers resetting on workers. MonologBundle must be at least at version 3.8.0 (not released yet).
Will this record be recorded every time it runs?
Chinese translation of this article (本文中文译):https://phpzlc.github.io/blog/8.html
Login with SymfonyConnect to post a comment