I'm trying to include many files to a blade file with dfr lang
#include("frontend.{$config->template}.privacy.Privacy-en")
#include("frontend.{$config->template}.privacy.Privacy-es")
#include("frontend.{$config->template}.privacy.Privacy-de")
.
.
.
I want one of these files to be imported according to the language chosen by the visitor
So I wrote this code as follows in page.blade.php
#include("frontend.{$config->template}.privacy.{'Privacy-' . LaravelLocalization::getCurrentLocale()}")
The error:
No hint path defined for [frontend.nova.privacy.{'Privacy-'. LaravelLocalization]. (View: C:\xampp\htdocs\templates\frontend\nova\page.blade.php)
any help will be highly appreciated.
Simple answer is don't do it this way. Laravel has built-in support for localisation, so there is no need to build different pages for each language and then jump through hoops - as you are trying to do - to try and incorporate the relevant one.
Read the documentation about localisation - in short, set up one blade template (called 'privacy.blade.php' for example) and within it use short keys such as :
{{ __('privacy.introduction') }}
and then define those keys within the relevant language files (so resources/lang/en/privacy.php, /fr/privacy.php, and so on) :
return [
'introduction' => 'The following statements set out our privacy information',
];
Related
We are using CAS to login to our Drupal instance. This is working correctly and displaying the correct user content (blocks etc. based on roles). What is not working correctly is the small snippet in the theme that says welcome . It keeps showing the previous user who logged in.
How do I set this in bigpipe?
The code looks like this in the theme: <span id="user_name">{{user.displayname}}</span>
Is there a way to tell bigpipe not to cache this?
This code snippet is on one of our twig files header.twig.html which is a partial.
I ended up putting this in a block, and just referencing the block section in the theme instead of just pulling that, then I used the block to be ignored for caching.
Thanks!
I used this post with other resources to solve a similar problem. We were including {{ user.displayname }} in a twig template for the header on all pages of our site. Some users were seeing other users' names in the header after signing in. We wanted to solve the problem while impacting caching as little as possible. Here, I share in detail what we did in the hope that it will help others. I'll use the specific names used in our code. Readers will need to adjust to their own names. (The code follows our prescribed format, so please forgive that it isn't standard.)
Step 1
Create a custom module. Custom module creation is covered adequately in other places, so I won't give details here. Our custom module is named rsc.
Step 2
Create the folder modules/custom/rsc/src/Plugin/Block and in it create a file named DisplayName.php.
Step 3
In the file DisplayName.php, include the following:
<?php
namespace Drupal\rsc\Plugin\Block;
use Drupal\Core\Block\BlockBase;
use Drupal\user\Entity\User;
/**
* A block to show the user's display name
*
* #Block(
* id = "display_name",
* admin_label = "Display Name"
* )
*/
class DisplayName extends BlockBase // The class name must match the filename
{
public function build()
{
$user = User::load(\Drupal::currentUser()->id());
return
[
'#type' => 'markup',
'#markup' => $user->getDisplayName(),
'#cache' => ['contexts' => ['user']]
];
}
}
Step 4
Clear the Drupal cache to make the new block available at Block Layout.
Step 5
Go to Admin > Structure > Block Layout and place the Display Name block in the Hidden Blocks For Referencing - Not Displayed section (bottom of the list on our site). In the Configure Block dialog, edit the Machine name to display_name to match id in the code above. Clear the Display title checkbox and save. Doing this makes the block available for use in twig templates.
Step 6
In the twig template for the header, replace
{{ user.displayname }}
with
{{ drupal_entity('block', 'display_name') }}
The drupal_entity function is part of the twig_tweak module, which we were already using. It allows insertion of a custom block into a twig template. If you're not using this module, you'll need to install it, or find another method of including a block in a twig template.
Step 7
Clear the Drupal cache to make the modified template take effect.
If you see anything about this that can be improved, please comment.
I want to add a new template option for the product filters block.
So far, I have copied the existing original.tpl from:
templates\blocks\product_filters
and put it into:
templates\addons\my_changes\blocks\product_filters
then I've renamed the file to: example.tpl and edited the top line of the file to be:
{** block-description:example **}
This basic process has worked for other blocks but not for this product filters one. The only options available in the template list are 'Original', and 'Horizontal filters'.
Is there something special I need to do to make my new template show up?
Templates available to be used by blocks are defined at schema, which is located at "app/schemas/block_manager/blocks.php" file.
Usually schema contains a path to a directory containing all templates that can be used by a block, like it's done for the "products" block:
'templates' => 'blocks/products',
Which makes block manager search templates at design/themes/[theme name]/templates/blocks/products directory.
Unfortunately, by some reasons the schema of the "product_filters" block is inconsistent compared to other block schemas - it contains the list of a concrete templates to be used:
'templates' => array(
'blocks/product_filters/original.tpl' => array(),
'blocks/product_filters/selected_filters.tpl' => array(),
'blocks/product_filters/horizontal_filters.tpl' => array(),
),
Because of that, no directory scan is being performed at a moment of determining a list of templates available for a block.
This is why the approach you're using worked for other blocks but not for "product_filters".
The solution for you is simple - you should create a "app/addons/my_changes/schemas/block_manager/blocks.post.php" file with the following content:
<?php
$schema['product_filters']['templates'] = 'blocks/product_filters';
return $schema;
After that please clear the cache and make sure that the "my_changes" add-on is installed and enabled.
Thanks for pointing out this problem, we'll fix it in an upcoming releases.
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.
I had previously added Joomla modules from within Joomla articles this way : {loadmodule mod_name} but this time I need to pass parameters from it.
How can I pass parameters from within the article to a Joomla module?
You'll need to modify or clone the Joomla plugin loadmodule because it doesn't handle parameters other than just a module name. It's not particularly difficult to do if you're proficient in PHP (assuming you don't mind getting your hands dirty with a little bit of Regex work) but I'd suggest cloning it and using it this way:
Copy folder \plugins\content\loadmodule to \plugins\content\Myloadmodule (and all it's files)
Within the new folder, rename loadmodule.php and loadmodule.xml to myloadmodule.php and myloadmodule.xml. These are the files you'll do all the work on.
In both files, replace occurrences of loadmodule with myloadmodule, (Case sensitive)
In myloadmodule.php, start at around line 36 with the Regex that strips out what is in the {loadposition xxx} being processed. You'll need to tinker with this Regex to get the parameters that you want to supply when using {myloadmoduel blah-blah-blah} in your article.
Find the database entry in your table '_extensions' for loadposition and create and identical record for myloadposition. (Unless you want to write and installer)
Finally, you'll need to render the modules with your new parameters - I can't begin to help there because I don't know what modules, or parameter work you'll be doing, but this renderModule documentation will be of assistance.
7.
I think I've covered it all, but this should be enough to get most of it done for you. When you're done, use {myloadposition ...} instead of {loadposition ...}.
I will give more details about the previous answer, to be able to pass parameters to a module with a tag as {loadmodule mod_name,param}
The solution given by GDP works fine: it's easy and quick to rewrite a content plugin (e.g. myloadmodule), following the steps 1 to 5 in the previous answer.
The problem, for me, comes with the steps 6: how to put parameters into the module, and ohow to retrieve de parameters within the module.
Step 7 : how to give parameters to the "render" of a module
In the plugin created (base on the loadmodule), you have to find the lines with the following code :
echo $renderer->render($module, $params);
Before this line, you can put parameters into the $params parameter, but "render" of the module retrieves only params with the key 'params', using a json format.
So, to pass parameters to the render function, you can do something like that :
$param = array('param_name' => 'value'); // param_name = value
$params = array('params' => json_encode($param)); // 'params' (String) should be decoded by the render of the module
echo $renderer->render($module, $params);
Step 8 : How to retrieve the parameter within the module
In the helper of your module, you can retrieve the parameter with $params variable :
$value = $params->get('param_name');
To understand a helper, read this tutorial : http://docs.joomla.org/J3.3:Creating_a_simple_module/Developing_a_Basic_Module
I googled the same issue and found your question. I know its old but my find may help someone else. There are now plugins that allow embedding modules and allowing you to pass parameters to it. My choice is Module Plant.
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.