Kirby Blade Laravel Package

Technical Evaluation

Architecture fit. Despite the "Laravel/PHP package" framing, this is not a Laravel package — it is a Kirby CMS plugin that pulls in illuminate/view (Laravel's standalone Blade component) and swaps Kirby's native PHP-template rendering for Blade compilation. Fit is therefore conditional on one thing: whether we operate Kirby 4/5 sites. In a Laravel estate this has no application; in a Kirby estate it is a template-layer substitution that touches the render path for every page, not an additive library. The architectural consequence is a split-brain template model — Kirby's convention (site/templates/*.php, snippet(), controller) coexisting with Blade's (@extends, @include, @section) — which requires an explicit team convention or it becomes permanent inconsistency.

Integration feasibility. Composer-installable, MIT, small surface area, released as recently as 2025-06-18 against both Kirby 4 and 5. The mechanical install is trivial; the real integration work is validating that the override is non-destructive: does the plugin render Blade only when a .blade.php file is present, or does it intercept all template resolution? Does snippet() still work inside Blade views, and is @include mapped to Kirby snippets or to a separate view path? Are $page, $site, $kirby, $site->user() available in Blade scope with the same semantics? Does Kirby's html()/escaping helper and the translation function survive, or do we adopt {{ }} escaping wholesale? These are answerable in a one-day spike but must be answered before commitment.

Technical risk. High for the maturity profile. Twenty-two stars, zero dependents, and a single maintainer means effectively no production evidence and a bus factor of one. The dependency chain is the sharp edge: illuminate/view moves on Laravel's major cadence, Kirby moves on its own, and the plugin sits between them — every major on either side is a compatibility gamble with no vendor SLA behind it. Blade's compiled-view cache introduces a second cache layer with its own invalidation rules; stale compiled templates after deploy are the canonical failure mode. There is also a developer-safety risk: teams accustomed to Kirby's explicit html() escaping may reach for {!! !!} in Blade and introduce XSS by reflex.

Key questions. Is rendering opt-in per template, and can Blade and PHP templates coexist in one site? Which illuminate/view major is pinned, and what happens on a Kirby 6 or Laravel 12 bump? Where are compiled views written, and how are they cleared on deploy? Is the Panel, error pages, and multi-language routing unaffected? What is the maintainer's stated support window and response history on issues?

Integration Approach

Stack fit. Only pursue if we run Kirby 4/5 in production and have a concrete pain the swap solves — most plausibly a team already fluent in Blade/Laravel who find Kirby's snippet-and-controller idiom friction-heavy, or a portfolio of Laravel apps plus Kirby marketing sites where template-muscle-memory consolidation has real value. If the driver is purely "Blade is nicer," the cost/benefit does not clear the bar at this maturity level.

Migration path. Template-by-template, never big-bang. Stand up a non-production Kirby instance, install the plugin, and port a single low-traffic template (a legal page, then a content page) with the PHP original kept alongside as the rollback. Confirm coexistence behavior in that first step — if the plugin is all-or-nothing, the migration becomes a full-site rewrite and the risk profile changes materially. Only after several pages render byte-comparably against the originals do we touch shared layouts and partials.

Compatibility. Pin the plugin and illuminate/view to exact versions in composer.json and treat both as upgrade-gated dependencies requiring a render-regression pass. Verify PHP version parity with each Kirby target, and confirm the compiled-view directory sits outside version control and inside the deploy's writable path. Check that Kirby's cache and the Blade cache can be cleared together by a single deploy step, or the two will drift.

Sequencing. (1) Spike: one-day feasibility check in a scratch Kirby install, answering the key questions above. (2) Decision gate: if coexistence, escaping semantics, and cache behavior are all clean, proceed; otherwise stop cheaply. (3) Pilot: one low-risk site, 3–5 templates, side-by-side comparison, one full deploy cycle to shake out cache issues. (4) Codify conventions — escaping rules, where views live, helper usage — in a short internal guide before any second developer touches it. (5) Broaden only if the pilot produces zero render regressions and a developer reports net velocity gain.

Operational Impact

Maintenance. Modest but non-zero. We inherit ownership of the integration, not just the dependency: composer pins, cache-directory hygiene, and a regression check on every Kirby and PHP upgrade. Budget a recurring half-day per upgrade cycle rather than a one-time install cost. Because the plugin is small and readable, we can fork it if the maintainer goes quiet — that is the mitigation for the bus factor, and it should be an accepted contingency before adoption, not after.

Support. None contractual. MIT, single maintainer, minimal issue traffic given the star count — meaning few bugs are being found because few people are looking. Internal expertise must be the primary support channel; we cannot lean on upstream responsiveness for a production incident.

Scaling. Render throughput is not the concern — Blade compiles once and caches, and Kirby's flat-file model is the actual scaling boundary in either case. The scaling risk is organizational: every additional developer must learn the plugin's boundary rules, and every new template is a fork in the road between two idioms. On a single small site with one or two developers this is manageable; across many sites or a rotating team it accrues as cognitive overhead and inconsistency.

Failure modes. Ranked: (1) stale compiled views after deploy producing old markup or fatal errors — mitigate with an explicit cache-clear in the deploy pipeline and a smoke check on a rendered page; (2) dependency break on a Kirby or illuminate/view major bump — mitigate with pinned versions and a staging render test; (3) escaping regressions from unescaped Blade output — mitigate with a code-review rule banning {!! !!} absent justification; (4) abandoned upstream — mitigated by the fork contingency and the small codebase; (5) partial migration leaving a site permanently split across two template paradigms — mitigated by finishing or reverting each site deliberately.

Ramp-up. Low in absolute terms for anyone with Laravel experience — Blade syntax is familiar and the plugin config is small. The ramp is really about the boundary: which Kirby helpers remain idiomatic inside a Blade view, how snippets and controllers map, and where compiled views live. A one-page internal README plus the pilot site as a reference implementation should get a Laravel-fluent developer productive in a day. For a developer without Laravel exposure, the plugin adds a second framework's idioms on top of Kirby and is not worth the teaching cost at this adoption level.