Templates System Laravel Package

Technical Evaluation

What the package actually is. swp/templates-system is the template/theme resolution layer extracted from Superdesk Web Publisher (SWP), a Symfony-based multi-tenant publishing platform. Its core job is the unglamorous but genuinely useful work of resolving which template renders for a given request: theme inheritance, fallback chains, overriding per tenant/site, and container-driven template lookup. That is a real problem in multi-tenant CMS work, and SWP solved it in production. The packaging, however, is a library — not a Laravel package. There is no service provider, no config publishing, no facade, and no Laravel-facing documentation. The task framing ("Laravel/PHP package") overstates the integration surface; expect to write the Laravel glue yourself.

Architecture fit. Fit is conditional and narrow. If the product requirement is multi-tenant, user-editable theming with deterministic override precedence, the concept maps well to a publishing/CMS workload. If the requirement is "render some templates," this is over-engineered relative to Blade or plain Twig. The library is designed around a PSR-11 container and Symfony-flavored conventions, so it will sit alongside Laravel's container rather than inside it — workable via a bridge, but every boundary (config, cache, filesystem, tenancy context) becomes an adapter you own.

Integration feasibility. Low as-is. Three concrete blockers: (1) the AGPL-3.0 license — network copyleft means offering source to users of a SaaS deployment, which is a legal/product decision, not an engineering one; (2) the last release is June 2018, so Composer constraints almost certainly cap PHP below 8.0 and conflict with Laravel 9/10/11; (3) zero dependents and three stars means no ecosystem, no forks of substance, no CVE watch, and no one to ask when it breaks. Any of these alone is manageable; together they describe a package you would vendor and own forever.

Technical risk. Highest risks, ranked: license contamination (AGPL in a commercial SaaS is a board-level conversation); abandonment (no security patch path — an SSTI or path-traversal finding in template resolution is yours to fix); PHP/Laravel version lock (forces a legacy runtime or a fork-and-modernize effort of unknown size); and template sandboxing. If templates are author-editable — which is the entire point of a "templates system for your templators" — then template evaluation is an untrusted-code execution surface, and the package predates most modern sandboxing guidance.

Key questions for diligence. What PHP and Symfony versions are pinned in composer.json? Which Symfony components does it hard-depend on, and are those constraints satisfiable alongside a current Laravel? How are templates stored — filesystem, DB, or both — and is there a compiled-template cache with correct invalidation on theme change? Is template evaluation sandboxed, and against what threat model? Is the upstream repo archived, and is there a maintained fork (SWP itself, or a Sourcefabric successor)? Does our distribution model trigger AGPL §13, and has legal signed off? Finally: what does this library give us that ~200 lines of Blade/Twig theme-resolution logic would not?

Integration Approach

Stack fit. Poor out of the box, moderate with deliberate effort. The mismatch is idiomatic: Symfony bundle/service-definition conventions versus Laravel's container, package discovery, and config publishing. The realistic integration is a thin Laravel service provider that binds the library's container contracts to Laravel's container, plus adapters for config, cache, and template storage. That adapter layer is the actual project — estimate it in weeks, not days, and staff it with someone comfortable reading vendor source.

Migration path. Do not plan a migration onto this package. Plan a spike that treats it as a reference implementation: stand it up in an isolated PHP 7.4 container, read the resolution and fallback logic, and extract the design. If the resolution semantics are genuinely subtle (theme inheritance across tenants usually is), reimplement them against Blade or twig/twig in a codebase you control. If they are not subtle, you have saved yourself a permanent fork. Either way, the deliverable of the spike is a decision memo, not a dependency.

Compatibility. Assume incompatibility until proven otherwise. Verification steps: composer why-not against the target PHP and Laravel versions; inspect composer.json for symfony/* pins that collide with Laravel's own Symfony dependencies (a common and painful conflict, since Laravel ships many of the same components at different major versions); check for use of removed PHP functions and dynamic properties if targeting PHP 8.2+. A legacy PHP 7.4 sidecar service is technically possible but operationally indefensible for new work.

Sequencing. Two-week timeboxed spike. Week one: install in isolation, map the public API, document template resolution order, and confirm licensing posture with legal. Week two: prototype the resolver semantics in-house against the current stack and compare effort. Gate at the end of week two with three outcomes — adopt-and-fork, reimplement-inspired, or reject outright. Default expectation: reimplement-inspired. Do not let the spike bleed into a production commitment without the license answer in hand.

Operational Impact

Maintenance. You will own this code. No upstream releases since 2018 means no bug fixes, no PHP-version compatibility work, and no security patches — every future PHP or Laravel upgrade is a manual port. Budget for a pinned dependency, a lockfile you are afraid to touch, and a named owner. A fork adds real cost: divergence tracking, internal release process, and the AGPL obligation to publish modifications if the service is network-accessible.

Support. Effectively none. Three stars and zero dependents means no community, no issue triage, no Stack Overflow corpus. The escalation path is "read the source." Vendor support does not exist in any contractual sense, and the upstream project's current status should be confirmed rather than assumed. For a system on the critical rendering path of a publishing product, that is a material support gap that should be recorded as accepted risk or designed around.

Scaling. Template rendering sits on the hottest path in a CMS — every page view. Three things need answers before any load commitment: whether compiled templates are cached and where (local disk versus shared cache matters for horizontal scale), how cache invalidation works when a tenant edits a theme (stale-render bugs are the classic failure here), and whether per-tenant template isolation is enforced at resolution time. None of these are documented at the level a capacity plan needs; each is a spike task.

Failure modes. Watch for: silent Composer resolution failure on the next framework upgrade; template resolution order producing wrong-tenant output under edge-case override chains (a correctness and data-isolation issue); server-side template injection if templates are author-editable without a sandbox; license exposure discovered late in a commercial deal; and plain abandonment — the package simply stops working on a future PHP and there is no one to call. The multi-tenant mis-resolution and the SSTI surface are the two that should keep a TPM up at night.

Ramp-up. The library's own API surface is likely small — a mid-level PHP developer should be productive in it within a few days. The real ramp is everything around it: container bridging, cache strategy, storage abstraction, and tenant context propagation, plus the organizational learning curve of "we now maintain a fork of an abandoned AGPL library." Plan for one to two weeks of focused engineer time to reach confident velocity, and treat that as a floor, not a ceiling.