- How do I install and set up longman/telegram-bot in a Laravel application?
- Install it with Composer using the package name longman/telegram-bot, then write a thin adapter in your app that owns the Telegram instance, your bot token config, and the webhook route. Point a POST route at the package, pass the raw JSON body into Request::fromJson(), dispatch with Telegram::run(), and return a 200 response. A working echo bot is roughly an afternoon of work. There is no publishable config or service provider, so all of that setup code becomes yours to maintain.
- Is there a Laravel service provider or facade for longman/telegram-bot?
- No. The package is framework-agnostic and ships no first-party Laravel service provider, facade, or publishable config file. Integration means writing an adapter in app/ that manages the Telegram instance, configuration, and routing yourself. That is acceptable for most projects, but it is code you own rather than something upstream maintains.
- Does longman/telegram-bot support Laravel 11, Laravel 12, and PHP 8.2, 8.3, or 8.4?
- The package is framework-agnostic, so Laravel version support mostly comes down to PHP constraints rather than Laravel internals. Before committing, check the package's PHP requirement against your runtime (8.2, 8.3, 8.4) and confirm its Guzzle dependency resolves cleanly alongside the version Laravel ships. If you need newer Bot API features, validate coverage against the pinned release rather than the README.
- Should I use webhooks or polling with longman/telegram-bot in Laravel?
- Webhooks fit Laravel's request/response hosting model much better: route a POST endpoint, hand the JSON to Request::fromJson(), dispatch, and return 200 quickly. Polling via getUpdates is supported but implies a supervised long-running worker or an artisan daemon, plus single-consumer-per-token semantics. For most Laravel deployments, webhook plus a queue for heavy work is the pragmatic choice.
- How do I define commands, inline keyboards, and conversations with longman/telegram-bot?
- Commands are classes extending Longman\TelegramBot\Commands\Command, organized into system, user, and admin namespaces with a static command registry handling routing. Inline keyboards, callback queries, payments, media, and multi-step conversations are all supported through the Bot API methods and helper objects. Because the registry is static, resolving Laravel services inside execute() usually means calling app() or overriding the command factory.
- Does longman/telegram-bot require a MySQL database?
- Not for core webhook handling. The bundled bot-manager and admin commands assume a MySQL schema, so conversation state and manager-style workflows should be treated as bring-your-own-persistence in a Laravel app. Prefer Eloquent or Redis over adopting the shipped schema. That keeps migrations, backups, and multi-tenancy under your existing stack conventions.
- Is longman/telegram-bot safe to use with Laravel Octane or Swoole?
- Treat it with caution. The package leans on static and global state such as Telegram:: setters, a static command registry, and static Request/Response helpers, which is fine for classic PHP-FPM lifecycles. Under Octane or Swoole those statics can leak between requests, so you should test explicitly and reset state between jobs. It is a genuine, testable risk rather than a theoretical one.
- How do I test a Telegram bot built with longman/telegram-bot?
- Keep your adapter thin so command logic stays unit-testable without hitting Telegram's servers. Mock the Guzzle-backed HTTP layer or inject fake responses, and feed canned update payloads into Request::fromJson() to exercise routing. For integration tests, hit your webhook route with sample updates and assert on the outgoing request bodies. Isolating static state between tests is the main friction point.
- Is longman/telegram-bot still maintained, and what are the alternatives?
- It has one primary maintainer and the last tagged release was 2024-06-10, so budget for the possibility of self-patching against Telegram Bot API changes. The MIT license means forking is viable. If container DI, facades, and queued jobs are priorities, irazasyed/telegram-bot-sdk is materially more Laravel-native. Note also that the package has around 4k stars but very few Packagist dependents, which suggests most users run it as a standalone app rather than a library.
- How do I handle webhook retries, duplicate update_id values, and 429 rate limits with longman/telegram-bot?
- Those concerns are not solved at the application level by the package, so design them yourself. Acknowledge fast with a 200 and push heavy work to a Laravel queue, then deduplicate on update_id to make processing idempotent against Telegram retries. Honor 429 retry_after backoff on outgoing calls and account for out-of-order update delivery in your state handling.