PHP 8.2: dynamic properties are deprecated

[radimvaculik]

Version: 2.9.5

Bug Description

With PHP 8.2, there is a deprecation error on dynamic properties.

Code

https://github.com/nette/tracy/blob/master/src/Bridges/Nette/TracyExtension.php#L120

[mabar]

In this case best solution would probably be to throw an exception in case logger is not instance of Tracy\Logger. You are using different ILogger implementation that does not support sending emails.

[mabar]

Do you override the logger yourself? Or is it overriden by some logging extension?
I think I already solved that issue in both orisai/nette-monolog and contributte/monolog by preserving original logger (in case Tracy bridge is enabled)

[radimvaculik]

@mabar I use final class SentryDecoratedTracyLogger implements ILogger and use $this->parentLogger = Debugger::getLogger(); to preserve Tracy logging.

[mabar]

Oh, my solution is currently broken too.

It overrides logger returned by Debugger::getLogger() and disables autowiring for service tracy.logger so my ILogger implementation is autowired instead even if service tracy.logger is created before Monolog has chance to wire into Tracy.

But. Order matters. If Monolog extension is loaded first, Tracy sets options to incorrect logger.
My case would be fixed by replacing Tracy\Debugger::getLogger()->mailer = by $this->getService('tracy.logger')->mailer = in generated DIC

[mabar]

@radimvaculik I fixed the issue in orisai/nette-monolog. You should be fine if you copy LazyTracyToPsrLogger changes to your SentryDecoratedTracyLogger orisai/nette-monolog@6f39f96#diff-34f516dc85e79726f910d1b0e989ea939cbf310611cf0507e69eee3b4a12a127R56-R110

[josefsabl]

I have this problem as well, using Contributte/Logging. Obviously this code Tracy\Debugger::getLogger()->mailer = ?; should not rely on the property to maybe exist, rather there should be something like MailLogger interface having the setMailer function.

Adding @ to suppress the deprecation provides a quick fix.

[slepic]

I have the very same problem in a custom implementation of Tracy\ILogger.

My current solution is to place a public $mailer property on my implementation and ignore it's value.

And I 100% agree that Tracy\ILogger does not support email and should not be treated as Tracy\Logger (or anything) which supports email. If a mailer is to be set, you better make sure that you're dealing with Tracy\Logger before you start accessing properties that cannot possibly ever exist on the interface (in fact, on any interface).

Adding magic methods to my implementation is a no go,
Adding a setMailer() method to the interface (or an extended interface) seems viable even if it would be BC. I mean, unless the motto is "If it's broken and we cannot fix it without introducing a BC, we'd rather not fix it at all"....