Weave Code
Templates System Bundle Laravel Package
swp/templates-system-bundle
Symfony bundle for managing reusable templates and layouts. Provides a central template registry, theme and layout resolution, and rendering helpers so applications can compose views consistently across modules without duplicating markup.
[READ-ONLY] Subtree split of the Superdesk Web Publisher Templates System Bundle
Frequently asked questions about Templates System Bundle
- Can I install swp/templates-system-bundle in a Laravel application?
- No. swp/templates-system-bundle is a Symfony bundle, not a Laravel package. It ships a Bundle subclass, DependencyInjection extensions with compiler passes, tagged services, Doctrine YAML/XML mappings, and Symfony event subscribers, none of which Laravel can load. There is no service provider handshake that makes composer require work, and Composer will hard-conflict on symfony/framework-bundle, symfony/event-dispatcher, and twig/twig against Laravel 9 or later.
- Which Laravel and PHP versions does swp/templates-system-bundle support?
- None. The package was last released on 2018-06-08 and targets roughly Symfony 3.4/4.x, Twig 1.x/2.x, PHP 7.1-7.2, and Doctrine pre-DBAL 3. Laravel 9+ requires Symfony 6/7 components, so the dependency graph is mutually exclusive. Even on a standalone Symfony install, running it on a current LTS is a fork-and-modernize job rather than a version bump.
- Is swp/templates-system-bundle still maintained?
- Effectively no. It is a read-only subtree split of the Superdesk Web Publisher Templates System Bundle with zero stars, zero dependents, and no release since 2018. There is no community to surface bugs, no security backports, and no evidence of production use outside Superdesk Web Publisher itself. If you adopt it, you own the fork and the patch SLA for Twig and Doctrine CVEs.
- What does swp/templates-system-bundle actually do?
- It provides a central template registry plus theme and layout resolution for Symfony applications. Templates are Twig source persisted in the database and rendered through a custom Twig loader instead of the filesystem. Containers hold ordered, addressable widgets as the unit of page composition, widgets are configured instances rendered into containers, and template assignments bind templates to routes, targets, or positions so editors can change layout without a deploy.
- Is this bundle the same as using Twig inside Laravel?
- No. Twig itself works in Laravel through packages like twigbridge, but this bundle's database-backed loader replaces the view resolution layer rather than extending it. It collides with Laravel's ViewFinderInterface, so you would be swapping out Laravel's view finder, not adding a template engine. The portable part is the domain model, not the integration code.
- What are the security risks of database-stored Twig templates?
- Editor-supplied Twig source executes with full Twig capability unless the sandbox extension is configured correctly, which makes it a stored-XSS and potentially remote-code-execution surface. Twig 3 also changed escaping and deprecation semantics, so an old bundle's assumptions may not hold. That is a security review you inherit rather than defer upstream, and you should decide explicitly who signs off on enabling and tuning the sandbox.
- How do I implement editor-managed layouts in Laravel without this bundle?
- The pragmatic path is to copy the schema and reimplement the model in Eloquent with Blade components or Twig. Templates, containers, widgets, and template_assignments are stable concepts worth copying verbatim, including ordering and cache TTL semantics. A thin equivalent typically takes three to five sprints, versus six to ten for a full port, and avoids carrying an abandoned Symfony dependency.
- What is the effort to port the template, container, and widget model to Laravel?
- Roughly six to ten sprints for a faithful port to Eloquent plus Twig or Blade, depending on how much of the assignment and context resolution you need. A reference-only rebuild of a thin equivalent is closer to three to five sprints and is the recommended default. Running it as an isolated Symfony sidecar behind an HTTP render API is two to three sprints plus ongoing ops, and only makes sense if publishing is a core domain.
- Can I use swp/templates-system-bundle as a sidecar service instead of integrating it?
- Yes, that is one of the few viable paths. You run it as an isolated Symfony service exposing an HTTP render API and let your Laravel app call it, which contains the dependency conflict and the upgrade burden to one service. The cost is two to three sprints of integration plus permanent operational overhead for a component with no upstream maintenance.
- What are the best alternatives to swp/templates-system-bundle for a Laravel CMS?
- For most Laravel applications, Blade components backed by a views or layouts table cover the same editorial requirement at materially lower cost. If you need Twig specifically, twigbridge plus your own database loader is a cleaner starting point than porting a Symfony bundle. Consider this bundle only as a reference implementation for the domain model, and only if the real requirement is editors authoring layouts at runtime rather than simply wanting Twig in Laravel.
Weaver
How can I help you explore Laravel packages today?