Open shanginn opened 8 years ago
Just popping in to give a bit more detail on this issue.
It seems the cause is that laravel-haml
uses its own BladeCompiler
instance. So when you call Blade::directory(...)
, you are registering the directive for Laravel's built in compiler, rather than the compiler that laravel-haml
is using.
Perhaps laravel-haml
can override this facade so that directive
calls get routed the appropriate caller? Or provide its own facade for easier directive registration? Although the latter won't be compatible if you are including a plugin/package that wants to register its own directives.
For now, this is how I've worked around the issue. In my AppServiceProvider
(or whichever provider is registering a directive):
public function boot()
{
$blade = $this->app['view.engine.resolver']->resolve('haml.blade')->getCompiler();
$blade->directive('run', function () {
return "<?php $expression; ?>";
});
}
This will register the directive with the compiler used by laravel-haml
. So no need to stick anything in __construct
.
Cannot use @scraton solution for Laravel 5.4. Engine haml.blade not found.
When you registen new Blade directive in AppServiceProvier, for example @run
It's not accesable by
HamlBladeCompiler
class, because inBladeCompiler
variable, that keep all registered directives,$customDirectives
is protected. I was unable to solve this by myself. So for time I used workaround and hardcoded this directive in__construct
method: