PSR-3 logging deprecation notice even without using logging

[laurinkeithdavis]

?	!
Operating system	Windows 10 x64 1809
PHP Telegram Bot version	0.59.0
PHP version	7.3.7
MySQL version	none
Update Method	Not used
Self-signed certificate	N/A
RAW update (if available)	>?

Summary

We upgraded from 0.56.0 to 0.59.0, which broke our implementation is now causing a deprecation notice even without using logging:

A PSR-3 compatible LoggerInterface object must be provided. Initialise with a preconfigured logger instance.

Previous behaviour

No errors.

How to reproduce

Send a message without logging configured.

Expected behaviour

Previously, logging configuration was not required and we don't care about logging anything have logging configured. More importantly, why was a BC breaking change implemented in a minor version?, so not sure why we are getting this notice.

[noplanman]

Hi @laurin1, thanks for reporting this!

It shouldn't be BC breaking, as only a deprecation warning is output.
I totally agree with you though, that having no logging enabled should never even touch that code, I'll get that fixed 🔨

Due to the nature of not being v1 yet, minor versions may contain bigger changes.

Sorry for any inconvenience this may have caused!

[noplanman]

@laurin1 Would you be able to test this fix please?
noplanman@5002857

[laurinkeithdavis]

Works.

[noplanman]

Ok, will release a new version tomorrow.

Did the script break for you with the deprecation messages or was it just the output that was bothersome?

[laurinkeithdavis]

It broke - the messages would not send.

[noplanman]

Right, must have to do with the PHP error reporting configuration of your install 🤔

Anyway, tomorrow you can fetch the new version with the fix 💪

[Alexfuse]

Same message
"Deprecated: A PSR-3 compatible LoggerInterface object must be provided. Initialise with a preconfigured logger instance. in ../vendor/longman/telegram-bot/src/TelegramLog.php on line 93
Telegram returned an invalid response!"
I try run set.php

[laurinkeithdavis]

Oh, I see what the problem is - it's throwing a E_USER_DEPRECATED (16384), not a E_DEPRECATED (8192) error. Apparently, when I wrote this portion of our error handler (years ago), I left off E_USER_DEPRECATED and so it was showing up as an "unknown" error type, which looked like an actual error, not a deprecation notice. I'll fix that now.

[laurinkeithdavis]

Not entirely accurate - very early in the morning here and not quite awake enough to process. :) Yes, we were not properly handing E_USER_DEPRECATED, but other than a couple of specific exceptions, I forgot that we consider deprecated to be an error (why wait to remove something until the last minute), so it would have failed for us anyway. However, that is our call and means the change was not BC breaking as I had originally thought.

[noplanman]

@Alexfuse That shouldn't have anything to do with this. It's probably a timeout that you are experiencing.

@laurin1 Ok, that makes sense now. Still thanks a lot for letting us know about this, because as you correctly pointed out, code that isn't used shouldn't be called! So this is definitely a good lesson for the future 🙏

[laurinkeithdavis]

Should we change the issue summary or leave it?