Alexander Dimitrov

And then having two or more arguments to consider (command, chat, user) comes the headache of what has priority over what. It actually make more sense to have command settings...

Or Yet Another Maybe - to avoid having multiple key columns and arguments to the functions: Try to get "key.$command.$chat", if not found try "key.$command", if not "key". This can...

maybe also offer options only through func_get_args() so you do not expose the underlying format, like: ```php function optionGet() { $args = func_get_args(); // sql clean/escape this $where = [];...

An alternative is circling in my head, but I don't have a clear picture how I want it yet. Something like: 1. if there is an open conversation (as in...

@noplanman Not a totally different things if you start a conversation in a command and then send an inline keyboard, then in CallbackqueryCommand you could load the conversation, get the...

@noplanman If the conversation ended, then callbackquery command would not be able to determine the command and can fall back to a registered callback or do nothing. Or if callback_data...

The tricky part is in groups, genericmessage handling is just as tricky, the two (genericmessage and callbackquery) are essentially (almost) the same thing.

The idea about an ID is sort of special formatting, which is outside of any telegram api specs and should be left to the individual to decide. BUT, you as...

And I still think that along with callbacks and specials formatting/filtering, CallbackqueryCommand should also check for a conversation and execute the command that started it (like in GenericmessageCommand), maybe using...

My take on this: https://github.com/sharkydog/php-telegram-bot/blob/callbackquery/src/Commands/SystemCommands/CallbackqueryCommand.php Not tested and probably not finished yet. Edit: Now it's tested and works Edit: coupled with this trait to make it easier for commands ```php...