Since Laravel 5.7, the majority of global Helper functions (specifically the ones related with "Arrays & Objects" and "Strings") are now based on Facades (using Illuminate\Support\Str and Illuminate\Support\Arr classes) instead of being defined as "normal" helper functions, as they were before 5.7 (see difference with previous Laravel 5.6 docs).
Does it really mean that we are not allowed to use them anymore directly within our Blade views? If we do, they have to be obviously prefixed with its full path in any case, resulting in a dirtier Blade views...
Is not this change counter-productive?
EDIT:
Made some googling and found this article that confirms the situation.
Also, I have seen that in 5.8.17 it is planned to include Arr and Str aliases by default within config/app.php (link).
In the meanwhile, I proceed to register Arr and Str aliases in my config/app.php config file to avoid the full path issue.
Thanks
Related
Im using Laravel 7 so I didnt think this was going to be an issue.
Just a note on my installation, it was an upgrade from 5.3.
My issue is with a custom Blade directive I created.
It is aded additional quotes around the input
I added a dd() to see why my Helper didnt work.
My ServiceProvider
Blade::directive('setting', function ($expression) {
dd($expression);
return SettingHelper::value($expression);
});
View file
#setting('theme_public')
Output of dd()
"'theme_public'"
Expected output
'theme_public'
I dont know why the extra quotes are being added.
You are right, I get the same behavior with a fresh laravel 7 installation.
I created some little tests, to see what's going on. I think the behavior is best explained like this. Imagine you are calling a view with one variable:
return view('welcome', ['var' => "Hallo"]);
You have a custom blade directive like this:
Blade::directive('dirtest', function ($expression) {
dd($expression);
});
If you use that in your template the output is this:
#dirtest($var)
// output of dd in the browser:
"$var"
So it seems like the blade directives are just meant to replace some shorthand directive with more verbose php code. The actual code get's executed later in the blade templating engine. That makes sense, since blade templates are also cached for faster execution. In the cached version that custom directive is already embedded and your custom function doesn't get fired anymore. I hope that explanation makes sense to you.
What that means for you
It really depends on your use case. If you have a custom directive, that only gets passed constant strings, you could probably get away with just writing:
#setting(theme_public)
But if there's just a slight chance, that you might pass in a variable from time to time, like
#setting($theme)
You really have to return code, that utilizes that variable and can be evaluated later.
How would I override the View::make('cashier::receipt'); view so that when that particular namespace is called like that, it checks my folder first and then defaults back to the vendor path.
View::addNamespace('cashier', [
'/path/to/my/views', // check first
'/path/to/original/views' // check second
]);
I believe that's how Laravel handles custom views for packages already. https://laravel.com/docs/5.2/packages#views - see Overriding Package Views here.
Laravel registers two locations to load views so they can be easily customised, the standard vendor path and something customisable.
Laravel will first check if a custom version of the view has been provided by you, for example in
resources/views/vendor/cashier.
Let me know if there was something more specific you were trying to achieve but I believe the info there will get you going.
Where can I find the default blade directives folder?
I was looking for the #forelse to take as example, but I couldn't find it.
Does anyone know where they are defined in Lumen/Laravel?
note: I'm using Lumen framework, but I think it's quite similar to Laravel in this question, so I'm tagging both.
EDIT:
Due to the imprecision, I'll explain better my intention.
Basically, I'm creating a directive exactly the same as #forelse, but with 2 or 3 further information.
For that reason, I came to ask about the location since I haven't found by myself.
They're defined in the Illuminate\View\Compilers namespace in the BladeCompiler.
See Illuminate/View/Compilers/BladeCompiler.php
Specifically you'll need the compileForelse method if that's the one you want as an example.
To extend a blade template you have to write
#extends('folder.template_name')
This works for standard installation.
I've created a module for the backend and now I can't use my module template because Laravel catches the first record and that is the standard view folder.
My structure looks like this:
app
-- modules
-- modules\backend
-- modules\backend\views
-- modules\backend\views\layouts\master.blade.php
-- views
-- views\layouts\master.blade.php
So when I'm in the backend and try to display my template:
// app\modules\backend\views\page\index.blade.php
#extends('layouts.master')
Laravel renders the app\views\layouts\master.blade.php instead of
app\modules\backend\views\layouts\master.blade.php
I've tried many names inside that #extends e.g.
#extends('app\modules\backend\views\layouts\master')
#extends('app.modules.backend.views.layouts.master')
#extends(base_path(). '\app\modules\backend\views\\' . 'layouts.master')
Nothing works.
While using a package or autoloaded module, referring to it's resources is done using the double colon notation. In your case, to access the module's master template you need to use
#extends('backend::layouts.master')
These conventions are described in the docs, for further info please refer to
Laravel 4 package conventions
Make sure /app/config/view.php has a path entry for where those views are located.
I.E.
'paths' => array(__DIR__.'/../views'),
To
'paths' => array(
__DIR__.'/../views',
__DIR__.'/../modules/backend/views'
),
or whatever represents your actual path.
From here you might want to look into doing the view folder loading via another mechanism if your views are in dynamically generated folders. Maybe a module::boot event that adds the module path to the view paths array? Just an idea.
Every time a tpl file is included the system first looks for a site-specific version of the file and falls back to a standard one if the site specific one does not exist. So perahps I put include "customer/main/test1.tpl". If our site is google, the system would first look for "customer/main/google_test1.tpl" and fall back to "customer/main/test1.tpl" if that file doesn't exist.
Note: Smarty 2.6.x
Did you know about the built-in template directory cascade? addTemplateDir and setTemplateDir allow you to specify multiple directories:
$smarty->setTemplateDir(array(
'google' => 'my-templates/google/',
'default' => 'my-templates/default/',
));
$smarty->display('foobar.tpl');
Smarty will first try to find my-templates/google/foobar.tpl, if not found try my-templates/default/foobar.tpl. Using this, you can build a complete templating cascade.
That won't be too helpful if you have lots of elements on the same cascade-level. Say you had specific templates for google, yahoo and bing besides your default.tpl. A solution could involve the default template handler function. Whenever Smarty comes across a template it can't find, this callback is executed as a measure of last resort. It allows you to specify a template file (or template resource) to use as a fallback.
So you could {include}, {extend}, ->fetch(), ->display() site_google.tpl. If the file exists, everything is fine. If it doesn't, your callback could replace _google with _default to fallback to the default template.
If neither template_dir cascade nor default template handler function seems applicable, you'll want to dig into custom template resources.