Templates System Laravel Package

Getting Started

The package is a Symfony-oriented Twig templating layer (swp/templates-system) rather than a Laravel-specific package; treat this as "integrate a framework-agnostic component", not "drop in a facade".

composer require swp/templates-system

Immediately after install, do three checks before writing code:

1. Dependency resolution. The last tagged release is from 2018-06-11. It will almost certainly want older Symfony components (symfony/twig-bridge, doctrine/*). Run composer why-not swp/templates-system and expect conflicts with Laravel 9+/Symfony 5+. Expect to either pin older versions in an isolated service, or to vendor-fork it.
2. License. It is AGPL-3.0. If the app is exposed over a network to third parties, the AGPL network clause applies. Confirm with legal before building on it — this alone disqualifies most SaaS products.
3. What it actually is. It is a CMS templating layer: templates are typically stored as records (not just files), and Twig gets a custom extension that lets template authors fetch content (gimme style tags) from a context. That is the real value — editors manage templates and pull content without PHP code.

Read src/ in this order:

• the Gimme / context component — the Twig extension and content fetchers
• the loader/resolution classes — how a template name resolves to a source
• the Template model — what metadata is stored (name, type, source, version)
• any *Bundle directory — this is the Symfony wiring you'll have to port to a Laravel service provider

First use case: store a template inside the admin, attach a template_name to a content record, and render it through a Twig environment that has the package's loader and extensions registered, returning HTML from a controller.

// provider boot — class names approximate; verify against src/
$this->app->singleton(\Twig\Environment::class, fn ($app) => new \Twig\Environment(
    $app->make(\Twig\Loader\LoaderInterface::class),
    ['cache' => storage_path('framework/twig'), 'debug' => config('app.debug')]
));

Implementation Patterns

• Wrap it in a service provider. php artisan make:provider TemplatesSystemServiceProvider. Bind the Twig Environment, LoaderInterface, and the Gimme context as singletons. Laravel's container is close enough to Symfony's that you can hand-translate the bundle's XML/YAML service definitions rather than registering the bundle.
• Template resolution as a chain. Register a DB loader first (for templates editors may override), then a filesystem loader as fallback. A ChainLoader-style class implementing Twig\Loader\LoaderInterface is the cleanest seam; it also makes ArrayLoader-backed tests trivial.
• Route → template mapping. Implement middleware that inspects the route and attaches a template_name attribute; controller resolves it via a TemplateRenderer service. Keeps Twig out of controllers.
• Persist templates in Eloquent. Model: name, source, type, cache_version, tenant_id. Bump cache_version on save and invalidate Twig's cache for that name.
• Gimme tags for content. Templates fetch content via the package's custom Twig nodes. Bind a request context (tenant, locale, "published only") before rendering so fetchers scope correctly. Wrap the context in a DTO (e.g., TemplateContext) so fetch behavior is testable without HTTP.
• Twig + Blade coexistence. Use Twig strictly for CMS-managed theme templates and Blade for app UI. Don't attempt to merge them; share the cache strategy (clear both in one deploy command) instead.
• Pre-warm on deploy. Add an artisan command that resolves and compiles all active templates; run after deploy to avoid cold-start latency on first requests.

Gotchas and Tips

• Abandoned upstream. 3 stars, 0 dependents, last release 2018. Treat it as a vendor fork: pin an exact tag/commit, copy into packages/, and own the tests. Do not expect fixes.
• AGPL-3.0 is copyleft. Review before adoption; see above.
• Symfony assumptions. It expects Symfony DI, event dispatcher, and Twig-Bridge conventions. You will adapt, not "install", in Laravel. Budget time for this.
• Twig cache staleness. This is the #1 "my template change didn't show" bug. Set a real cache dir (storage/framework/twig) and invalidate on template save; Environment::load() respects isFresh, so a version bump on the source is the simplest fix.
• Loader order matters. Filesystem loaders shadow DB loaders if registered first. Register the override-able (DB) loader first.
• Debug mode. In dev, construct the environment with debug: true and strict_variables: true; missing context variables will then fail loudly instead of rendering blanks.
• Escaping audit. Fetch results rendered through the custom extension can bypass auto-escaping depending on how they're emitted. Verify output of user-authored templates before trusting it.
• Extension points. The context/fetcher registration is where you'll plug tenant scoping, publication status, and localization — plan custom logic there rather than patching the core.
• Cache the resolved template per route. Resolve the Template record once per route and store it in Redis; re-resolving on every request is the main performance cost.