- What is leitsch/kirby-blade and does it support Kirby 4 and Kirby 5?
- It is a Kirby CMS plugin that replaces Kirby's native PHP template renderer with Laravel's Blade engine by pulling in illuminate/view. It is Composer-installable, MIT licensed, and released in 2025 with support for both Kirby 4 and Kirby 5. It keeps Kirby's content model, pages, controllers, and blueprints intact while letting templates use Blade syntax, layouts, components, and directives.
- Is kirby-blade a Laravel package I can install in a Laravel application?
- No. Despite the Laravel-adjacent naming, this is a Kirby CMS plugin and not a Laravel package; the only Laravel component involved is illuminate/view, Laravel's standalone Blade compiler. It has no application in a pure Laravel estate. It only makes sense on a Kirby 4 or Kirby 5 site where you want to change the template layer.
- How do I install kirby-blade with Composer?
- Run composer require leitsch/kirby-blade in a Kirby 4 or Kirby 5 project; the plugin registers itself through Kirby's plugin loader. Pin the plugin and illuminate/view to exact versions in composer.json and treat both as upgrade-gated dependencies. Confirm PHP version parity with your Kirby target and run a render-regression pass whenever either side is bumped.
- Can Blade templates and Kirby PHP templates coexist in the same Kirby site?
- This is the first thing to validate in a spike: determine whether rendering is opt-in per template, meaning Blade is used only when a .blade.php file exists, or whether the plugin intercepts all template resolution. If it is all-or-nothing, migration becomes a full-site rewrite and the risk profile changes materially. Start with one low-traffic page, keep the original PHP template alongside as a rollback, and compare output before touching shared layouts and partials.
- Where are compiled Blade views stored and how do I clear the cache on deploy?
- Blade compiles templates to a cache directory, which adds a second cache layer alongside Kirby's own caching and has its own invalidation rules. Confirm the compiled-view path, keep it outside version control, and make sure it sits inside a writable directory in your deploy. Clear it as part of every deploy, since stale compiled templates after a release are the canonical Blade failure mode.
- Do Kirby's $page, $site, and $kirby variables, snippet(), and helpers work inside Blade views?
- Kirby's template variables should be available in Blade scope, but verify that $page, $site, $kirby, and $site->user() behave with identical semantics. Check whether snippet() still works inside Blade views and whether @include maps to Kirby snippets or to a separate view path. Also confirm that Kirby's html() escaping helper and translation function survive the swap before committing.
- Which illuminate/view version does kirby-blade pin, and what breaks on a Kirby or Laravel major bump?
- The plugin sits between illuminate/view, which follows Laravel's major release cadence, and Kirby, which follows its own. Every major on either side is a compatibility gamble with no vendor SLA behind it, so check which illuminate/view major is pinned before adopting. Pin both packages to exact versions and require a full render-regression pass on any upgrade.
- Is kirby-blade production ready, and how many stars and dependents does it have?
- It is a single-maintainer plugin with roughly twenty-two GitHub stars and zero dependents, so there is little public production evidence and a bus factor of one. That does not make it unusable, but it means your team owns the compatibility risk rather than a vendor. Review the maintainer's stated support window and issue response history before committing to it in production.
- How do I avoid XSS when using Blade's raw output syntax in Kirby templates?
- Blade escapes output inside double curly braces but renders raw HTML with the unescaped variant, and developers used to Kirby's explicit html() helper can reach for it by reflex. Set an explicit team convention that defaults to escaped output and requires review on every unescaped tag. Audit any user-supplied content before it is rendered raw.
- What are the alternatives to kirby-blade for Blade-style templating in Kirby?
- Kirby's native PHP templates with snippets and controllers are the default and carry no extra dependency risk, while Twig plugins offer a comparable compiled-template approach. The strongest case for kirby-blade is a team already fluent in Blade and Laravel that finds Kirby's snippet-and-controller idiom friction-heavy. If the only driver is that Blade feels nicer, the cost and risk at this maturity level do not clear the bar.