Weave Code
Oembed Bundle Laravel Package
markup/oembed-bundle
Symfony bundle that adds oEmbed support, turning media URLs from providers like YouTube, Vimeo, and Twitter into ready-to-use embed HTML via configurable services and Twig helpers.
Bundle with a way of defining oEmbed providers, and rendering oEmbed in templates.
Frequently asked questions about Oembed Bundle
- Can I install markup/oembed-bundle in a Laravel application with Composer?
- In practice, no. markup/oembed-bundle is a Symfony 2.x bundle that pins symfony/framework-bundle and symfony/http-kernel to the 2.x line, which conflicts with the Symfony 6/7 components that Laravel 10 and 11 depend on, so composer require fails dependency resolution outright. Even if you force the install, the package expects a Symfony kernel, bundle registration, and a DI compiler pass that Laravel never boots. Treat it as a reference implementation and reimplement the oEmbed resolver in a small first-party Laravel package instead.
- What does markup/oembed-bundle actually do?
- It is a consumer-side oEmbed client: you give it a media URL from a supported provider such as YouTube, Vimeo, or Twitter, and it discovers the provider endpoint, makes the HTTP request, and parses the JSON response into structured data. That response exposes the ready-to-use embed HTML plus fields like type, title, and thumbnail. The framework plumbing (services, configuration, Twig helpers, routing) is most of the package, and the domain logic itself is only a few hundred lines.
- Does markup/oembed-bundle support Laravel 10 and 11, PHP 8, and current Symfony versions?
- No. The bundle targets Symfony 2.x, which reached end of life in November 2018, and its Composer constraints keep Symfony on the 2.x line. Symfony 2-era code also commonly trips PHP 8 removed or deprecated constructs, dynamic property deprecations, and old Twig and PHPUnit APIs. There is no shared abstraction layer you can reuse in a Laravel app, so Laravel version support is effectively not applicable.
- Is markup/oembed-bundle still maintained?
- There is no meaningful maintenance. The repository has around 3 stars and zero dependents, with no community and no security response path, and the last tagged release in January 2020 looks like a metadata bump rather than active work. For a package that performs outbound HTTP requests and renders third-party HTML, the absence of a disclosure process is a real risk. Plan on replacing it rather than waiting for fixes.
- What are the best alternatives to markup/oembed-bundle for oEmbed in Laravel?
- The pragmatic choice is embed/embed by Oscar Otero, which is PHP 8 compatible, PSR-4, actively maintained, and already handles provider discovery, endpoint requests, and HTML rendering, so it buys you most of the consumer surface for free. Wrap it behind your own interface, for example OEmbedResolver with a resolve(string $url): Embed method, so transport and provider logic stay swappable. If security review prefers no third-party fetch logic, hand-roll roughly 250 to 400 lines against an allowlist of 6 to 10 providers.
- How do I convert a YouTube or Vimeo URL into embed HTML in Laravel?
- Bind an OEmbedResolver implementation into the container, resolve the URL in a controller, service, or queued job, and hand the resulting embed HTML to a Blade component such as <x-oembed :url="$url" /> instead of the bundle's Twig helper. Cache the parsed response keyed by the normalized URL so repeat renders do not hit the network. Normalize privacy-enhanced domains like youtube-nocookie in your provider map, because that variation postdates the bundle.
- How do I configure oEmbed providers and restrict discovery to an allowlist?
- Map the bundle's YAML and XML configuration concepts into a config/oembed.php file holding providers, endpoints, cache TTL, and an allowed-provider list. Open discovery is convenient but lets user input reach arbitrary endpoints, so most product requirements are better served by an allowlist of the providers you actually support. Register each provider behind the same interface so adding a custom oEmbed provider is a config entry plus a small class, not a change to the resolver.
- Is it safe to fetch arbitrary third-party URLs for oEmbed?
- Not without guards, and a 2015-era bundle will not ship them. An oEmbed consumer fetches URLs supplied by users, which opens SSRF against internal metadata endpoints, unbounded redirects, XXE if XML responses are parsed with legacy loaders, and stored XSS if provider-supplied HTML is rendered unescaped. Block private and link-local IP ranges, cap redirects and response size, enforce timeouts, and sanitize or iframe-isolate the returned HTML before rendering.
- How do I cache oEmbed responses so pages stay fast?
- Cache the parsed response, not the raw HTTP body, keyed by the normalized URL plus provider, with a TTL that respects the provider's own cache hints. For request paths, prefer resolving asynchronously through a queue and storing the embed HTML on your media model so page renders never wait on a third-party call. Keep timeouts short and fail open to a link-only fallback when a provider is slow or unavailable.
- How do I test oEmbed resolution without calling real providers?
- Fake the HTTP layer, for example with Http::fake in Laravel or a mock PSR-18 client, and return recorded provider payloads so tests stay deterministic and offline. Cover the failure paths too: missing discovery link, non-200 responses, malformed JSON, timeouts, and blocked hosts. Because your resolver sits behind an interface, you can also swap in a stub implementation for feature and Blade tests that only care about rendered output.
Weaver
How can I help you explore Laravel packages today?