Liquid Laravel Package

Product Decisions This Supports

• Build vs. buy on a templating layer. If the roadmap includes any feature where customers author templates, this package turns a multi-week sandboxing project into a composer require. That is the central decision it informs: do we build a safe evaluation layer, adopt an existing engine, or defer the feature entirely?
• User-authored content surfaces. Notification/email templates, invoice and PDF layouts, CMS blocks, white-label theming, and merchant-configurable storefront fragments all need a renderer that is safe by construction — no eval, no arbitrary PHP. Liquid's constrained tag/filter model is the product-safety argument, not just a syntax preference.
• Which template dialect to standardize on. Liquid, Twig-with-sandbox, or a bespoke mini-language are three different product bets. Liquid buys familiarity for anyone coming from Shopify; Twig buys the largest PHP ecosystem and a mature sandbox. This package only makes sense if Liquid is the answer, so it forces that conversation early rather than after the editor UI ships.
• Shopify adjacency and migration. For a Shopify app or a Shopify-to-standalone migration, "can we render the merchant's existing templates as-is?" is a scoping question with a hard binary answer. A PHP Liquid implementation is the only path that avoids a Ruby sidecar — but see the parity caveat below.
• Extension surface as product surface. The tag/filter registration API is where we decide what customers can and cannot express. That boundary determines support load, documentation burden, and abuse surface — a PM-level decision this package exposes cleanly rather than hiding.
• Rendering architecture. PHP-native rendering means templates can run in queue workers and existing Laravel jobs. The alternative — shelling out to Ruby Liquid or calling a rendering service — adds an operational dependency and a latency floor to every template render.

When to Consider This Package

Adopt when all of the following hold:

• The product genuinely needs Liquid specifically — merchant familiarity, an existing template corpus, or Shopify compatibility — not just "some templating."
• The stack is PHP/Laravel and the team does not want a Ruby or Node rendering service in the critical path.
• Templates are tenant data, not code, and the security boundary matters enough that Blade is disqualified.
• The team accepts an early-adopter dependency: 21 stars, zero dependents, single-maintainer risk, MIT-licensed so forkable. Budget for a vendored fork and a compatibility test suite built from real customer templates.

Look elsewhere when:

• Twig fits. For a Symfony-influenced or general PHP shop, twig/twig plus its sandbox extension is the lower-risk default: larger ecosystem, more eyes on the sandbox, better tooling.
• You need Shopify-exact parity. Any PHP reimplementation will drift from the official Ruby Liquid spec at the edges. If "renders identically to Shopify" is a contractual promise, use the official implementation, not this.
• You need a vendor relationship. No commercial backing, no SLA, no security response process. If procurement or a security review requires a supported dependency, this fails that gate.
• Only developers write the templates. Then Blade is fine, the sandbox buys nothing, and the dependency is pure overhead.
• Render throughput is a first-class constraint. Interpreted Liquid in PHP will not match compiled Twig; benchmark against your volume before committing.

How to Pitch It (Stakeholders)

To executives: This lets us ship customer-editable templates — emails, invoices, storefront fragments — without standing up a new service or letting customers run code on our servers. The cost is one MIT-licensed Composer dependency instead of roughly four to six weeks of engineering to build and harden a sandboxed evaluation layer ourselves.

To engineering: PHP-native Liquid with clean tag/filter extension points, renderable from queue workers, no Ruby sidecar, no eval. Safe-by-construction for untrusted input. We control the exposed surface, which bounds the abuse and support footprint.

The honest risk paragraph: Adoption is essentially zero — 21 stars, no dependents, one maintainer. Treat it as an early-adopter dependency, not a foundation. Mitigations are cheap and should be committed up front: vendor or fork it, keep a regression suite of real Liquid templates, and pin the version. If those mitigations feel expensive, that is the signal to choose Twig's sandbox instead.