Render shortcode in front matter string

I am using the Sawmill and Forestry ‘blocks’ approach to building site pages from multiple page section blocks.

Some of the sections have a ‘content’ variable that is used to store the main chunk of text for that section of the page. This is different from the {{ .Content }} portion of text after the front matter of the .md file.

I can use the ‘markdownify’ function to render the ‘content’ that is written in Markdown. Headings, links, images work well and render correctly within that section. The problem that I face now, is that if I put a shortcode in that ‘content’ field, it passes through unprocessed.

For example, instead of a markdown img reference like:


I use a figure shortcode to add a caption:

{{< figure src="/someimage.jpg" caption="Amazing Image!" >}}

Then the shortcode text above is passed into the text as you see it here and does not render the figure. Same is true if I want a YouTube video, Tweet, etc.

Is there a way to process the ‘content’ string to render the shortcode?


I don’t think that’s possible. On the other side: everything you are using in front matter is somehow called in templates, so why not using what you would put into the shortcode in the template where it would be rendered?

Generally speaking you are 100% correct. But in this use case, I don’t know in advance where the content creator is going to want to add the shortcode item into the content string.
Imagine that instead of a single {{.Content}} on a page (which handles shortcodes perfectly), I have multiple ‘content’ variables for each section of a single page. I don’t know in advance for that page how many sections there will be and within that section’s content string that they are going to insert a shortcode.

Note, if I drop HTML into the ‘content’ string the HTML is rendered, so I could do something like go get the embed code from a YouTube video, convert all the double-quotes to single-quotes in the code and paste that where I want it in the string. It works ok, but it gets them away from writing content in Markdown and asks them to work with HTML code. This is asking more from my non-tech-savvy content editors than teaching them how to use Forestry Snippets for the shortcodes and just having them add the video ID for the YouTube video shortcode.

This is the point where you will have to show a sample repository that makes it clear what we are talking about. I am having issues understanding your “multiple .Content” approach because a “Page” can have only one single "Content’ variable. It’s probably just nomenclature, but what you are describing is not a principle that Hugo supports.

By the way: did you open a post on the support page of “Sawmill and Forestry”? This might be the better place, because THEY create this approach.

1 Like

Here is a demo site that uses this approach.

Here is an example file where you can see a ‘content’ variable for each ‘block’ in the page.

You can see here the layout file that checks each block to determine the proper partial to load.

Here is the partial that take the block’s ‘content’ parameter and runs it through markdownify.

There are small differences in what I am doing versus what you see in this demo, but the methodology is the exact same. You can see for yourself that if you add a shortcode to any of the ‘content’ variables in the front matter, the shortcode text will pass through without being rendered. I assume that markdownify function does not have a way to handle the shortcode.

I think this issue is specific to Hugo and how it processes strings from front matter in templates differently than it processes the text below the front matter section of the .md file. Which is why I posted here instead of opening a ticket with the developer of this technique of using data in front matter to build page content.

My hope is that the “markdownify” function will someday run the string through the same process as the “Content” below the front matter.

I added a new issue for a new template function that will render shortcodes in strings passed into it.

I think that this will be a more flexible approach than trying to extend an existing function like markdownify.