You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
When implementing custom commands that share names with message types (e.g., LocationCommand and PollCommand), the fatal error appears "Cannot declare class ... because the name is already in use" error when processing messages of those types (e.g., when receiving a location or poll message). This appears to be due to different approaches in how the bot loads commands and handles message types, leading to duplicate class declarations.
Current behaviour
Custom commands like LocationCommand and PollCommand are created to handle /location and /poll commands.
These commands are properly registered and loaded by the bot.
When the bot receives a text "/command" everything works correct.
When the bot receives a location or poll message (as message content, not as a command), it attempts to process it by converting the message type to a command name (e.g., location becomes Location).
The bot checks if a command class exists for that message type using class_exists($class_name) without setting the $autoload parameter to false.
This triggers the autoloader, which tries to load the class again, resulting in a duplicate class declaration error:
Compile Error: Cannot declare class Longman\TelegramBot\Commands\UserCommands\LocationCommand, because the name is already in use
How to reproduce
Implement commands named LocationCommand and PollCommand to handle /location and /poll commands.
Send a Message of the Conflicting Type: Send a location or poll message to the bot (not as a command, but as regular message content).
Observe the Error: The bot throws a compile error about the class already being declared.
Expected behaviour
The bot should process location or poll messages without errors.
The existing LocationCommand or PollCommand should handle /location or /poll commands when they are explicitly invoked.
No duplicate class declaration errors should occur when processing messages that match command names.
Additional details
Different Loading Approaches:
The bot loads commands from the specified directory recursively, creating a mapping of command names from the command property of each class to the class itself.
When processing certain message types, the bot attempts to map the message type to a command by converting the message type string (e.g., location) to a class name (e.g., Location).
Issue with class_exists in getCommandClassName:
In Telegram.php, the bot uses class_exists($class_name) without the $autoload parameter set to false.
This causes the autoloader to attempt to load the class again, even if it's already been loaded, leading to a duplicate declaration error.
Possible solutions
3.1. Modify the class_exists Check:Change the class_exists function in Telegram.php to prevent autoloading
3.2. Adjust Command Name Resolution: Modify how the bot maps message types to command names to avoid conflicts with existing command classes. For instance, differentiate between commands and message types by using a different naming convention or adding a prefix/suffix.
Thank you. If any additional information is needed, please let me know.
The text was updated successfully, but these errors were encountered:
🐞 Bug Report
Required Information
{...}
Summary
When implementing custom commands that share names with message types (e.g., LocationCommand and PollCommand), the fatal error appears "Cannot declare class ... because the name is already in use" error when processing messages of those types (e.g., when receiving a location or poll message). This appears to be due to different approaches in how the bot loads commands and handles message types, leading to duplicate class declarations.
Current behaviour
Custom commands like LocationCommand and PollCommand are created to handle /location and /poll commands.
These commands are properly registered and loaded by the bot.
When the bot receives a text "/command" everything works correct.
When the bot receives a location or poll message (as message content, not as a command), it attempts to process it by converting the message type to a command name (e.g., location becomes Location).
The bot checks if a command class exists for that message type using class_exists($class_name) without setting the $autoload parameter to false.
This triggers the autoloader, which tries to load the class again, resulting in a duplicate class declaration error:
How to reproduce
Implement commands named LocationCommand and PollCommand to handle /location and /poll commands.
Send a Message of the Conflicting Type: Send a location or poll message to the bot (not as a command, but as regular message content).
Observe the Error: The bot throws a compile error about the class already being declared.
Expected behaviour
The bot should process location or poll messages without errors.
The existing LocationCommand or PollCommand should handle /location or /poll commands when they are explicitly invoked.
No duplicate class declaration errors should occur when processing messages that match command names.
Additional details
Different Loading Approaches:
The bot loads commands from the specified directory recursively, creating a mapping of command names from the command property of each class to the class itself.
When processing certain message types, the bot attempts to map the message type to a command by converting the message type string (e.g., location) to a class name (e.g., Location).
Issue with class_exists in getCommandClassName:
In Telegram.php, the bot uses class_exists($class_name) without the $autoload parameter set to false.
This causes the autoloader to attempt to load the class again, even if it's already been loaded, leading to a duplicate declaration error.
Possible solutions
3.1. Modify the class_exists Check:Change the class_exists function in Telegram.php to prevent autoloading
3.2. Adjust Command Name Resolution: Modify how the bot maps message types to command names to avoid conflicts with existing command classes. For instance, differentiate between commands and message types by using a different naming convention or adding a prefix/suffix.
Thank you. If any additional information is needed, please let me know.
The text was updated successfully, but these errors were encountered: