It would be a great feature if Kirby supported frontmatter in Markdown files additionally to its proprietary format.
With more people migrating from other systems to Kirby, support for frontmatter could make migration a lot easier and quicker. Especially for bloggers moving from Eleventy/11ty and other MD based systems.
Example Markdown + Frontmatter
---
title: New Years Resolutions
date: 2024-12-31 23:59+1
---
This year I plan to migrate to Kirby!
Example Kirby
title: New Years Resolutions
----
date: 2024-12-31 23:59+1
----
content:
This year I plan to migrate to Kirby!
Alternatively, Kirby could offer a migration tool that translates MD-files into Kirby-TXT files.
Very easy to build yourself using Virtual Pages. Essentially, this is the code I use (using GitHub API, but local files would work as well). Using this library: https://github.com/spatie/yaml-front-matter
You could also use “physical” pages and build your own Data
implementation (https://github.com/getkirby/kirby/tree/main/src/Data), either by overriding the txt
type in https://github.com/getkirby/kirby/blob/7cee6564bac5463275032bc2df5d3d399aa4be84/src/Data/Data.php#L40 or by switching the relevant pages to a custom content file extension.
Both replies are interesting. However, I still think that Kirby should support the default form of Markdown natively. It would make the CMS more compatible with third party editors like Obsidian, iA Writer and many more, and more accessible for users who are not perticularly code-savvy and do not have the resources, time, or ability to extend Kirby’s core functionality.
I think that files with the md
-extension should be treated as markdown files, including the FrontMatter way of encoding metadata. This would make it a lot easer to add a blog to a Kirby page that uses txt
-files for normal pages and md
-files for posts.
About the “default form of Markdown”: Kirby 1 predates Jekyll 1 (which popularized the frontmatter format). So there’s that ;)
Having to parse YAML also has performance implications, so our simple text format is still a good default for Kirby.
But independent of that I see the arguments for making the frontmatter format an option in the core. We will certainly keep this feedback topic open.
Thanks for considering it and for informing me about what happened when, I didn’t realize. I understand performance is crucial, and since Kirby is file based, the parsing can’t be heavy on compute.
What about the Kirby cache? Couldn’t Kirby use a file’s last modified date to only parse it once and then use the cache—not needing to parse the file ever again?
Yes, but that would increase complexity. There are always trade-offs that will depend on the project and its specific requirements. So both formats have their use.
Out of curiosity, doesn’t Kirby already check a file’s last modified date before rendering it? I always assumed it did…
You can retrieve the modification date with $page->modified()
, but Kirby does not call this method natively during rendering – only to determine the lock status of changes versions.