I'm migrating documentation to Gitbook, but I'm unable to get the variables feature to render variable content in my pages.
The variables docs page indicates that variables are set in /book.json and that they are accessible through book.[CONFIGURATION_DATA]
The templatting docs page indicates this is done through a {{ varname }} construction.
However in my published Gitbook docs, I'm just getting literal {{ varname }} content in my output. This happens even when I update via the linked Git repo to ensure there is no escaping of the variable constructions.
I'm happy to use other approaches, e.g. liquid-style constructs with .yaml configs, but I'm unable to find any docs on other options either. As long as I can update those setting centrally, it will work for me.
Related
I would like to override a block from a twig template from a plugin in my own plugin.
I have overridden native shopware templates in the past, but I have troubles with plugin templates.
The plugin I am trying to adjust is FroshProductCompare and I am also using FroshDevelopmentHelper to easily retrieve the template I am trying to adjust.
Via the development helper, I found out that the template is located at
vendor/store.shopware.com/froshproductcompare/src/Resources/views/storefront/component/compare/section/overview.html.twig
So I created the file at
custom/plugins/ExamplePlugin/Resources/views/storefront/component/compare/section/overview.html.twig
and added
{% sw_extends "#FroshProductCompare/storefront/component/compare/section/overview.html.twig" %}
to the first line of the file.
I have also tried
{% sw_extends "#Storefront/storefront/component/compare/section/overview.html.twig" %}
I have built the storefront and cleared the cache multiple times and I have also reinstalled the plugins in different orders without success.
I found similar questions, which are not the same.
E.G. How to do a template multiple inheritance in Shopware 6?
But the difference here is, that the block is not native to shopware and is created by the plugin.
Any ideas?
The issue is most likely due to plugin load order.
tl;dr: Older plugins (based on installation date) take precedence over newer plugins. But if you want to make sure your plugins take precedence defined the load order in your theme.
It starts with finding the right template in \Shopware\Core\Framework\Adapter\Twig\TemplateFinder::find you can see a queue is build based \Shopware\Core\Framework\Adapter\Twig\TemplateFinder::getNamespaceHierarchy which in turn gets it from \Shopware\Core\Framework\Adapter\Twig\NamespaceHierarchy\NamespaceHierarchyBuilder. The method return the first found template to the order is the key.
The NamespaceHierarchyBuilder is tagged with shopware.twig.hierarchy_builder which is used to inject the following builders:
Shopware\Core\Framework\Adapter\Twig\NamespaceHierarchy\BundleHierarchyBuilder with priority 1000
Shopware\Storefront\Theme\Twig\ThemeNamespaceHierarchyBuilder with priority 500
Since you want to overwrite a template from a plugin with a plugin BundleHierarchyBuilder is the interesting one (all plugins are simply symfony bundles).
BundleHierarchyBuilder is getting the bundles from the kernel (\Shopware\Core\Kernel). The kernel registers the bundles in \Shopware\Core\Kernel::registerBundles and uses an instance of \Shopware\Core\Framework\Plugin\KernelPluginLoader\KernelPluginLoader to load the plugins. The used instance is \Shopware\Core\Framework\Plugin\KernelPluginLoader\DbalKernelPluginLoader as you can see in \Shopware\Core\HttpKernel::createPluginLoader.
As described in this answer DbalKernelPluginLoader loads the plugins based on the installation date. So plugins with an older installation date will be higher up in the list in the TemplateFinder and their template will be returned.
I would actually recommend you this solution: Define the load order in your own theme.
I've recently started making a website using the X-Cart platform.
I've read some of pages from the official documentation, but a lot of things do not match the current version of X-Cart (5.3).
From what I understand, they switched from Smarty to Twig, but the file locations and hierarchy have changed as well. Even the database structure is modified and old tables don't have the same names.
I'm currently trying to entirely replace the header / footer of my website. The HTML files are included in lists and displayed with twig, but I don't know how to find those specific files.
Also, I've used the Webmaster Kit add-on in order to find the templates. The problem is that every single element displayed on the page is built from multiple places. Most of them can be found in /customer/layout/, but are part of lists such as layout.header, so the twig files only include the wrappers and retrieve the rest of the code from the database, at least that's my understanding of the situation.
{##
# Header logo
#
# #ListChild (list="layout.header", weight="100")
#}
<div id="{{ this.getUniqueId('logo') }}" class="company-logo">
<img src="{{ this.getLogo() }}" alt="{{ t('Home') }}" />
</div>
I tried accessing layout.header through my database, but the table shown in the documentation doesn't exist anymore.
Could someone please explain the hierarchy and guide me through the steps to create a custom header / footer ?
I did create my costum module, but I still don't know which files are the right to edit in order to make changes happen on my website.
Thank you, let me know if you need additional details.
The header section is defined by the skins/customer/layout/header/main.header.twig template or you can just assign all needed templates to layout.header view list and it will have the same effect. You may also want to remove existing templates and viewer classes from this list.
All these procedures are explained here:
http://devs.x-cart.com/en/getting_started/step_2_-_applying_design_changes.html
http://devs.x-cart.com/en/design_changes/basic_guide_to_theme_creation.html
If you want to look up what templates and viewer classes are in the list, then you can run following MySQL query:
SELECT * FROM xc_view_lists WHERE list="layout.header";
As for footer, the layout.footer defines this area or just override the skins/customer/layout/footer/main.footer.twigtemplate.
Hope, it helps.
Tony
I'm trying to setup a site using Wintersmith as a static site generator in Node.js. By default, articles written in markdown to be published as content in the site use a short heading section to specify some of the metadata about the article that can be used in a Jade template, for example. These attributes are grouped between two markdown horizontal rule elements (---):
---
title: README
author: the-wintersmith
date: 2013-04-30
template: article.jade
---
Welcome to your new blog!
...
Out of the box, this works fine and I can do things like parse the date object, or include the author of the article, etc. But I want to also add a parameter called "thumb" that would point to an image file to use as a thumbnail for the post. But simply adding the parameter above and trying to store it doesn't work and it won't be accessible that way.
I've seen lots of people using Wintersmith where they include additional metadata parameters, but none that seem to specify how they accomplish it.
How do you add additional metadata parameters for use in your Wintersmith templates?
I think you're looking for the page.metadata object.
test.md
---
foo: bar
template: test.html
---
...
test.jade
h1=page.metadata.foo
Any idea about How can I pass hidden values between 2 expression engine templates?
I don't want to use PHP code, is there any plugin or module?
Thanks
Highly recommend using Session Variables.
On your first page:
{exp:session_variables:set name="talking" value="nonsense"}
On your second page:
{exp:session_variables:get name="talking"}
Then you can always delete it afterwards:
{exp:session_variables:delete name="talking"}
If you want to deal with POST variables and set it on the first page via a form submission, then you can get it easily with Mo' Variables:
{post:talking}
What you may be looking for is an add-on called Stash . I think that would do exactly what you need!
I know this sounds crazy, but I need to show some post information outside of the loop in the expression engine channel module. Is this possible?
You could use EE's SQL Query template tags (if you know, or have access to the database table names and know what to look for in the database):
http://expressionengine.com/user_guide/modules/query/index.html
Basically, you'd output only what you need - it doesn't have to belong to a channel, or anything specific. The one kicker is that you'd have to know the basics of SQL syntax, but if you have a small working knowledge of it, you can do tons of additional things with it.
If you're not keen on SQL, you could simply embed a template within the template that you're working on. Here's a simple example that assumes you're editing the index and meta templates inside of a template group called 'news':
index template contents:
{exp:channel:entries channel="news"}
<div class="entry">
<h1>{title}</h1>
<div class="content">{body}</div>
{embed="news/meta" this_entry_id="{entry_id}"}
</div>
{/exp:channel:entries}
meta template contents:
{exp:channel:entries channel="news" dynamic="no" limit="1" entry_id="{embed:this_entry_id}"}
<div class="meta">
<p>{entry_date}</p>
<p>{author}</p>
</div>
{/exp:channel:entries}
As you can see, the index template is embedding the meta template. Note that we're passing a parameter to the meta template so that it knows which entry ID to print information about. If you're unfamiliar with EE's template embedding feature, you can read more about it in the EE docs. Embedding templates in other templates is a great way to access the {exp:channel:entries} loop multiple times.
There's an add-on called MX Jumper that allows you to "set" a variable from inside your entries loop and then "get" it elsewhere in the template (before or after in the HTML loop doesn't matter because it parses later).
Alternatively, the approach that's all the rage now is to use the add-on Stash to store any and all elements you need to use distinctly as stash variables that you set and then get - similar to the above, except that once you set them, getting them has to happen at a later parsing stage. The beauty of this approach is stash will store the "set" variables for reuse either at a user or site level, and you can determine what the expiry period is - which then results in better performance. When you apply this broadly using the "template partials" mindset, you can store everything with stash, and then call them into a small number of wrapper templates. This makes it possible to use stash to set, for example, your entry title, then get it three separate times in the wrapper template without any additional load - no need for separate loops within your template - one loop to set the variable, and then you can call that variable as needed in your template - it's kind of like creating global variables on the fly.
I would also suggest looking at Stash.