Weave Code
Drupal8 Bundle Laravel Package
theodo/drupal8-bundle
Symfony bundle for using Drupal 8 as a headless CMS. It provides configurable services around Drupal’s REST API, helping Symfony apps authenticate and fetch Drupal entities and content without custom integration code. Useful for decoupled projects pairing Drupal content management with a Symfony fro...
At a glance
Frequently asked questions about Drupal8 Bundle
- Can I install theodo/drupal8-bundle in a Laravel application?
- No. This is a Symfony full-stack bundle, not a Laravel package. It registers through AppKernel or bundles.php and depends on Symfony's kernel and container lifecycle, which Laravel does not provide. Laravel consumes Symfony components but has no bundle registry, so there is no supported way to install or register it.
- Does theodo/drupal8-bundle support Laravel 9, 10, or 11?
- It does not support any Laravel version. The bundle targets Symfony 2.3 through 3.x and PHP 7.x, while Laravel 9 and later run on Symfony 6 components. Its Symfony-era contracts will not resolve, and there is no bundle system to hang it from in Laravel.
- What does theodo/drupal8-bundle actually do?
- It is a Symfony bundle for using Drupal 8 as a headless CMS. It provides configurable services around Drupal's REST API so a Symfony app can authenticate and fetch Drupal entities and content without writing custom integration code. It also boots a Drupal 8 kernel inside a Symfony request, which is why it is tightly coupled to Symfony.
- Is theodo/drupal8-bundle still maintained?
- There is no evidence of active maintenance, and you should assume it is abandoned. Drupal 8 lost security coverage in November 2021, and the bundle targets Symfony 2.3-3.x and PHP 7.x, all unsupported. Adoption is also weak: roughly 33 stars, zero dependents, and a single-vendor origin, which reads as a proof of concept.
- What Drupal and PHP versions does theodo/drupal8-bundle require?
- The bundle is built for Drupal 8 and PHP 7.x, paired with Symfony 2.3 through 3.x. All of those are end-of-life and no longer receive security patches. Do not treat it as a supported path for new Drupal 10 or 11 projects.
- What license does theodo/drupal8-bundle use, and is it safe for a commercial SaaS?
- It is GPL-2.0, which is expected because kernel-level Drupal integration inherits Drupal's copyleft. That copyleft is a hard blocker for proprietary distribution and needs legal sign-off before any design work. The SaaS-only case is the tolerable one, but you should still confirm your posture with legal.
- How do I use Drupal as a headless CMS with a Laravel frontend instead?
- Reimplement the pattern idiomatically rather than installing the bundle. Run Drupal as an isolated, containerized service with its own deploy, no shared process, and network restrictions, exposing rendered markup or JSON:API. Then add a Laravel middleware or controller layer that fetches, caches in Redis with tag-based invalidation, and composes content into Blade views. Keep a route-level fallback proxying unmatched paths to Drupal until each route is migrated.
- Can I reuse the strangler-fig pattern from this bundle to migrate off Drupal incrementally?
- Yes, the concept is genuinely reusable even though the code is not. The repository is a worked example of keeping Drupal live while a Symfony or Laravel app takes over routes incrementally. In Laravel, proxy unmatched paths to Drupal through middleware or a controller, then flip each route to native Laravel rendering behind a feature flag. Budget a parallel-run period with read-through validation before decommissioning Drupal.
- What alternatives should I evaluate for decoupled Drupal in Laravel?
- Start with Drupal's native JSON:API or GraphQL, which already satisfy most headless requirements at far lower risk and cost. A small Laravel HTTP client service with caching and a fallback proxy covers the rest without co-hosting two frameworks. If the estate is genuinely Symfony 3.x or 4.x, you could evaluate the bundle directly, but the end-of-life exposure remains. For new work, target a supported Drupal 10 or 11 behind a versioned API boundary.
- What should I check before investing engineering time in this package?
- Run a short checklist first: PHP version ceiling, Drupal core version, Symfony version, licensing posture, and whether your team can legally and practically own a fork. Also confirm whether the business driver is migrating off Drupal or embedding Drupal content in an existing Laravel app. Most of these checks fail for a greenfield Laravel project, which is exactly why you run them before any engineering time.
Weaver
How can I help you explore Laravel packages today?