Feature Request - Option to Separate Front Matter and Content into Different Files

feature
1

I have been using Hugo for several years, our company uses it for about half a dozen websites and also internally for QA. Thank you for your work.

One of the annoying niggles I do have with it is that because the front matter is embedded in the content file it is more complex to programatically manipulate the content and also a lot of markdown plugins don’t display markdown files properly due to the front matter.

My proposal is for front matter to optionally be stored in a separate toml/yaml/json file which has the same name as the .md file just with a different file extension. If no front matter file is supplied then hugo can just assume that the front matter is supplied in the .md file as has always been the case.

This will make for easier manipulation/generation of both front matter and content.

For example:

  • content/index.md
  • content/index.yml
  • content/about/index.md
  • content/about/index.yml
  • content/support.md
  • content/support.yml
1 Like
2

Well, it’s called frontmatter because it’s in the front of the file. What you probably want is some kind of system that retrieves files in the data directory based on the filename or some key in the frontmatter of the markdown file in question. Other than that I don’t see why something that was born to be together has to get a feature to get separated. Your case is a very specific creation and IDE display issue, not a feature. I would even say IDEs should start supporting Hugo-Markdown files rather than changing Hugo.

Thinking a little more about it: I have cases where I moved JSON files into a page package. Have a look at how I integrated data files into the Hugo newsletter:

Build a template, that loads the data.json or frontmatter.json file from the folder where the .md file resides and load the info from there and use in your templates.

1 Like
3

I agree about the concept, but I’m not totally sold on the execution (there are, for one, some ambigouity issues (pretty sure I spelled that word wrong) with the above suggestion; or, it would probably break some existing sites.

That said, we have (at least) one issue that talks about “pages from data”. I have put that issue in front of my head this week and decided to try to get a first version out sooner than later that does not try to solve everything (which results in nothing being done).

From my drafts a content folder could look like this:

content
├── _content.sql
├── _index.md
├── blog
│   └── _content.json
└── docs
    ├── _content.cue
    ├── logo.jpg
    └── page.md
  • So, with the above any _content.* file will be expanded where it’s placed in the content tree, and can contain bundles (with images/image references etc.)
  • For the cue files, see https://github.com/cuelang/cue (not sure when/if we add that, but it would be cool)
  • The above will be expanded to remote content adapters (Word Press etc.)
  • I assume some level of merging with *.md files – which could allow you to keep “front matter” only in these files. Not sure.
3 Likes
4

Thanks for responding.

I do like the idea of the _content.* files.

I can see how making index.yml a metadata file would break systems in which there is already an index.yml file in the folder, maybe it is a bundle asset.

So in this situation would _content.json potentially have a reference that it could pick up the markdown from or would it simply hold the front matter and get the content from _index.md?

@davidsneighbour I definitely agree with the assertion that IDEs should have built in compatibility for Hugo, but sadly that is not the world we live in yet.

To be honest though it is having other languages inside a .md file that is the more significant issue for me. As I have said we have have been using Hugo for years and completely understand why the two sections are combined in a single file. But .md files not having pure markdown in it means that you can’t treat them like markdown files without processing them first, and in many cases Hugo might not be the only application that you want to be consuming the markdown.

Currently the easiest way to achieve this (I haven’t actually tried) might be to bundle a separate markdown file that contains the content and then consume it in the template and don’t include {{ .Content }} in the template so the imported markdown effectively replaces it. But this way isn’t that flexible and would be even stranger if you have an _index.md file that only contains yaml/toml/json

5

Any progress on this? Is anyone working on a solution? I too would like to separate front matter from content. The json looks weird in my markdown editor, and if I ever stop using Hugo, I have to go back and remove a bunch of Hugo-specific data from my content. Thanks!

6

I also dislike having the real post mixed with metadata.

One way to achieve this is to create a page bundle. In index.md, you keep the front matter and a single

{{% include "content.md" %}}

(which requires the include shortcode, see Hugo: include/embed another file with a shortcode | Roneo.org). Then content.md contains… your content.