Zola: Make the page front-matter section optional

[npryce]

I am trying to use Gutenberg to publish markdown content generated by other tools. Gutenberg fails to generate the site because the content does not start with a front-matter section.

I can add it to all the generated files by creating a build pipeline with Make, but (a) now I'm writing code to build the site and that's what I want to use Gutenberg for, and (b) I'd only add empty front-matter sections anyway.

Could Gutenberg treat the content as having an empty front-matter section if it does not find one in the Markdown file?

[paulcmal]

Hey, reading the code this seems to be the expected result. However, given that a page does compile with an empty frontmatter, that seems inconsistent to me. Maybe it should be allowed to compile without any frontmatter by having the frontmatter parser return an empty frontmatter in a such case, like so:

/// Split a file between the front matter and its content
/// Will return an error if the front matter wasn't found
fn split_content(file_path: &Path, content: &str) -> Result<(String, String)> {
    if !PAGE_RE.is_match(content) {
        Ok(("".to_string(), content.to_string()))
        //bail!("Couldn't find front matter in `{}`. Did you forget to add `+++`?", file_path.to_string_lossy());
    } else {

    // 2. extract the front matter and the content
    let caps = PAGE_RE.captures(content).unwrap();
    // caps[0] is the full match
    // caps[1] => front matter
    // caps[2] => content
    Ok((caps[1].to_string(), caps[2].to_string()))

    }
}

I just tried it and it seems to work fine :)

I'm curious about your use-case though. Would you like to tell a bit more about what it is you're building?

[Keats]

It could be made to work without frontmatter, it just feels nicer to me to have one, even if empty so you don't have random .md being rendered as pages by mistake - which happened to me early on.

[npryce]

If one is using Gutenberg to publish markdown documents generated by other tools, they don’t have a frontmatter section

[ghost]

This is exactly what I'm trying to accomplish:
https://github.com/Markaround/markaround/blob/placeholder/authors-first-manifesto.md

Basically, the generator uses different methods to create metadata directly from the content.
Easy example: Title infered from the first header.

@vassudanagunta is implementing it with hugo, here:
https://github.com/Markaround/hugo-af
But i'm not really interested in extending hugo.
Would you be interested to allow this use-case?

Edit: This would solve #396 and #317

Edit-1: Here is something which just occured to me as I was contemplating this matter. Let us not forget that by using 'front-matter' ,wether YAML, TOML, or JSON, in a *.md file, we are making this a part of the markdown spec. Now, it is likely too late to avoid this, but it is something to keep in mind. TOML seems to break most github/lab/tea parsing so far. Maybe only YAML sticks, since it was the biggest/first 'slang' of front-mattered markdown.

Edit-3: Iv just opened an issue which embodies the idea - basically being able to 'tweak' our markdown 'flavor' and processing.

[Keats]

Basically, the generator uses different methods to create metadata directly from the content.

That only works for very basic things like the title or if the date/ordering is in the filename. You are not going to be able to guess which template needs to be use, whether to insert anchor links in title, taxonomies etc or even just a description from the content.

I'm not entirely against having no front-matter but that at the same time having some random markdown being rendered without my knowledge doesn't feel great. I need to think a bit more on how to make both aspects work together.

[ghost]

An compile-time optional library to extend/replace the metadata-parsing step ?
Of course I dont have the code in mind, so you know best.
This is simply meant to allow me to render any markdown content, not to replace complex front-matter uses. Think non-technical people who want to use my publishing pipeline; they can do markdown just fine.
Or just reading any random markdown file(s) in a nicely-styled html!

Different approach: If gutenberg could simply use external TOML files that match the md file basename. That would allow me to use another tool to create and maintain those files ex-gutenberg.

[elbaro]

Can we add allow_no_frontmatter = false option to config.toml?

Edit: the name is misleading. It should be allow_missing_frontmatter = false

[dghaehre]

I am also in a "need" for this. I am using vimwiki with markdown and it would be super cool to use zola and get everything in the browser.

Any new thoughts on this?

[Keats]

Not right now

[Recmo]

I need this too (I'm switching to zola and am not going to add front-matters to ten years of markdown posts. Also, the front-matter breaks some other tooling). So created a fork that makes front-matter optional and tries to collect the data by other means:

• If there is a title in front-matter, use that.
• Or else look for the first level-1 heading # Title and use that.

• Or else use the filename without extensions.

• If there are created and/or updated dates in front-matter, use that.

• Or else check the git log for the first and last commit date on the file.
• Or else use the file system creation and modification date.

It's hacky but serves my needs. You could also extract the author from git history, but my personal blog is single-author so I didn't bother. It can be cleaned up and turned into a PR if there is interest.