Text:
Kirby is the content management system I use for all of my websites. It comes with an incredibly powerful backend called the Panel. This article is about not using the Panel. It might sound crazy, but for some projects, rawdogging the content folder is the right call.
Kirby stores content in plain, readable files inside of a folder structure. Every page is a subfolder, a field is a few lines of text, and a file named cover could be used as, well, the cover. In fact, you’re looking at such a file right now. The names on the left are field names, and the ---- lines separate them. Pretty readable, isn’t it?
Not using the Panel, I don’t even need blueprints. Adding a new field is just—
Field:
Bam. There it is. Now you can use it in the template.
It’s not like adding a field to a blueprint is a huge deal in Kirby. But for certain projects, or in certain (early) stages of projects, it’s quite empowering being able to write content and defining the structure at the same time.
You’re in the process of learning how to use Kirby? I’d suggest skipping the Panel altogether. So many questions can be answered by simply looking into the content folder, at the actual field values.
I’m sure you’d agree that the world was in a better place when Kirby didn’t have a Panel yet. Coincidence?
While similar at first glance, Kirby doesn’t use Frontmatter, where a YAML block of metadata would sit on top of one huge main text. In a Kirby file, everything is a field. The only special field is Title. Thinking about it, that’s not even true for Panel-less setups.
Anyways:
- sometimes: Markdown text is not enough. but: What else is there? - sometimes: You're wondering why you ditched the Panel. but: Maybe you can still use the structure field? - sometimes: You realise YAML is pretty cool. and: It's perfectly readable.
Yup:
That’s exactly what the structure field saves as well.
Simply use $page->anyways()->toStructure() in the frontend.
Of course you can put whatever the fuck you want into your fields. It doesn’t have to be readable. And while the Panel has to worry about boring stuff like script injections, you’re allowed to have fun:
Train:
Freedom:
The content folder is your Panel now.
Here are some tips:
- [x] Use
.mdinstead of.txtfor Markdown syntax highlighting - [x] My VSCode extension provides syntax highlighting for separators/fields, smart link pasting, and a “Create Meta Data File” context menu action for files
- [x] Set up snippets like
!datefor the current timestamp in ISO 8601 format - [x] Create your own Kirby CLI commands for repetitive tasks like creating pages, extracting colours, taking OG image screenshots, …
- [x]
<?= $page->file('cover') ?>can be surprisingly intuitive without the Panel - [ ] Set the
Uuidfield and refer topage://articlesinstead of cryptic letters or fragile slugs
With the Panel disabled, the content folder can remain in the repository. While this would lead to quite the overhead for Panel-managed sites, it’s a no-brainer for Panel-less ones. You get diffs for every edit, backups come for free, and deploying is a git push.
A disabled Panel also means one less attack surface on the server. Recently this topic seems to be too important to be the last paragraph of this article.
