Php View Laravel Package

Product Decisions This Supports

• Build vs. buy, resolved cheaply. The entire renderer is a few hundred lines of ob_start()/include glue. "Adopting" it is a composer require, not a vendor commitment — treat it as a decision not to build a rendering layer, and not to take on Twig's dependency surface either.
• Feature scoping for server-rendered surfaces. Good fit for admin panels, internal tools, error pages, transactional email HTML, PDF/HTML exports, and prototype MVPs where the value is in the data, not the markup engine.
• Framework-fit decisions. It is the default renderer in the Slim 4 skeleton, so for a Slim service the integration cost is near zero. For a Laravel codebase, this is a downgrade — Blade already ships with auto-escaping, components, and slots; do not introduce a second, weaker renderer. Release 3.4.0 does not change this: PSR-7 message-version compatibility is irrelevant to a Laravel app, which never enters this renderer's request/response path.
• Architecture reversibility. It binds to ViewRendererInterface + PSR-7 responses, so the blast radius of a later migration to Twig or Plates is confined to template syntax, not application code. That makes it a legitimate "start simple, upgrade if needed" bet.
• Install-surface risk, now reduced. 3.4.0 widens the constraint to psr/http-message ^1.0 || ^2.0. Previously, any project already pinned to PSR-7 v2 (current Slim 4 installs, many PSR-7 implementations) could not install this without a Composer conflict. That blocker is gone, which strengthens rather than weakens the "smallest dependency surface" argument — the one hard constraint it imposes is now satisfied by both major PSR-7 lines.
• Performance and ops budgeting. Plain PHP templates are opcache-friendly and effectively the fastest option available; if render latency or cold-start matters, this is the floor, not a compromise.
• Roadmap signal. A thin renderer keeps the door open for adding a JSON/API-first surface later without stranding a templating investment.

When to Consider This Package

Adopt when:

• You are on Slim 3/4 or any PSR-7 project, PHP 7.4+/8.x. As of 3.4.0, this includes projects pinned to psr/http-message 2.0 — no conflict, no override, no --ignore-platform-req hack.
• The team writes PHP comfortably and there is no designer/marketer editing templates directly.
• Template count is modest (roughly under 20–50) and churn is low; layouts are simple header/footer wrappers.
• You want the smallest possible dependency and supply-chain surface — one package versus Twig's transitive tree.
• You need speed and predictability over templating ergonomics.

Look elsewhere when:

• Auto-escaping is a compliance or security requirement. There is no default escaping here; every output is <?= $var ?> unless you discipline yourself. Twig auto-escapes; this does not. 3.4.0 does not touch this.
• You need template inheritance, blocks, macros, filters, or i18n-aware formatting — Twig, Blade, Plates, or Latte will save more time than they cost.
• Templates are authored or influenced by untrusted users — you need a sandboxed engine (Twig's sandbox extension), not arbitrary PHP execution.
• You are already inside Laravel or full-stack Symfony; use the native engine and avoid a second mental model.
• You require a vendor SLA or long-term support contract. Release cadence is low, maintainership is narrow, and the listed dependent count is effectively nil. 3.4.0 is a maintenance release, not a roadmap signal: a one-line widening of an existing dependency constraint, no new features, no deprecations, no breaking changes. Read it as "the project is alive and receiving compatibility patches," not "this is being actively developed." The mitigating factor remains that the code is small enough to vendor or fork in an afternoon — budget for that possibility rather than assuming active upstream stewardship.
• You need a component library or design-system primitives shared across teams.

Upgrade note: 3.4.0 is non-breaking and safe to take on a patch bump; the only effective change is that Composer will now resolve against psr/http-message 2.x where it previously could not. No template or application code changes are implied.

How to Pitch It (Stakeholders)

To executives: This is a free, MIT-licensed, deliberately minimal view layer that is already the default in the standard Slim project skeleton. It costs nothing to adopt, adds almost no dependency or supply-chain risk, is the fastest rendering path available, and saves roughly a sprint of integration work versus standing up Twig. The recent 3.4.0 release is a small compatibility patch — it removes an installation conflict with the current generation of PSR-7 HTTP libraries — rather than new capability, so it changes our risk read only at the margin: the project is maintained enough to keep pace with its dependency ecosystem, which is exactly the level of stewardship a package this small needs. The trade-off is unchanged: safety comes from developer discipline rather than framework defaults, so we pair adoption with a mandatory escaping helper and a lint rule. If it is ever abandoned, the code is small enough that forking is a routine maintenance task, not a crisis.

To engineering: Plain .phtml templates rendered through output buffering, with a single layout applied by wrapping the inner template's output. Two non-negotiables: (1) every dynamic value goes through an e()/htmlspecialchars helper — there is no auto-escaping and no sandbox; (2) never let user input select the template name, since the renderer resolves paths by appending .phtml and checking the filesystem. Pin the version (3.4.0 is a safe patch bump and unblocks psr/http-message 2.x projects that previously could not install it), add a CI check that greps for unescaped short-echo tags, and keep business logic out of templates by pre-shaping view models in the controller. If the template count or the number of non-PHP authors grows past a threshold we set now, we migrate to Twig — the interface boundary makes that a contained change.