PHP 8.2: dynamic properties are deprecated about tracy HOT 7 CLOSED

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.

from tracy.

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.

from tracy.

@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

from tracy.

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)

from tracy.

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

from tracy.

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

from tracy.

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"....

from tracy.