◆ KI und WordPress WP Meetup Hamburg #140

Kapitel 10

Die Mittellage

Die Frage lautet nicht „KI oder WordPress". Sie lautet: Wer darf die Seite in zwei Jahren ändern — und womit?

  • Er schafft das CMS nicht ab. Er baut es neu, für einen Kunden, allein.
  • WordPress läuft überall: Wird ein Hoster zu teuer, ziehst du um. Mit allem.
  • Und wenn du morgen ausfällst, findet dein Kunde jemanden, der es kennt.
  • Der Normalfall ist der Mittelweg: Der Kunde macht Text und Bilder, wir den Rest.
  • Bricks-Komponenten als Blöcke, Etch, PHP-Blöcke im Core — Vorlagen mit Leitplanken.

Die KI baut die Bausteine. WordPress hält den Rahmen, die Rechte und die Übergabe.

Es geht nicht um das Framework

Welches Werkzeug gewinnt, ist die falsche Frage. Es gibt drei, die zählen — und die stellt man am besten, bevor man sich für irgendetwas entscheidet.

  • Wartbarkeit: Kann es jemand anderes ändern?

    Nicht „kann ich es ändern". Sondern: Kann es jemand ändern, der nicht dabei war, in einem Jahr, ohne mich anzurufen? Namen im Markup und Werte im Token-System sind keine Geschmacksfrage — sie sind die Antwort auf genau diese Frage.

  • Skalierbarkeit: Kostet die fünfzigste Seite so viel wie die erste?

    Wenn jede neue Seite wieder Entscheidungen über Abstände, Farben und Varianten verlangt, skaliert es nicht — dann wird es mit jeder Seite teurer. Wenn die Bausteine stehen, ist eine neue Seite nur noch: Inhalt einfüllen.

  • Zugang: Wer kommt überhaupt rein?

    Damit meine ich nicht Barrierefreiheit im WCAG-Sinn, sondern ganz praktisch: Wer darf und kann etwas veröffentlichen? Eine Person mit Git-Zugang und einem Deploy-Prozess — oder jeder im Team, der sich einloggen kann? Das entscheidet, ob eine Website lebt oder einfriert.

  • Und genau das ist das Angebot

    Einmal richtig aufsetzen: Templates, Komponenten, Rollen, Rechte. Danach schreiben und veröffentlichen, so oft ihr wollt, ohne dass jemand Code anfasst. Der Aufwand liegt am Anfang und nicht bei jedem einzelnen Beitrag — das ist der ganze Handel, und er ist zwanzig Jahre alt.

Zwei Arten, dieselbe Karte zu schreiben

Links steht, was tatsächlich ausgeliefert wird. Rechts dasselbe Element, nur mit Namen für seine Teile. Beides funktioniert. Nur eines davon kann man in einem Jahr noch lesen.

Ohne Namen — was die KI gebaut hat
<div class="flex h-full flex-col justify-start gap-3.5">
  <div class="flex size-10 shrink-0 items-center
    justify-center rounded-full bg-gold/[0.18] text-gold">
  <span class="flex w-full flex-col before:absolute
    before:inset-0 before:content-['']">
    <h3 class="font-sans text-[19px] leading-6
      font-semibold text-white">Bessere Qualität</h3>
    <span class="mt-3.5 font-body text-sm
      leading-[23px] text-white/70">…</span>
Mit Namen — derselbe Baustein
<article class="feature-card">
  <div class="feature-card__icon">…</div>
  <h3 class="feature-card__title">Bessere Qualität</h3>
  <p class="feature-card__text">…</p>
</article>

Ein Framework wie ACSS nimmt dir die Entscheidung ab: konsistente Abstände, konsistente Farben, geprüfte Kontraste — dafür sehen die Seiten einander ähnlich, bis hin zu den immer gleichen Icons. Utility-Klassen nehmen dir gar nichts ab: maximale Freiheit, und hinterher weiß niemand, was ein Element eigentlich ist. Die Mitte ist unspektakulär: eigene Namen für die eigenen Bausteine, Werte aus dem Token-System. Dann sagt das Markup, was es ist, und die Werte sagen, wie es aussieht.