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
Related
I am trying to implement custom demo data that is generated once the plugin is activated (similar to the Shopware plugin SwagPlatformDemoData). Part of this demo data are generated CMS pages, although I cannot find any documentation online outlining different methods of generating these pages. The only reference I could find was the 'startseite' cms page generated within the SwagPlatformDemoData plugin (which generates a image on a full-width section, whereas I need to generate text in a main section and a sidebar)
Where would I find documentation for this so that I can implement this further?
I suggest you take a look at the DemodataCommand. It utilizes the DemodataService which uses entity specific generators, implementations of DemodataGeneratorInterface, e.g. the CustomerGenerator. You can register your own generator by tagging it accordingly:
<service id="MyPlugin\Core\Framework\Demodata\Generator\CmsPageGenerator">
<!-- all the services you need -->
<tag name="shopware.demodata_generator" option-name="cms-pages" option-default="60"/>
</service>
Then you should be able to just replicate what the DemotdataCommand does, calling the DemodataService to create data using your own generator.
Regarding the creation of fleshed out CMS pages with random content you may want to look at the CreatePageCommand which creates pages that are to some degree randomized.
You can create a lifecycle and define what need to be installed/removed when (de)activating the plugin. Documentation can be found here: https://developer.shopware.com/docs/guides/plugins/plugins/plugin-fundamentals/plugin-lifecycle#overview
After you've created the lifecycle, you need to create a function and add your content to $this->cmsPageRepository->create($cmsPage, $context);
You can use the structure explained in this documentation: https://developer.shopware.com/docs/concepts/commerce/core/shopping-experiences-cms#structure
I want to define a new template called "product".
This template calls an external service and retrieves the information about that specific product. That is easily done with a custom plugin that access the product information. Information on how to do that has been found here.
However, I would like that the URL of the page would be something like:
/product/<id>/<seo-friendly-description>
So I can retrieve in the Twig template both <id> and <seo-friendly-description> which will be used later to retrieve the specific product information.
I have tried to find something that could help in the documentation, without success. Could someone either point me to the right doc section or highlight the basic steps that shall be achieved so I can start solving this issue?
Just in case it helps, I am trying to find something similar to how bottle or other web frameworks work:
#route('/hello/<name>')
def greet(name):
return 'Hello ' + name
I've been building a family recipebook into my own website and I've been working through a similar problem. I haven't quite worked out all the kinks, but my solution is mostly working if you want to checkout my github repo.
In short, you need the plugin to watch what the active route is. If the route matches, you then create the page and populate it using your plugin data.
I haven't quite figured out how to get the active page to highlight in the navigation menu for generated pages, but you might still find this solution helpful.
tl;dr
Within OrchardCMS, is there any way to automatically migrate the contents of a BodyPart into a LayoutPart? And if so, how?
Detail
I am upgrading an old Orchard instance (v1.8.x) that used the old BodyPart. The goal is to update OrchardCMS to the current release, and with it, migrate to the new Layout system added in v1.9. Enabling the Layout module will add the LayoutPart to content items such as Page, but the two parts both exist on the Content Definition, and moving content from the BodyPart to the LayoutPart seems to be a manual process. Is there any way to automatically migrate content from the BodyPart to the LayoutPart, perhaps even if it was nested within a single Grid->Row->Column(12)->HTML block? And if so, how?
I think you should be able to do this with a little bit of playing around and a little bit of find & replace in your code editor. I would take an empty new site and export two pages, one with content in the BodyPart and one with content in the LayoutPart they way you want it to look. You should be able to see how they are different, I haven't looked at how they export recently, but I think the body part html is contained in a pretty simple xml tag while the layout part includes some code to designate all the elements, with the html contained inside.
Next step is to export all the content from your site (using import/export) and use a good text editor to convert all the body parts into layout parts using find & Replace.
Finally, import the edited file back into the site.
I haven't tried any of this so obviously have a database backup handy and test this out in a dev environment first. Also, I'm guessing that if you follow the directions above you will end up with duplicate content in the body and layout, so you probably want to make sure your import has an empty body tag for each page.
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 understand how the use of the stash plugin will affect the URls of my site.
The traditional way:
I have a template group called site. Within the TG site I have the templates articles, about_us, etc.
The URl will for a single entry be
www.mysite.com/index.php/site/articles/title_of_respective_article
URL for the About-us-page:
www.mysite.com/index.php/site/about_us
Both will reflect the template_group/template structure and thus be SEO-friendly and give users a hint where they are on the site.
But when I use stash I will have 2 wrappers (one for the homepage and one for the rest of the site.
Partials will be used for header, main content and footer.
As far as I understand it, I´ll use the template_groups layout for the wrappers and partials for the main content.
The templating look like
Two wrappers build the TG "layout" Both are hidden, since they should´nt be called directly.
layout
.homepage
.site
Three partials in the TG partials
partials
header
main_content
footer
And by the way shouldn´t those not also be hidden, since they aren´t complete HTML-pages either.
This is what confuses me. How do I get my nice URLs back?
A URL like
www.mysite.com/index.php/site/about_us
will not match the TG/T concept anymore.
Any help?
To expand on both their answers above, and just to be specific to your www.mysite.com/index.php/site/about_us request:
You'd create a template group called "site" and then you may alternatively have something like this code in the /index template
{embed="layout/.site"}
{exp:channel:entries limit="1" disable="categories|member_data|pagination"}
{exp:stash:set name='title'}{title}{/exp:stash:set}
{exp:stash:set name='maincontent'}
<section>
<h1>{title}</h1>
<article>{content}</article>
</section
{/exp:stash:set}
{/exp:channel:entries}
The embed calls the .site layout and the interior simply pulls your specific channel:entries data.
As you can see, it's still using the traditional templategroup/template ways of building URLs, it's just pulling data differently.
When using Stash and the template partials approach (which I don't use personally), the files you mention are all embedded. You still use the same template groups and template files as before.
The Stash-based approach is simply a different way of doing things within your existing templates - not a replacement for them.
Exactly as Derek says. The way to think about it is this - with the template partials approach, your templates contain mostly (if not only) the entries logic (channel entries loop, its parameters, what custom fields are in play for that channel, etc). The outcome of the logic gets stores as stash variables. The stash variables then get called upon by your embedded layout templates to display the content you've stashed. So your URL structure remains the same, but you have considerably less duplication of effort since the more you constrain your templates to logic (i.e. very little if any formatting/display markup) the cleaner they are and the easier it then is to manage your templates.