Weave Code
Wistia Bundle Laravel Package
markup/wistia-bundle
Symfony bundle for integrating Wistia video hosting into your application, offering Twig helpers and services to embed Wistia videos and configure player options with minimal setup.
A Symfony2 Bundle for communicating with the Wistia Data API
Frequently asked questions about Wistia Bundle
- Can I install markup/wistia-bundle in a Laravel application with Composer?
- It is technically a Composer package, but it is a Symfony2 bundle built around a DependencyInjection extension, a Configuration tree, and a services.xml container graph that Laravel does not understand. Installing it should be assumed to fail or, worse, succeed and pull in pinned Symfony2-era constraints. Even if it loads, you would only reach its services through framework glue that no Laravel developer wants to maintain. The realistic recommendation is not to install it.
- What is the best way to integrate Wistia into Laravel if this bundle is not usable?
- Treat the bundle as a reference specification for the Wistia Data API, not as a runtime dependency. Build a single WistiaClient class behind a WistiaClientInterface contract using Laravel's Http facade, with typed DTOs for Project and Media, explicit pagination, retry-with-backoff on 429 and 5xx responses, and a cached project list. Expose it through a small service provider and a config/wistia.php file fed by environment variables. That reproduces the bundle's useful surface in a fraction of the time it takes to adapt it.
- Which Laravel and PHP versions does markup/wistia-bundle support?
- None officially, because the package targets Symfony2, which reached end of life in 2018. Its dependency constraints, PSR compliance, and PHP version compatibility are all suspect against a modern Laravel stack. Before considering it at all, you would need to audit every transitive dependency against your required Laravel and PHP versions. In practice, that audit is more work than writing the thin client yourself.
- Is markup/wistia-bundle actively maintained and safe for production?
- There is no meaningful adoption signal: roughly 2 stars and 0 dependents, which means no production evidence and nobody to catch a regression. That is a supply-chain gate failure under most sane dependency policies. The MIT license removes the legal obstacle but not the maintenance one. The real risk is not that the package breaks, it is that you own it forever for no benefit over owning your own thin client.
- What features does the Wistia bundle actually provide?
- It bundles configurable Wistia API credentials and video options, Twig helpers for rendering embeds, and service-based access to video metadata through native Symfony dependency injection. The useful client surface is small, along the lines of getProjects, getMedias, getMedia by hashed ID, and possibly upload. There is no evidence of Laravel-specific features such as Blade directives, package discovery, or config publishing.
- Do the Twig helpers in this bundle work in Laravel Blade templates?
- No. The embed helpers are Twig extensions registered through the Symfony bundle's service container, and Laravel does not ship Twig by default. Porting them means writing a Blade component or directive that outputs the same Wistia embed markup and player options. That is trivial compared with adapting the rest of the bundle.
- How should I store and configure Wistia API credentials in Laravel?
- Follow the bundle's one genuinely good idea, which is keeping credentials in configuration rather than scattered through code, but implement it the Laravel way. Put the API key in config/wistia.php reading from an environment variable, and never hardcode it in services or controllers. Then bind the client as a singleton in a service provider so the key is resolved once. If you have credential-handling or media-retention obligations, confirm where the key is allowed to live before building.
- What Wistia Data API endpoints does a Laravel client need to cover?
- For a read-only v1, the core surface is listing projects, listing medias within a project, and fetching a single media by its hashed ID, plus generating embed markup with player options. Upload, replace, delete, captions, and stats are separate scope and should not be bundled into the first release. Inventory exactly what the bundle calls by reading DependencyInjection/Configuration.php, Resources/config/services.xml, and the client class, then reproduce only that. Read-only is a fraction of the work and is the sensible default ask.
- How do I test a Wistia integration in a Laravel application?
- Because Wistia is an external HTTP service, use Http::fake to stub responses for projects, medias, and single-media lookups, and assert your DTO mapping and pagination behaviour. Add explicit tests for retry-with-backoff on 429 and 5xx responses and for cache hits on the project list. Keep the client behind an interface so the rest of the application can use a fake implementation in feature tests. None of this is possible with the original bundle, whose logic is welded to the Symfony container.
- What are the alternatives to using markup/wistia-bundle for video hosting in Laravel?
- You can keep Wistia and talk to its Data API directly from a small Laravel-native client, which is the lowest-effort path if Wistia is already the chosen platform. Longer term, define an exit path to Mux, Vimeo, or S3 behind the same WistiaClientInterface so the vendor can be swapped without touching application code. Note that Wistia Data API stats are media-level, so per-viewer attribution has to come from your own embed and tracking, not from the API. Do not let a video analytics requirement get scoped as an integration when the real work is on your side.
Weaver
How can I help you explore Laravel packages today?