A little over a year ago, in February 2025, I launched moinframe. But the wish to share my excitement for Kirby with more people had been brewing for years before that.

Let's take a quick trip down to memory lane.

I found Kirby CMS back in version 2, looking for a proper home for my photography portfolio and blog. Back then, WordPress was the obvious choice, and to be fair, WordPress is what introduced me to the whole world of self-hosted websites in the first place. I owe it that.

But a predefined theme was never my dream. So I dug into the theme files pretty quickly, met the famous WordPress Loop, and realized: nope. Everything is a post, the syntax, widgets and the markup ends up tangled with the logic in ways I never got comfortable with. It worked, but it never clicked, as the cool kids say. Even though I wasn't a developer back then.

Then I found Kirby. A flat-file CMS, written in PHP, no database, no themes, no opinions about how my templates should look. A whole stack of friction was just gone.

The Panel was clear and customizable, all fields were the simple yaml structure we still use and love.

Image handling was easy, too. Of course with one necessity: the Focus Plugin developed by Flo, which was an amazing helper on image heavy layouts.

With php 5.3 (ha!) in the backend, I could built anything. A client gallery with password-protection, a pricelist with token based authentication (via url query). I even used the params() method for displaying child page content.

Here is the thing: Kirby did not turn me into a developer overnight. No software will, AI won't.

Kirby just did not get in the way. And I think that is the biggest trait.

Simple enough to start with as a designer, deep enough to grow into when I was ready. That is a rare combination. And this promise is kept over the last 10+ years.

Of course, Kirby was never the loud option. Every couple of months, the dev scene picks a new winner. When I started developing seriously, React was the new kid on the block. Then Next.js. Then headless everything. With round trips to Strapi and other Content Management Systems it always made work and setup more complex, while the output was not improving. In the size of projects I worked on anyways.

Now there is AI everything. If you sit there with a flat-file CMS and tell people it is what you build with, you can feel the polite skepticism in the room. Is that a real Gamechanger? Will that make me 30% more performant?

During my communication design studies, a few friends and I started a small studio and built actual client websites in Kirby 3. A furniture store. An industrial supplier. The little shop around the corner. Whatever the brief was, Kirby could carry it.

Fast forward through a few years at an agency, and the same picture, just bigger. Mid-sized clients, with great ambitions. API backend for a Web app for a trade fair booth? Maintained through Kirby. Service Portals, Company pages, Blogs. Having worked with Typo3 and Drupal before, Kirby provided a faster development time, a closer connection to the design team and a better editor experience in the panel for sure. Going Headless with Kirby and KQL, I was mapping content blocks from the panel into a Nuxt frontend. A little change in the preview option and the editor experience stayed superb.

This is the part that does not sound impressive but is the actual quiet superpower: every month, a new client requirement lands on the table. With the german "Mittelstand" as customers, it was always something specific or weirdly shaped. And nevertheless the conversation nearly always ended with, "yeah, that will work fine with Kirby." A confidence, built up over years and not over hype cycles. Today Claudia and I run Gute Kombi, our own brand and web studio. Smaller team, same answer when a brief lands on the table.

And in 2026, the case for the underdog has only gotten stronger. Every week brings a new AI-powered framework promising to disrupt the disruptors. The hot library from a couple of years ago has either been abandoned, renamed, or absorbed into something else. Kirby is here. Still light, still PHP, still in the hands of the people who build with it.

With the beautiful projects built on Kirby I see every week, i feel like: This underdog is winning. We don't do 10x performance. We do not disrupt the industry. We just kind of... finish awesome projects. Outrageous, I know 😬

And now, my head will have Banks on repeat the whole day. Lalala as the underdog (Rah).

The idea is simple. Kirby maps URL extensions to template files. We already have a posts.php template that renders when someone visits /posts. If we create a file called posts.xml.php, Kirby will automatically serve that when someone visits /posts.xml. This is perfect, since our RSS feed is just another representation of the same content – ha that name fits quite well i think :D

We still have access to our $page object and all the content and methods of that page.

You can also use this for JSON, or really any format you want. Worth checking out the Kirby docs on content representations if you want to dive deeper.

Before we write the template, one thing: RSS is just XML. If you've never written XML, it's basically like HTML but stricter. Every tag must be closed, attribute values must be quoted, and special characters need to be escaped.

For RSS specifically, there's a spec that defines a set of elements like <channel>, <item>, <title>, <description> and so on. The RSS 2.0 spec at rssboard.org is a good reference, or just ask an LLM to generate it for you.

Let's create site/templates/posts.xml.php.

RSS requires dates in RFC 2822 format and I'm using the PHP intl formatter,so we'll write a small helper script to create the timestamps.

function rssDate($field): string
{
  return $field->toDate('EEE, dd MMM yyyy HH:mm:ss') . ' ' . $field->toDate('xx');
}

Then we grab our posts, limited to the 20 most recent:

$posts = $page->children()->published()->sortBy('published', 'desc')->limit(20);

Now the actual XML output.

For escaping XML, we can use Kirby's built-in Escape::xml() method from the Toolkit (available as esc($value, 'xml')). It encodes special characters so they don't break the XML structure.

We set the content type header and write the RSS channel metadata: title, description, link, language, and the build date from the most recent post.

<?php header('Content-type: application/rss+xml; charset=utf-8'); ?>
<?= '<?xml version="1.0" encoding="UTF-8"?>' ?>
<rss version="2.0" xmlns:content="http://purl.org/rss/1.0/modules/content/" xmlns:atom="http://www.w3.org/2005/Atom">
  <channel>
    <title>
      <?= esc($site->title() . ' - ' . $page->title(), 'xml') ?>
    </title>
    <description><?= esc($page->metaDescription()->or($site->metaDescription()), 'xml') ?></description>
    <link><?= esc($page->url(), 'xml') ?></link>
    <atom:link href="<?= esc($page->url() . '.xml', 'xml') ?>" rel="self" type="application/rss+xml" />
    <language><?= $kirby->language()->code() ?></language>
    <lastBuildDate><?= rssDate($posts->first()->published()) ?></lastBuildDate>
    <?php foreach ($posts as $post): ?>
      <item>
        <title><?= esc($post->title(), 'xml') ?></title>
        <link><?= esc($post->url(), 'xml') ?></link>
        <guid><?= esc($post->url(), 'xml') ?></guid>
        <pubDate><?= rssDate($post->published()) ?></pubDate>
        <description>
          <![CDATA[<?= $post->main()->toBlocks()->excerpt(300) ?>]]>
        </description>
        <content:encoded>
          <![CDATA[<?= $post->main()->toBlocks() ?>]]>
        </content:encoded>
        <?php if ($author = $post->author()->toUser()): ?>
          <author><?= esc($author->email() . ' (' . $author->name() . ')', 'xml') ?></author>
        <?php endif ?>
      </item>
    <?php endforeach ?>
  </channel>
</rss>

Let's walk through what's happening.

The <channel> element wraps everything and describes the feed itself. The <atom:link> with rel="self" is a self-referencing URL, which some feed readers expect. The <lastBuildDate> tells readers when the feed was last updated, and we just use the date of the most recent post for that.

For each post, we output an <item>. That's the main building block in RSS, each item is one entry in the feed.

A few things worth noting:

If your posts have an author field, the author block at the bottom adds it to the feed. If not, the if check just skips it.

To make the feed discoverable, add an RSS autodiscovery tag in your <head>, in my case in the layout snippet:

<link rel="alternate" type="application/rss+xml" title="Posts" href="<?= $page->url() . '.xml' ?>">

This is what allows browsers and feed readers to automatically find your feed. And of course you can link to it visually in your posts template as well:

<a href="<?= $page->url() . '.xml' ?>">RSS Feed</a>

First, create a new folder in your content directory:

content/globalmedia/globalmedia.txt

Then create a matching blueprint. The blueprint is straightforward, just one section for images:

title: Global Media
options:
   extends: permissions/default
   delete: false
   preview: false
   duplicate: false
   changeStatus: false
   changeSlug: false
   move: false
status:
  unlisted: Published
sections:
  images:
    type: files
    layout: table
    search: true
    size: tiny
    template: image

We lock down the options so editors can't accidentally duplicate or move the page. It's a utility page, not content.

Since this page only stores media, it shouldn't be reachable on the frontend. Add a route to your config.php:

return [
  "routes" => [
    [
      "pattern" => "/globalmedia",
      "method" => "GET",
      "action" => function () {
        return;
      }
    ]
  ]
];

Now visiting /globalmedia returns a 404.

We need a way to decide, e.g. per template, whether file uploads should go to the page itself or to the global media page.

Create a plugin (e.g. site/plugins/project-helper) and add a page method:

Kirby::plugin('project/helper', [
  'pageMethods' => [
    'mediaPage' => function () {
      $mediaPage = page('globalmedia');
      if (!V::in($this->intendedTemplate(), ['note'])) return $mediaPage ?? $this;
      return $this;
    }
  ]
]);

The idea: templates listed in the array, note in this case, keep their files locally. Everything else uses the global media page. So a note stores its images in its own folder, but a page like "About" pulls from the shared pool.

Now update your file fields to use this method. For example, a cover field from the starterkit:

cover:
  type: files
  multiple: false
  query: page.mediaPage.images.template('image')
  uploads:
    parent: page.mediaPage
    template: image

The uploads.parent tells Kirby where to store new uploads, and the query tells the field where to look for existing files. Both point to page.mediaPage, which returns either the page itself or the global media page.

Do the same for image blocks or any other file fields where this applies.

For convenience, add the global media page to your panel sidebar. I'm using the Kirby Panel Menu plugin for this, which generates a sidebar menu.

return [
"panel" => [
  "menu" => fn($kirby) => panelMenu($kirby)
    ->site()
    ->page('Media', 'globalmedia', ['icon' => 'images'])
    ->area('users')
    ->area('system')
    ->toArray()
  ]
];

With everything in place, each template gets the storage strategy that makes sense for it.

The beauty of this approach is that you define the rules once in the plugin, and every file field across your site respects them automatically.

<?php
use Kirby\Toolkit\Str;

$name = $name ?? "";
$size = $size ?? "1em";
$sprite = asset('icons.svg');
?>

<i class="i" style="--size: <?= $size ?>" data-icon="<?= $name ?>">
  <svg aria-hidden>
    <use xlink:href="<?= $sprite->url() ?>?v=<?= $sprite->mediaHash() ?>#symbol-<?= $name ?>" />
  </svg>
</i>

Normally, you'd call the snippet like this:

<?php snippet('icon', ['name' => 'phone', 'size' => '1.25em']);?>

<?= icon('phone') ?>

Here is how you do it:

function icon(string $name, string $size = '1em') {
	return snippet('icon', ['name' => $name, 'size' => $size], true);
}

The method is basically just a slim wrapper around Kirby's snippet() method. It accepts the same parameters and returns the rendered snippet. The key detail: Passing true as the third argument makes the snippet return the HTML as a string instead of echoing it directly.

Let's say you have a heading block and you've added two custom fields: a style field (letting editors choose visual styles independent of the semantic level) and an text alignment field. Both work perfectly fine in the block drawer.

But here's the thing: the preview in the blocks field doesn't reflect those choices. The editor has no idea if a heading is centered or styled differently until they open the block again. That's not great UX.

The obvious solution would be to overwrite the k-block-type-heading component. Copy the whole thing, modify it, done. But then you're on the hook for maintaining that code whenever Kirby updates its panel. Not ideal.

Instead of replacing the component, we can extend it. Vue (and Kirby's panel plugin system) makes this surprisingly straightforward.

I've set up a minimal plugin with just two files:

plugins/panel-extend/
├── index.js
└── index.css

Both files get autoloaded by the panel. No extra registration needed.

In index.js, we define the plugin and extend the existing component:

window.panel.plugin("your-name/panel-extend", {
  components: {
    "k-block-type-heading": {
      extends: "k-block-type-heading",
      
      methods: {
        updateDataAttributes() {
          const { alignment, style } = this.content;
          if(!this.$el) return;
          this.$el.dataset.alignment = alignment
          this.$el.dataset.style = style
        }
      },
      
      watch: {
        content: {
          handler() {
            this.updateDataAttributes();
          },
          deep: true
        }
      },
      
      mounted() {
        this.updateDataAttributes();
      }
    }
  }
});

What's happening here:

That's it for the JS. We're not touching any of the original rendering logic, just adding data attributes that CSS can hook into.

In index.css, we use those data attributes to style the preview:

/* Styles */
.k-block-type-heading-input[data-style="h1"] {
  font-size: var(--text-3xl);
}
.k-block-type-heading-input[data-style="h2"] {
  font-size: var(--text-2xl);
}
.k-block-type-heading-input[data-style="h3"] {
  font-size: var(--text-xl);
}
/* ... h4, h5, h6 */

/* Alignment */
.k-block-type-heading-input[data-alignment="left"] {
  text-align: left;
}
.k-block-type-heading-input[data-alignment="center"] {
  text-align: center;
}
.k-block-type-heading-input[data-alignment="right"] {
  text-align: right;
}

Now when an editor changes the style or alignment in the block settings, the preview updates instantly. They can see that a heading is centered or styled as an H1 without having to open the drawer.

One thing to keep in mind: these are panel-only styles. Your frontend snippet still needs to handle the actual output. But for the editing experience, this makes a real difference.

Small touches like this help editors understand what they're building. A live preview that reflects their choices reduces friction and makes the panel feel more polished.

And the best part? When Kirby releases an update with improvements to the heading block component, you'll get those for free. Your extension just adds to the existing code, it doesn't replace it.

Give it a try. Extend what you need, keep what works.