Blade — Optional PHP-less Mode and Core Filters

[osama300]

we need an optional PHP-less mode for Blade templates (sandbox-like, similar to Twig) and provide a small set of core filters for common transformations.

# RFC: Blade — PHP-less mode + Core Filters

## Summary


## Problem
- Blade templates compile directly to PHP. This allows `@php`, `<?php ... ?>`, and `{!! !!}`. While powerful, it is unsafe for use cases like multiple themes or third-party templates.  
- Blade lacks a simple filter DSL (`{{ var|upper }}`) like Twig. Developers must call PHP helpers manually, reducing readability.

## Proposed Solution

### 1. PHP-less Mode
A new config option in `config/view.php`:

```
php
'blade' => [
    'allow_php'        => false,  // disables @php and <?php ... ?>
    'forbid_raw_echo'  => true,   // disables {!! !!}
    'strict_variables' => true,   // throw if variable is not defined
    'filters' => [
        'enable_core' => true,
    ],
],
```


When `allow_php` is false:

* `@php`, `<?php ... ?>`, and `<?= ... ?>` are forbidden.
* `{!! !!}` is forbidden if `forbid_raw_echo` is true.
* Accessing an undefined variable throws an exception if `strict_variables` is true.

### 2. Core Filters

Introduce a minimal set of built-in filters with Twig-like syntax:

```blade
<h1>{{ $title | upper }}</h1>
<p>{{ $username | lower }}</p>
<time datetime="{{ $created_at | date('c') }}">
  {{ $created_at | date('Y-m-d') }}
</time>
```

Suggested core filters:

* `upper`, `lower`, `title`, `trim`
* `date(format='Y-m-d')`

Chained filters should be supported:

```blade
{{ $name | trim | upper }}
```

## Example Usage

```blade
{{-- Safe filters --}}
{{ $post->title | upper }}
{{ $user->created_at | date('Y-m-d') }}

{{-- These will throw if PHP-less mode is enabled --}}
{{-- @php($x = 1) --}}
{{-- {!! $rawHtml !!} --}}
```

## Backwards Compatibility

* All new options default to current behavior.
* Existing projects are unaffected unless they enable PHP-less mode or core filters.

## Benefits

* Safer use of Blade in theming or third-party template scenarios.
* Cleaner, more expressive syntax for common transformations.
* Brings Blade closer in ergonomics to Twig without breaking existing apps.

[robert-moore96]

i feel like there are 3 separate ideas here without any real link between them

• being able to prevent use of raw php in a template

while i get why that may be wanted, it is virtually impossible to implement in practice without a complete redesign of how templates work which would break all existing ones and have significantly less capability overall than blade currently has

just disabling the @php blocks would have code style/linter level effects, it would not provide any security benefit at all and potentially gives people a false sense of security leading to them being less careful and in turn lbeing less secure

you can put arbritrary php in almost any blade tag, not just the @php ones. getting RCE via developers making mistakes with templating engines is its own class of vulnerability (SSTI), and this is just developers making mistakes, accepting code from a malicious 3rd party you have basically no chance

to actually have a template engine which is safe from that perspective, it needs to handle the data fetching itself rather than just being a wrapper around whatever underlying language is being used

eg i write something like <p>Hello {{ auth.user.name }}</p> and the templating tool itself parses that and gets the name property of the user property of auth, with all of those things being explicitly defined as being safe to use in templates

imo there is a place for a templating engine like that, for CMS' / user provided templates. but i dont think trying to turn blade into that is something that would go well or should even be attempted tbh (imo such a template engine needs to be built from the ground up to work like that, not starting with 1 that allows full language support and trying to convert it)

• disabling {!! !!}

tbh this has similar issues, maybe that would prevent mistakes by inexperienced developers, but it would have no effect on the safety of accepting code from a malicious developer,

• filters syntax / preset filters

i do like the idea of those, but one of the big features in php 8.5 is the pipe operator which is basically that, so other than making sure the framework is compatible with php 8.5 in general, i dont think that is a specific feature that needs adding to blade, i think we will just be able to use the pipe operator

[osama300]

Sorry if my initial proposal was unclear 🙏
And thank you @robert-moore96 for the detailed explanation.

For me, the most important point is the idea of providing a sandbox-like mode in Blade (similar to Twig).

I’m currently working on a SaaS e-commerce platform where I need:

• Multiple themes support
• An external SDK for theme developers

In this scenario:

• Blade already integrates deeply with Laravel and Livewire,
• While Twig doesn’t fit as smoothly into the Laravel ecosystem.

My concern is:

• Why should Blade remain limited in this area?
• Livewire had to create Blaze,
• Filament had to move away from Blade in some parts.

At the same time, modern trends like Server-Driven UI and the rising demand for SaaS applications make the need for a safer, more flexible templating system even more relevant.

I might not fully understand all the internal complexities, but I wonder:
👉 Why not raise the level of Blade, even if that means a more fundamental rewrite?
I believe this could make Laravel much stronger in the UI space, and directly benefit SaaS software and libraries like Livewire or Filament.

[robert-moore96]

the main point is that a templating engine that can safely process user submitted templates without giving code execution is fundamentally different to a templating engine that just overlays the underlying programming language with some nicer syntax

1 is not superior in general to the other, they are different tools for different jobs.

if anything the one that overlays the programming language has potential for far more useful features and is likely going to be much nicer to use for regular web apps where the developer is writing their own templates

trying to turn 1 into the other is asking for failure, certainly going from having full language support and trying to lock that down to make it safe

the suggestions you gave of disabling certain tags from blade have absolutely no effect on a malicious developer being able to run arbitrary PHP or JS code in a template.
they only make it look to a beginner that it is more secure, which means they will be less careful and therefore less secure.

if you write {{ ... some code }}, blade doesnt actually parse/execute the ... some code, it just replaces {{ with <?= e( and the }} with ) ?>, you can write whatever code you want in there as long as it is valid PHP, (and if you want the page to return successfully it needs to return a string or certain other specific types that e can handle)

this will never be safe for user submitted stuff, but is a huge part of what makes blade so good