Sends your logs to files, sockets, inboxes, databases and various web services
CubeHandler and PHPConsoleHandler as both projects are abandoned and those should not be used anymore (#1734)Logger @final as it should not be extended, prefer composition or talk to us if you are missing something7 to 0) support to Logger::log and Logger::addRecord to increase interoperability (#1723)SyslogFormatter to output syslog-like files which can be consumed by tools like lnav (#1689)__toString for objects which are not json serializable in JsonFormatter (#1733)GoogleCloudLoggingFormatter (#1719)AmqpHandler->setExtraAttributes to allow configuring attributes when using an AMQPExchange (#1724)\n or \r sequences (#1720)$datetime parameter to Logger::addRecord as low level API to allow logging into the past or future (#1682)Logger::useLoggingLoopDetection to allow disabling cyclic logging detection in concurrent frameworks (#1681)Monolog\Test\TestCase class as @internal to make sure PHPStorm does not show it above PHPUnit, you may still use it to test your own handlers/etc though (#1677)$datetime parameter to Logger::addRecord as low level API to allow logging into the past or future (#1682)Logger::useLoggingLoopDetection to allow disabling cyclic logging detection in concurrent frameworks (#1681)Monolog\Test\TestCase class as @internal to make sure PHPStorm does not show it above PHPUnit, you may still use it to test your own handlers/etc though (#1677)This is mostly a cleanup release offering stronger type guarantees for integrators with the array->object/enum changes, but there is no big new feature for end users.
See UPGRADE notes for details on all breaking changes especially if you are extending/implementing Monolog classes/interfaces.
Noteworthy BC Breaks:
8.1.0.Monolog\LogRecord object
with public (and mostly readonly) properties. e.g. instead of doing
$record['context'] use $record->context.
In formatters or handlers if you rather need an array to work with you can use $record->toArray()
to get back a Monolog 1/2 style record array. This will contain the enum values instead of enum cases
in the level and level_name keys to be more backwards compatible and use simpler data types.FormatterInterface, HandlerInterface, ProcessorInterface, etc. changed to contain LogRecord $record
instead of array $record parameter types. If you want to support multiple Monolog versions this should
be possible by type-hinting nothing, or array|LogRecord if you support PHP 8.0+. You can then code
against the $record using Monolog 2 style as LogRecord implements ArrayAccess for BC.
The interfaces do not require a LogRecord return type even where it would be applicable, but if you only
support Monolog 3 in integration code I would recommend you use LogRecord return types wherever fitting
to ensure forward compatibility as it may be added in Monolog 4.Monolog\Level
ResettableInterface::reset() now requires a void return type.New deprecations:
Logger::DEBUG, Logger::ERROR, etc. are now deprecated in favor of the Monolog\Level enum.
e.g. instead of Logger::WARNING use Level::Warning if you need to pass the enum case
to Monolog or one of its handlers, or Level::Warning->value if you need the integer
value equal to what Logger::WARNING was giving you.Logger::getLevelName() is now deprecated.SwiftMailerHandler, use SymfonyMailerHandler insteadSymfonyMailerHandler (#1663)This is mostly a cleanup release offering stronger type guarantees for integrators with the array->object/enum changes, but there is no big new feature for end users.
See UPGRADE notes for details on all breaking changes especially if you are extending/implementing Monolog classes/interfaces.
Noteworthy BC Breaks:
8.1.0.Monolog\LogRecord object
with public (and mostly readonly) properties. e.g. instead of doing
$record['context'] use $record->context.
In formatters or handlers if you rather need an array to work with you can use $record->toArray()
to get back a Monolog 1/2 style record array. This will contain the enum values instead of enum cases
in the level and level_name keys to be more backwards compatible and use simpler data types.FormatterInterface, HandlerInterface, ProcessorInterface, etc. changed to contain LogRecord $record
instead of array $record parameter types. If you want to support multiple Monolog versions this should
be possible by type-hinting nothing, or array|LogRecord if you support PHP 8.0+. You can then code
against the $record using Monolog 2 style as LogRecord implements ArrayAccess for BC.
The interfaces do not require a LogRecord return type even where it would be applicable, but if you only
support Monolog 3 in integration code I would recommend you use LogRecord return types wherever fitting
to ensure forward compatibility as it may be added in Monolog 4.Monolog\Level and Monolog\LevelName
ResettableInterface::reset() now requires a void return type.New deprecations:
Logger::DEBUG, Logger::ERROR, etc. are now deprecated in favor of the Monolog\Level enum.
e.g. instead of Logger::WARNING use Level::Warning if you need to pass the enum case
to Monolog or one of its handlers, or Level::Warning->value if you need the integer
value equal to what Logger::WARNING was giving you.Logger::getLevelName() is now deprecated.callType to IntrospectionProcessor (#1612)Full Changelog: https://github.com/Seldaek/monolog/compare/2.4.0...2.5.0
Monolog\LogRecord interface that can be used to type-hint records like array|\Monolog\LogRecord $record to be forward compatible with the upcoming Monolog 3 changesincludeStacktraces constructor params to LineFormatter & JsonFormatter (#1603)persistent, timeout, writingTimeout, connectionTimeout, chunkSize constructor params to SocketHandler and derivatives (#1600)AsMonologProcessor PHP attribute which can help autowiring / autoconfiguration of processors if frameworks / integrations decide to make use of it. This is useless when used purely with Monolog (#1637)user_agent key in WebProcessor, disabled by default but you can use it by configuring the $extraFields you want (#1613)self (#1609)