Reading about the changes in Kirby v2.3, I’m intrigued by the possibility of using Twig as a template language. This goes someway to addressing the few (largely stylistic) issues I have with Kirby. Another similar issue is that of the document format.
A YAML front matter block proceeding markdown content has become something of a de facto standard across static site generators. For example:
---
title: Page title
intro: This is some intro text
info:
- title: First item title
description: First item description
- title: Second item title
description: Second item description
---
# Headline 1
Lorem ipsum dolor sit amet, consectetuer adipiscing elit.
Currently, Kirby has something close, but subtly different in two ways:
Each field is separated by four dashes
The content area has to be proceed with the text: value.
So, taking the above example, in Kirby this would be formatted as follows:
title: Page title
----
intro: This is some intro text
----
info:
- title: First item title
description: First item description
- title: Second item title
description: Second item description
----
text: # Headline 1
Lorem ipsum dolor sit amet, consectetuer adipiscing elit.
There are a couple of issues with this approach, not least portability of content, and the fact that services like GitHub have optimised their file viewers to support the more common format. Also, including text: alongside content feels like a combination of concerns.
Anyway… I guess my question is, is this something that can be addressed in a post-v2.3 world? If not, what would need to change in order to support this more common document format?
I don’t think that would fit well with Kirby’s approach. The fact that you have a text: label (or anything else) in front of the content is due to the fact that you can have multiple content fields, so you need a means of separating them.
Also, the front matter block as one entity is probably fine if it is kept short. As soon as you need to include more information, Kirby’s approach seems more reasonable/readable.
There’s also the issue of backwards compatibility.
I also think that omitting the “text” key for the main content won’t work for Kirby. Other than the “title” field, no fields are required. This means that users can name their main content field however they like, don’t use one at all (e.g. for pages that are just overviews and don’t have their own content) or even use multiple ones. Omitting the key there would lead to a lot of ambiguity.
I think, that’s the reason for the current format. You can have multiple fields with any content you want - Markdown, Yaml, or mostly anything else.
And I don´t know, how this could be achieved with your suggestion.
The current format is very flexible, because not everything can be divided in content + meta information.
This is one example where I think it is better to omit the standard and follow an own, better solution – as the previous posts have already shown why.
Thanks for your feedback, all. I’m not suggesting this as a replacement for the current format… that’s well established and understood. I’m enquiring about using this alternative content format (or indeed others or a custom one) as an option, much like Twig is now an option for templating via a plugin — a development that goes against some of the founding ethos surrounding Kirby, incidentally.
Secondly, the YAML front matter + Markdown format does allow for multiple blocks of content, via the YAML | function, like so:
---
title: This is the title of my page
intro: |
## Introduction
This is a block of markdown content. It could be **emboldened** or include [a link](/) for example.
---
This is the main content for that page. It also uses *Markdown*
So, to reiterate my question, what would need to change in order to support this alternative document format? Might it be possible with a plugin, or would it require additional changes to the Kirby API?
That part was not refactored into a Component, so it’s not easy to replace or extend without significant changes to core. Might be doable, but if there is very little demand it’s less likely to happen.
I’ve worked with several static site generators, and while Kirby’s way of not having a default content “field” (aka everything that is not YAML front-matter) was puzzling of a few minutes, it proved more flexible for custom content structures. With YAML front-matter you always have to decide which bit of content is big enough to be your “main” content, and which bits should be awkwardly crammed into the YAML front-matter. Or put your different content sections into child pages (“modular pages” in Grav), which does not help with editing in the admin panel.
One thing I would like though is changing the ---- token to something else. It’s a valid piece of Markdown (to make H2s or HRs). For instance, just playing a tiny bit with the regexp, I was able to write:
§ Title: Hello
§ Published: 2015-10-23
§ Text:
Hello from the other side
§ Credits:
Recorded at: Metropolis Studios in London, United Kingdom; mixed at
Capitol Studios in Los Angeles, California and Electric Lady Studios,
New York, New York.
Is it actually necessary for your use case to make Kirby understand the “frontmatter + content” format?
If you just want your content files to be future proof / portable, it seems like it wouldn’t be that hard of a task to write a generic converter that takes Kirby content files and spits out frontmatter files on the other end - by the time you actually need them.
Realistically though, you’ll never want to move your content away from Kirby anyway, so my advice is to just learn to love its content file structure and live happily ever after.
On a related note, making a frontmatter-to-kirby content file converter available on the Kirby website might be a useful (marketing) tool to help users of other systems migrate to Kirby.
