Approach for Content Segmentation

I’ve been wondering about a means of segmenting content into parts of a template. The purpose of doing so would be to achieve a better separation of metadata and content in a content file.

Let’s say that my template has HTML for a <main> and <aside> tags and I want to specify in a content file what will go in each tag. This is a simple example, working for HTML and not markdown.

The template looks for content between HTML comments that specify a segment of HTML.

{{ $main := findRE "<!--content.main-->(.|\n)*?<!--end-->" .Content }}`
{{ $aside := findRE "<!--content.aside-->(.|\n)*?<!--end-->" .Content }}`
{{ partial "head" . }}
      {{ range $main }}{{ . | safeHTML }}{{ end }}
      {{ range $aside }}{{ . | safeHTML }}{{ end }}

The content file will have the respective HTML .

date = "2016-06-22T00:54:48-04:00"
title = "Content Segmentation"
<h1>Main Content</h1>
<h2>Aside Content</h2>

The mechanics work fine. I’m just wondering if the approach aligns well with the goals and methodologies of the HUGO project. I also wonder if there’s currently another (better) means of accomplishing the same objective that I’m overlooking. I’d appreciate any thoughts, opinions, suggests. If it’s useful to you, have fun! :slightly_smiling:



This works, but is suboptimal, most notable in the speed and memory department.


My thoughts in there could be expanded to your side and main sections. If you have 10K pages, you don’t want to parse them 10 times and create 10 copies of them just to segment some content.

But the above issue may be long down the road.

1 Like

Hi @bep,
Thanks, I really appreciate the feedback and now understand & appreciate the performance implications. The issue paints that picture well.

Assuming this weren’t a performance cost, I wonder about this as approach and as a good content design pattern. I love Content Views for the ability to render content different ways from a shared template. This works wonderfully when working with Frontmatter .Params , but I’m wonder about rendering content that’s best placed in .Content.

An example would be a list template where I’m rendering a code snippet from each page in the node. That code snippet may be more manageable when kept in a page’s .Content rather than making it a .Param.

Essentially I’m asking if the <!--more--> summary concept could/should be expanded to allow for content selections that don’t live in Frontmatter. I don’t have an answer for that. It might be an edge case that wouldn’t be very useful. I’m remaking my site with HUGO and was curious.

Thanks again for your feedback!


@ecarlisle This is an intriguing idea, but my thoughts are that when you compare an SSG to your typical CMS, the front matter of an .md is the plain-text representation of the typical inputs you find above a “body copy” text field (ie, {{.Content}} in Hugo). Thus, I see little utility in complicating a single field. Basically, {{.Content}} is really just content:; ie, the final key-value below your front matter…if that makes sense.

Performance implications notwithstanding, the real convenience factor for content is the ability to write in markdown, so I think you’ll end up doing just as much, if not more, work with the above solution than you would with, say, adding a couple key-values in your front matter.

I think the best direction would be for Hugo to add terse methods to create relationships between content models, but such a suggestion is easy for me to make considering I’m not a Go programmer :wink:

1 Like

I’m not sure @ecarlisle s example is the best … but there are clearly obvious improvements in this area in Hugo. People have some expectations in this area, they want to:

  • add some author / social links after the ingress
  • put the ToC wherever they want, and format the way they want
  • put the footnote refs wherever they want
  • …?

Right now only the ToC part is kind of possible, and it is done in a hackish way. All of the above is content.

1 Like