[6.x] Restore Raw blocks in blade nocache views - #15365
Conversation
|
Similar to how I would have done it! Looks reasonable |
| $rawBlocks = \Closure::bind(fn () => $this->rawBlocks, $compiler, BladeCompiler::class)(); | ||
|
|
||
| if (empty($rawBlocks)) { | ||
| return $compiled; | ||
| } |
There was a problem hiding this comment.
The PHP-vs-verbatim discriminator is a content-shape heuristic (str_starts_with($raw, '<?php') && str_ends_with($raw, '?>')), not a real type tag — Laravel's rawBlocks doesn't retain origin type. If a @verbatim block's trimmed content happens to itself be exactly <?php ... ?> (e.g. someone documenting Blade/PHP syntax verbatim), it will be misclassified as a passthrough PHP block and actually executed as PHP in the second compile pass instead of rendered as literal text. Narrow edge case, template-author-controlled content (not a remote-attacker vector), but it's a genuine logic bug in new code, not pre-existing. No test covers this collision case.
There was a problem hiding this comment.
A fix would mean shielding @php/@verbatim blocks inside statamic:nocache regions before Laravel's own storeUncompiledBlocks() runs which requires subclassing BladeCompiler and rebinding the blade.compiler container singleton so we can intercept ahead of parent::compileString().
Given it's template-author-controlled content and requires deliberately writing verbatim content that's byte-for-byte an empty PHP tag pair, could we document the limitation in a comment for now and come back to the bigger change if required down the line?
3 participants
Fixes #11987
Not sure if this is the right way @JohnathonKoster but Claude seems to think so.