Block-Theme oder Classic-Theme in WordPress: der ehrliche Vergleich

Öffnen Sie Ihren Theme-Ordner. Enthält er ein Verzeichnis templates mit einer index.html darin sowie eine theme.json im Wurzelverzeichnis, haben Sie ein Block-Theme vor sich. Enthält er eine index.php neben Dateien wie header.php und footer.php, und zeigt Ihre Admin-Seitenleiste Design und dann Customizer, ist es ein Classic-Theme.

Dieser eine strukturelle Unterschied entscheidet darüber, wer was auf Ihrer Website ändern kann, wo diese Änderungen gespeichert werden und welche Hälfte des WordPress-Plugin-Ökosystems sich normal verhält.

Die 30-Sekunden-Bestimmung

Merkmal	Classic-Theme	Block-Theme
Basis-Template	index.php	templates/index.html
Kopf- und Fußbereich	header.php, footer.php	parts/header.html, parts/footer.html
Globale Konfiguration	functions.php	theme.json (plus optionale functions.php)
Adminmenü	Design > Customizer	Design > Editor
Speicherort der Änderungen	Dateien auf der Festplatte	Datenbank, als wp_template-Beiträge
Widgets-Bildschirm	vorhanden	nicht vorhanden

WordPress entscheidet anhand der Datei templates/index.html. Ein Theme, das zwar eine theme.json mitbringt, aber seine PHP-Templates behält, gilt weiterhin als Classic – dieser Zwischenzustand ist verbreitet und hat einen Namen, dazu unten mehr.

Mit Shell-Zugriff klärt ein einziger Befehl die Sache:

wp eval 'var_dump( wp_is_block_theme() );'

WP-CLI ist die schnellste Prüfung bei einer Website, die Sie nicht selbst gebaut haben – besonders dann, wenn ein Page-Builder die üblichen Adminmenüs versteckt hat.

Was sich für die Person ändert, die die Website pflegt

In einem Classic-Theme liegen Kopfbereich, Fußbereich, Seitenleiste, Farben und Logo hinter dem Customizer, und Sie bekommen nur die Bedienelemente, die der Theme-Autor eingebaut hat. Hat das Theme kein Feld für den Copyright-Text im Fußbereich vorgesehen, gibt es kein Feld. Entweder Sie bearbeiten eine PHP-Datei oder Sie leben damit.

In einem Block-Theme legt der Site-Editor die gesamte Seite offen. Kopfbereich, Fußbereich, die Beitragsschleife, die 404-Seite, das Layout der Suchergebnisse – alles besteht aus Blöcken, alles ist von jemandem bearbeitbar, der nie PHP gesehen hat. Das ist die eigentliche Schlagzeile, und sie ist wirklich gewichtig.

Der Preis dafür: Alles ist von jemandem bearbeitbar, der nie PHP gesehen hat. Ein Kunde kann um zwei Uhr nachts den Websitetitel aus dem Kopfbereich löschen, und es gibt keinen Versionsverlauf auf der Festplatte, aus dem sich das wiederherstellen ließe – nur die eigenen Revisionen des Site-Editors. Absichern lässt sich das über Blocksperren und über Einschränkungen, wer den Editor überhaupt erreicht. Aber das ist Zusatzarbeit, an die Sie aktiv denken müssen.

Zwei kleinere Verluste, die in der Praxis wehtun: Block-Themes haben keinen Widgets-Bildschirm (Widget-Bereiche werden durch Template-Teile und Blöcke ersetzt), und klassische Menüs weichen dem Navigation-Block, der seine Einträge als eigenen Inhaltstyp speichert statt im gewohnten Menü-Bildschirm.

Was sich für Entwickler ändert

Classic-Themes nutzen die PHP-Template-Hierarchie. WordPress löst einen Request entlang einer bekannten Kette auf – single-{post-type}.php, dann single.php, dann singular.php, dann index.php – und Ihre Datei läuft, ruft get_header() auf, durchläuft The Loop und gibt Markup aus, das Sie Zeichen für Zeichen kontrollieren.

<?php get_header(); ?>
<main class="site-main">
  <?php while ( have_posts() ) : the_post(); ?>
    <h1><?php the_title(); ?></h1>
    <?php the_content(); ?>
  <?php endwhile; ?>
</main>
<?php get_footer(); ?>

Block-Themes verwenden dieselben Hierarchienamen mit der Endung .html, aber die Datei enthält Block-Markup – HTML mit Block-Trennern in Kommentaren – und es gibt keine Template-Tags:

<!-- wp:template-part {"slug":"header","tagName":"header"} /-->

<!-- wp:group {"tagName":"main"} -->
<main class="wp-block-group">
  <!-- wp:post-title {"level":1} /-->
  <!-- wp:post-content /-->
</main>
<!-- /wp:group -->

<!-- wp:template-part {"slug":"footer","tagName":"footer"} /-->

Drei Konsequenzen treffen Entwickler sofort:

get_header() und get_footer() laufen nie. Alles, was an diesen Actions hängt – in einem Plugin oder einem alten Child-Theme – tut stillschweigend nichts. wp_head und wp_footer feuern weiterhin, das Einbinden von Skripten und Styles überlebt also meistens, header-spezifische Hooks aber nicht.

Die Datenbank schlägt Ihre Dateien. In dem Moment, in dem jemand ein Template im Site-Editor speichert, legt WordPress diese Fassung als wp_template-Beitrag ab und liefert sie statt Ihrer Datei aus. Sie können den ganzen Nachmittag an der HTML-Datei arbeiten und im Frontend keinerlei Veränderung sehen. Werden die Anpassungen für dieses Template gelöscht, gilt wieder die Dateifassung. Das ist die mit Abstand häufigste Meldung „mein Block-Theme ist kaputt” – und kein Fehler.

Die Gestaltung wandert in theme.json. Farben, Abstandsskala, Typografie und Block-Standardwerte werden als Daten deklariert statt als CSS, und WordPress erzeugt daraus das CSS. Das ist sauberer und deutlich konsistenter – bis Sie etwas brauchen, das das Schema nicht ausdrückt. Dann schreiben Sie ohnehin CSS und kämpfen gegen die Spezifität der generierten Regeln.

{
  "version": 3,
  "settings": {
    "color": {
      "palette": [
        { "slug": "brand", "color": "#1a1a1a", "name": "Brand" }
      ]
    }
  }
}

Gleichen Sie den Wert von version mit der WordPress-Ausgabe ab, die Sie einsetzen – das Schema wurde mehr als einmal überarbeitet, und eine aus einem alten Tutorial kopierte Versionsnummer führt zu Einstellungen, die klammheimlich ignoriert werden.

Und functions.php verschwindet nicht. Block-Themes nutzen die Datei weiterhin zum Einbinden von Assets, zum Registrieren von add_image_size-Einträgen, für eigene Inhaltstypen und alles Weitere in PHP. Sie machen dort nur sehr viel weniger Templating.

Was Sie wirklich gewinnen – und was Sie wirklich verlieren

Der Wechsel zu Block bringt Ihnen: Kontrolle über die gesamte Seite im Editor, gestalterische Konsistenz erzwungen durch theme.json, weniger Dateien zu pflegen und Styles, die zwischen Editor und Frontend weit häufiger übereinstimmen, als Classic-Themes das je hinbekommen haben.

Der Wechsel zu Block kostet Sie: die direkte Kontrolle über das ausgegebene Markup, die unkomplizierte Anpassung über Hooks, die Kompatibilität mit allem, was PHP-Templates voraussetzt, und die Gewissheit, dass das Erscheinungsbild der Website in der Versionsverwaltung liegt.

Der letzte Punkt verdient Nachdruck. In einem Classic-Theme sagt Ihnen git log, was sich geändert hat. In einem Block-Theme lebt ein erheblicher Teil des Erscheinungsbilds in der Datenbank – dort, wo Ihre Deployment-Pipeline nicht hinsieht.

Wann ein Classic-Theme weiterhin die richtige Antwort ist

• Ein Page-Builder betreibt die Website. Elementor, Divi, Beaver Builder und ähnliche Werkzeuge übernehmen das Templating selbst. Ein Block-Theme darunterzulegen ergänzt ein zweites Templating-System, das nichts tut.
• Das Markup muss exakt stimmen. Maßgeschneiderte Komponentenbibliotheken, strenge Barrierefreiheits-Anforderungen, ungewöhnliche Schema-Vorgaben – die Block-Ausgabe ist auf das begrenzt, was Blöcke ausgeben, und dagegen anzuarbeiten kostet mehr als PHP zu schreiben.
• Viel Plugin-Templating. Mitglieder-, LMS-, Verzeichnis- und ältere Commerce-Erweiterungen liefern häufig PHP-Template-Overrides mit. Viele haben inzwischen Block-Entsprechungen, viele aber nicht.
• Die Website ist fertig und läuft. Ein Theme mit fünf Jahren angesammelter Anpassungen hat keinen Upgrade-Pfad zu Block, sondern nur einen Neubau. „Das ist der neuere Ansatz” ist kein betriebswirtschaftliches Argument.
• Außer Ihnen bearbeitet niemand die Website. Der Hauptnutzen des Site-Editors besteht darin, Kontrolle an Nicht-Entwickler abzugeben. Gibt es keine Nicht-Entwickler, zahlen Sie den Preis für einen Nutzen, den niemand abruft.

Der hybride Mittelweg

Ein Classic-Theme kann eine theme.json ergänzen und bekommt damit das Global-Styles-System, die Farb- und Abstands-Presets sowie eine konsistente Editor-Gestaltung – und behält gleichzeitig seine PHP-Templates und den Customizer. WordPress nennt das nicht Block-Theme, der Site-Editor bleibt also unerreichbar, aber Sie erhalten den größten Teil des Design-System-Nutzens für einen Bruchteil des Aufwands.

Für eine bestehende Website, die im Wesentlichen funktioniert, ist das üblicherweise der richtige erste Schritt. theme.json hinzufügen, Palette und Abstände definieren, das dadurch ersetzte CSS löschen – und dann sehen, ob Sie den Rest überhaupt noch wollen.