- Does php-tmdb/symfony work with Laravel?
- No. php-tmdb/symfony is a Symfony bundle that registers services in a Symfony dependency-injection container, so its wiring is dead weight in a Laravel application. For Laravel you should depend on php-tmdb/api directly, or use a plain PSR-18 or Guzzle client, and bind it in Laravel's own service container. The bundle adds no domain logic beyond configuration and service registration, so nothing is lost by skipping it.
- How do I install and configure php-tmdb/symfony?
- Run composer require php-tmdb/symfony and register the bundle in config/bundles.php for your environment. Then supply your TMDB API key through the bundle's configuration tree, typically reading it from an environment variable rather than committing it. Once configured you can inject the Tmdb\Client service into your own classes. A working spike against a single endpoint is roughly an afternoon of work.
- Which Symfony and PHP versions does php-tmdb/symfony support?
- The bundle targets Symfony 4, 5 and 6, and no Symfony 7 support is claimed. Symfony 6.0 through 6.3 are past end of life, so while the declared ^6.0 constraint may install on 6.4 LTS it is not tested against current patch releases. Always verify the PHP constraint and the Symfony range in composer.json rather than trusting the README, and check the Guzzle major version pinned by the underlying php-tmdb/api library.
- Is php-tmdb/symfony still maintained?
- Last release was March 2021, the repository has roughly 35 stars, and it is effectively a single-maintainer hobby project. There is no indication of ongoing maintenance or testing against recent Symfony or PHP releases. If you adopt it, budget explicitly for forking or replacing it, and compare that cost against writing a small in-house adapter of around 200 lines.
- What is the difference between php-tmdb/symfony and php-tmdb/api?
- php-tmdb/api is the actual client library that talks to The Movie Database endpoints. php-tmdb/symfony is only a bundle that registers that client as a Symfony service, exposes a configuration tree for the API key, and wires in an HTTP client and cache. The bundle contributes no domain logic of its own, so treat it as a swappable adapter rather than an architectural dependency.
- How do I fetch movies, TV shows, and people data with this bundle?
- Inject the Tmdb\Client service into your own class and call the relevant API accessors, such as the movies, TV, people, search, discover and images endpoints. The bundle only handles container wiring, so the available methods come from php-tmdb/api rather than from the bundle itself. Keep those calls inside a dedicated class so the rest of your code does not depend on the client's API surface.
- Does php-tmdb/symfony handle TMDB rate limits and 429 responses?
- No. TMDB enforces quotas, and the client wrapper will happily hand you back 429 responses without any built-in retry or backoff. You need to implement your own retry strategy with exponential backoff and avoid bursting requests across your catalog or import jobs. Caching is the most effective mitigation, and it is opt-in, so nothing is cached until you configure it.
- How do I configure caching for TMDB responses in this bundle?
- The bundle can wire in a cache, but it is opt-in, so if nobody configures it every request goes to the wire. Point the cache configuration at a PSR-6 or Symfony cache pool backed by something durable such as Redis or the filesystem. TMDB metadata changes slowly, so generous TTLs on title, credits, and image data cut both latency and quota consumption. Verify caching is actually active in staging before relying on it in production.
- Should I use the Tmdb\Client directly in my controllers and services?
- No. Define an internal port, for example a CatalogProvider interface that returns your own DTOs, and implement it with a class that delegates to Tmdb\Client. Never let Tmdb types leak into controllers, domain services, or serializers. Done this way, replacing the bundle with an in-house Guzzle or PSR-18 client later is a one-file change plus a dependency removal. Skipping this step turns a small dependency decision into a multi-sprint refactor.
- How do I test code that depends on php-tmdb/symfony?
- Because the bundle only wires container services, you can unit test by mocking or stubbing Tmdb\Client and injecting the double directly. If you wrapped it behind your own interface, mock that interface instead so tests never touch the network or the bundle. Use Symfony's container test helpers only for a thin integration test that asserts the service is registered and the API key is read from configuration. Keep endpoint-response mapping tested separately with recorded fixtures.