Warum ich von WordPress zu Kirby CMS gewechselt bin

Ich habe viele Jahre mit WordPress gearbeitet und damit auch einige Websites umgesetzt. Irgendwann habe ich aber gemerkt, dass WordPress für die Art, wie ich heute Websites entwickeln möchte, nicht mehr so richtig zu mir passt.

Ich wollte ein CMS, das für kleine und mittlere Websites gut funktioniert, ohne direkt einen riesigen Unterbau mitzubringen. Ein System, bei dem ich möglichst viel selbst in der Hand habe und nicht für jede zusätzliche Funktion erst überlegen muss, welches Plugin ich dafür installiere.

Gleichzeitig sollte es aber auch kein komplett minimalistisches CMS sein, bei dem ich am Ende sämtliche grundlegenden Funktionen selbst bauen muss.

Genau an diesem Punkt bin ich bei Kirby gelandet.

Was mir an Kirby ziemlich schnell gefallen hat, war der starke Fokus auf Einfachheit. Ich bekomme ein CMS und ein flexibles Panel für die Redakteure, kann aber gleichzeitig die komplette Website so entwickeln, wie ich es möchte.

Kirby gibt mir dabei viele Werkzeuge an die Hand, schreibt mir aber nicht vor, wie ich meine Website aufbauen muss.

Was mich an WordPress immer mehr gestört hat

Einer der größten Punkte war für mich irgendwann die starke Abhängigkeit von Plugins.

Natürlich kann man in WordPress sehr viel selbst entwickeln. Trotzdem hatte ich bei vielen Projekten immer wieder das Gefühl: Ich brauche eine bestimmte Funktion – also suche ich zuerst nach einem Plugin.

• Formulare? Plugin.
• SEO? Plugin.
• Custom Fields? Plugin.
• Mehrsprachigkeit? Plugin.
• Caching? Plugin.

Und grundsätzlich ist daran auch nichts falsch. Das riesige Plugin-Ökosystem ist schließlich eine der großen Stärken von WordPress.

Gleichzeitig wurde es für mich aber immer häufiger zu einem der größten Nachteile.

Denn mit jedem Plugin kommt eine weitere Abhängigkeit ins Projekt. Ein weiterer Entwickler oder Anbieter, auf dessen Updates ich angewiesen bin. Eine weitere Oberfläche, die anders funktioniert. Und teilweise auch ein weiteres Abo.

Besonders nervig fand ich dabei die Entwicklung der letzten Jahre hin zu immer mehr Freemium-Modellen.

Man installiert ein Plugin, weil man eine bestimmte Funktion benötigt, und stellt dann fest, dass genau diese Funktion nur in der Pro-Version enthalten ist.

Natürlich müssen die Entwickler hinter den Plugins auch Geld verdienen. Darum geht es mir gar nicht.

Aber wenn eine eigentlich überschaubare Website plötzlich aus WordPress, einem Theme, zahlreichen Plugins und mehreren kostenpflichtigen Lizenzen besteht, hat sich das für mich irgendwann einfach nicht mehr gut angefühlt.

Selber entwickeln? Natürlich – aber wie?

Die offensichtliche Antwort darauf lautet natürlich:

Dann entwickle die Funktionen doch einfach selbst.

Und ja, das geht mit WordPress.

Ich habe dabei aber immer wieder festgestellt, dass mir die Developer Experience von WordPress nicht besonders viel Spaß macht.

WordPress trägt inzwischen mehr als 20 Jahre Geschichte mit sich herum. Das merkt man meiner Meinung nach auch beim Entwickeln. Es gibt Hooks, Actions, Filter, globale Funktionen, unterschiedliche APIs und teilweise mehrere Wege, um dasselbe Problem zu lösen.

Dazu kam für mich die Dokumentation.

Vielleicht habe ich teilweise auch einfach an den falschen Stellen gesucht, aber ich hatte bei WordPress erstaunlich oft das Gefühl, mir Informationen aus verschiedenen Dokumentationen, Blogposts, Stack-Overflow-Antworten oder GitHub-Issues zusammensuchen zu müssen.

Es funktioniert am Ende irgendwie – aber besonders angenehm fand ich diesen Weg selten.

Developer Experience in WordPress

Ein gutes Beispiel dafür sind für mich eigene Komponenten.

Ich habe über die Jahre mit verschiedenen Page Buildern gearbeitet. Solange man die vorhandenen Komponenten verwendet, funktioniert das meistens ziemlich gut.

Sobald man aber eigene Module oder Widgets entwickeln möchte, wird es schnell aufwendiger.

Mit Gutenberg hat WordPress dafür mittlerweile eine eigene Lösung. Grundsätzlich finde ich den Ansatz von Gutenberg auch gut. Ich kann eigene Blocks entwickeln und den Redakteuren genau die Komponenten zur Verfügung stellen, die sie für eine Website benötigen.

Bei der Entwicklung eines eigenen Blocks kommt für mich aber relativ schnell wieder eine gewisse Komplexität dazu.

Nehmen wir ein wirklich einfaches Beispiel:

Ein Bild mit einer Bildunterschrift.

Für einen eigenen dynamischen Gutenberg Block benötige ich zunächst eine block.json, in der ich den Block registriere und seine Attribute definiere.

{
  "apiVersion": 3,
  "name": "example/image-caption",
  "title": "Bild mit Caption",
  "category": "media",
  "attributes": {
    "imageId": {
      "type": "number"
    },
    "imageUrl": {
      "type": "string"
    },
    "caption": {
      "type": "string"
    }
  },
  "editorScript": "file:./index.js",
  "render": "file:./render.php"
}

Anschließend benötige ich die Darstellung für den Gutenberg Editor.

Vereinfacht könnte das beispielsweise so aussehen:

import {
  MediaUpload,
  MediaUploadCheck,
  RichText,
  useBlockProps
} from '@wordpress/block-editor';
import { Button } from '@wordpress/components';

export default function Edit({ attributes, setAttributes }) {
  const { imageId, imageUrl, caption } = attributes;

  return (
    <figure {...useBlockProps()}>
      <MediaUploadCheck>
        <MediaUpload
          allowedTypes={['image']}
          value={imageId}
          onSelect={(image) =>
            setAttributes({
              imageId: image.id,
              imageUrl: image.url
            })
          }
          render={({ open }) => (
            imageUrl
              ? <img src={imageUrl} alt="" onClick={open} />
              : <Button onClick={open}>Bild auswählen</Button>
          )}
        />
      </MediaUploadCheck>

      <RichText
        tagName="figcaption"
        value={caption}
        onChange={(caption) => setAttributes({ caption })}
        placeholder="Bildunterschrift"
      />
    </figure>
  );
}

Und weil ich den Block dynamisch rendern möchte, kommt anschließend noch das PHP für das Frontend dazu.

<?php

$image_id = $attributes['imageId'] ?? null;
$caption  = $attributes['caption'] ?? '';

if (!$image_id) {
    return;
}
?>

<figure>
    <?= wp_get_attachment_image($image_id, 'large') ?>

    <?php if ($caption) : ?>
        <figcaption>
            <?= wp_kses_post($caption) ?>
        </figcaption>
    <?php endif; ?>
</figure>

Das ist jetzt bewusst ein vereinfachtes Beispiel. In einem echten Projekt kommen je nach Anforderungen noch weitere Dinge dazu.

Und natürlich kann man einen Gutenberg Block auch anders aufbauen.

Aber genau das zeigt ganz gut meinen Punkt.

Für eine Komponente, die eigentlich nur aus einem Bild und einer Bildunterschrift besteht, habe ich plötzlich mehrere Dateien, React für den Editor, die WordPress Block API und PHP für das Frontend.

Das funktioniert.

Mir persönlich ist es für viele klassische Websites aber einfach zu viel.

Und wie sieht das bei Kirby aus?

Bei Kirby war genau dieser Punkt für mich einer der größten Unterschiede.

Die gleiche Komponente kann ich dort über einen Blueprint definieren.

name: Bild mit Caption

fields:
  image:
    label: Bild
    type: files
    multiple: false
    layout: cards

  caption:
    label: Bildunterschrift
    type: text

Damit habe ich bereits definiert, was ein Redakteur im Panel bearbeiten kann.

Für die Ausgabe im Frontend brauche ich anschließend nur noch mein PHP Snippet.

<?php if ($image = $block->image()->toFile()): ?>
  <figure>
    <img
      src="<?= $image->url() ?>"
      alt="<?= $image->alt()->esc() ?>"
    >

    <?php if ($block->caption()->isNotEmpty()): ?>
      <figcaption>
        <?= $block->caption()->esc() ?>
      </figcaption>
    <?php endif ?>
  </figure>
<?php endif ?>

Das war für mich tatsächlich einer dieser Momente, bei denen Kirby plötzlich sehr viel Sinn ergeben hat.

Ich definiere im Blueprint, welche Daten meine Komponente benötigt, und kümmere mich im Snippet darum, wie diese Daten im Frontend ausgegeben werden.

Mehr brauche ich für viele Komponenten erst einmal nicht.

Natürlich kann auch Kirby deutlich komplexer werden. Ich kann eigene Blocks mit einer individuellen Preview bauen, Plugins entwickeln oder das Panel erweitern.

Aber ich muss es eben nicht.

Für viele meiner Komponenten reichen YAML und PHP vollkommen aus.

Und genau diese Einfachheit gefällt mir.

Weniger darüber nachdenken, was das CMS von mir möchte

Bei Kirby hatte ich relativ schnell das Gefühl, wieder mehr über die eigentliche Website nachzudenken.

Wie möchte ich meine Komponenten strukturieren?

Welche Felder braucht ein Redakteur wirklich?

Welches Markup möchte ich im Frontend ausgeben?

Wie möchte ich meine Templates und Snippets organisieren?

Kirby stellt mir dafür die Werkzeuge zur Verfügung und lässt mich anschließend meine Architektur selbst bestimmen.

Und genau das ist wahrscheinlich der größte Unterschied für mich.

Bei WordPress habe ich mich irgendwann immer häufiger gefragt:

Welches Plugin brauche ich dafür?

Oder:

Wie möchte WordPress, dass ich das umsetze?

Bei Kirby frage ich mich eher:

Wie möchte ich das umsetzen?

Das klingt zunächst nach einem kleinen Unterschied.

Für meine tägliche Arbeit macht es aber einen ziemlich großen Unterschied.

Würde ich heute wieder zurück zu WordPress wechseln?

Mittlerweile arbeite ich seit ungefähr einem halben Jahr mit Kirby. Und wenn ich nach dieser Zeit ein Fazit ziehen müsste, wäre es wahrscheinlich ziemlich einfach:

Bis jetzt gab es keinen Moment, an dem ich wieder zurück zu WordPress wollte.

Im Gegenteil. Ich habe das Gefühl, dass ich mit Kirby deutlich schneller entwickle – und das nicht nur bei einfachen Websites oder Komponenten.

Auch komplexere Komponenten bekomme ich mittlerweile wesentlich schneller umgesetzt. Bei WordPress habe ich teilweise zwei bis drei Stunden gebraucht, bis allein das Grundgerüst für einen eigenen Gutenberg Block stand und die entsprechende React-Komponente im Editor so funktioniert hat, wie ich es wollte.

Bei Kirby definiere ich meine Felder im Blueprint, baue mein PHP Snippet und kann mich ziemlich schnell um das kümmern, worum es mir eigentlich geht: die Komponente selbst.

Dazu kommen viele Kleinigkeiten, die für mich inzwischen einen ziemlich großen Unterschied machen.

Das Setup eines neuen Projekts geht schnell. Ich brauche keine Datenbank. Mehrsprachigkeit ist bereits im CMS vorgesehen. Ich kann meine Komponenten so bauen, wie ich sie brauche, und bin für viele grundlegende Funktionen nicht auf zusätzliche Plugins angewiesen.

Auch moderne Workflows lassen sich für mich sehr gut damit verbinden. Gerade die Integration von LLMs zum Erstellen oder Aufbereiten von Content ist etwas, womit ich aktuell gerne experimentiere.

Und natürlich kostet Kirby selbst Geld. Mir ist dieses Modell mittlerweile aber deutlich lieber, als ein kostenloses CMS als Grundlage zu haben und anschließend für verschiedene Funktionen einzelne Plugins, Pro-Versionen oder laufende Abos zu benötigen.

Gibt es Dinge, die WordPress besser kann?

Nach meinem aktuellen Stand und für die Art von Websites, die ich entwickle, kann ich diese Frage tatsächlich nicht wirklich mit einem konkreten Beispiel beantworten.

Das bedeutet nicht, dass Kirby grundsätzlich das bessere CMS ist. WordPress und Kirby verfolgen teilweise sehr unterschiedliche Ansätze und es wird sicherlich Projekte und Teams geben, für die WordPress die bessere Wahl ist.

Für mich und meine Art, Websites zu entwickeln, ist es momentan aber Kirby.

Wenn mich heute jemand fragen würde, warum ich Kirby verwende, müsste ich deshalb gar nicht lange überlegen:

Schnelles Setup, keine Datenbank, schnelle Entwicklung eigener Komponenten, Mehrsprachigkeit von Haus aus, eine für mich sehr gute Developer Experience und deutlich weniger Abhängigkeit von Plugins und Abos.

Am Ende war der Wechsel von WordPress zu Kirby für mich deshalb weniger ein Wechsel von einem CMS zu einem anderen.

Es war vielmehr ein Wechsel zurück zu der Art, wie ich Websites eigentlich entwickeln möchte.