- What does radic/blade-extensions actually do?
- It is a thin compiler-extension layer that registers extra Blade directives on top of Laravel's view compiler. The headline features are a Twig-style @foreach with $loop metadata, @break and @continue, @set for inline variable assignment, a multiline @array directive, and view blocks/partials helpers. It ships no runtime services, database footprint, or request lifecycle impact, so adoption is low risk architecturally. The main caveat is that most of these directives now exist in core Blade.
- Which Laravel and PHP versions does radic/blade-extensions support?
- The package targets the Laravel 4.x through 5.x era, using a service provider on 5.x and a more invasive compiler override on 4.x. It likely predates PHP 8.x typing, so expect dependency-resolution dead ends on modern stacks. Pin your Composer constraint to your exact Laravel major instead of floating, and verify the illuminate/view and illuminate/support bounds before installing. Treat it as out of scope for Laravel 6 through 11.
- How do I install radic/blade-extensions in a Laravel app?
- Install it with Composer, then register the package service provider in your app configuration if auto-discovery is not supported by the version you pull. Publish the config file if you need directive aliasing or want to disable individual directives. After that, compiled views regenerate on the next render, or you can run php artisan view:clear to force it.
- Does radic/blade-extensions support Laravel package auto-discovery?
- Only newer tagged releases in the 5.x lineage are likely to include an extra block for auto-discovery. Older versions require manual provider registration in config/app.php. Check the installed package's composer.json for the laravel extra key before assuming discovery works. If you are on a pinned legacy version, plan for manual registration.
- Will radic/blade-extensions conflict with native Blade @foreach, @break and @continue?
- Yes, that is the most common failure mode. The package re-registers those directive names, which can shadow or collide with native Blade behavior and produce confusing, hard-to-debug output. Before installing, grep your templates and AppServiceProvider for any custom directives with the same names. On Laravel 5.3+ there is no reason to override them, since $loop, @break and @continue are built in.
- How do I replace @set and @array with native Blade?
- On Laravel 5.5+ the native @php and @endphp pair subsumes nearly every @set and @array use case, for example @php $items = [...]; @endphp. Inventory usages first by grepping for @set and @array, then rewrite each one and run view:clear so cached compiled templates are discarded. Run the app and check the affected pages before removing the package from Composer.
- Is radic/blade-extensions safe and maintained enough for production?
- It shows the profile of an effectively unmaintained package: low dependents, low activity, and no vendor to lean on for security patches. A templating extension that compiles strings is worth keeping patched, and there is no patch path here. Compile-time failures also surface at deploy time when the first uncached view renders, which raises the operational risk. For anything on Laravel 5.3 or newer, use native Blade instead.
- What are the alternatives to radic/blade-extensions?
- For Laravel 5.3+ the best alternative is core Blade itself: $loop metadata, native @break and @continue, @php and @endphp, and @json cover almost every feature this package offers. If you need genuinely custom syntax, write a small directive in a service provider using Blade::directive and keep it in your own codebase. That avoids an abandoned third-party dependency while giving you full control over upgrades.
- Why does my view fail to compile after installing radic/blade-extensions?
- Compilation errors usually mean the package's directive regex is clashing with native Blade or with another registered directive. Because Blade caches compiled views, a stale or partially compiled file can also be the cause, so run php artisan view:clear first. If the error persists, check whether your Laravel version already defines the directive you are using. On 5.4+ the native @break and @continue are the safer choice.
- Should I use radic/blade-extensions in a new Laravel 10 or 11 project?
- No. Every headline feature has been in core Blade for years, and the package's compiler hooks are not guaranteed against modern Blade internals. Adding it to a greenfield build means duplicate directive surface area and an unmaintained dependency you will have to remove later. The only rational use case is a legacy Laravel 4.x to 5.2 application where rewriting templates is expensive.