Hör auf, jede WordPress-Seite neu aufzubauen

Zusammenfassung

Die meisten Agenturen bauen jede WordPress-Site aus einem leeren Theme auf, selbst wenn eine gemeinsame Basis Wochen aus dem Zeitplan streichen würde. Dieser Artikel argumentiert, dass theme.json, Block-Muster und dynamische Blöcke es Ihnen ermöglichen, die strukturelle Ebene zu standardisieren, ohne das individuelle Design jedes Kunden zu beeinträchtigen. Er geht direkt auf die fünf Einwände ein, die Teams davon abhalten, sich zu ändern: „Wir haben verschiedene Kunden“, „Individuelle Blöcke sind teuer“, „Der Editor ist verwirrend“, „Wir verlieren unsere Hooks und Filter“ und „FSE ist nicht produktionsreif“. Jeder Einwand erhält ein praktisches Gegenargument und ein konkretes Muster, das Sie schrittweise übernehmen können. Der Lohn ist ein wiederholbarer Build-Prozess, der maßgeschneiderte Arbeit dort würdigt, wo sie hingehört. Warnung: Es werden keine One-Click-Reset-Buttons versprochen.

Wie viele Ihrer Kundenseiten teilen sich auch nur eine Zeile Code? Nicht die Copyright-Zeile – echten Code. Wenn die Antwort „kaum eine“ lautet, kennen Sie den Schmerz bereits: derselbe Hero-Bereich zum neunten Mal neu gebaut, dasselbe Team-Grid-Markup von einem Projekt zum nächsten kopiert, dieselben Preprocess-Anpassungen über ein halbes Dutzend Themes hinweg abgeglichen. Sie haben auch die Verteidigung gehört: „Jeder Kunde hat andere Bedürfnisse.“ Richtig. Die Schlussfolgerung, die alle daraus ziehen – dass jede Website ein maßgeschneidertes Fundament braucht – ist jedoch falsch. Das WordPress-Ökosystem bietet Ihnen jetzt eine Möglichkeit, die strukturellen Teile zu standardisieren, ohne das Design zu standardisieren: theme.json für Design-Tokens, Block-Muster für wiederkehrende Layouts und dynamische Blöcke für die wenigen Funktionen, die echte serverseitige Logik benötigen. In diesem Artikel geht es um die Einwände, die Agenturen davon abhalten, diesen Schritt zu gehen, und darum, was tatsächlich funktioniert, wenn man dagegen vorgeht.

Der Einwand „Aber jeder Kunde ist anders“

Das zugrunde liegende Prinzip: Standardisieren Sie das Fundament, nicht die Oberfläche. Der Grund, die Struktur in einer gemeinsamen Bibliothek zu halten, ist genau der, die visuelle Ebene freizuhalten. Eine theme.json-Datei ist kein Design – sie ist ein Satz von Design-Tokens. Farben, Abstände und Typografie sind Werte, kein Markup. Das ist der entscheidende Wandel: Sie können das Markup teilen, während eine pro Standort angepasste theme.json die Website für eine andere Marke völlig anders aussehen lässt.

Nehmen Sie zwei Kunden: eine Anwaltskanzlei und einen Outdoor-Händler. Ihre Designsprachen liegen meilenweit auseinander. Aber beide brauchen einen Hero-Bereich, ein Testimonial-Raster, ein Call-to-Action-Band. Anstatt das Markup für jedes neu aufzubauen, pflegen Sie drei Block-Muster und lassen die theme.json jedes Kunden Farben, Schriften und Abstände definieren. Die Struktur bleibt identisch; die Design-Tokens verwandeln es von einer Marke in die andere. Wenn der Händler im nächsten Frühjahr seine Farbpalette ändert, bearbeiten Sie eine Datei auf seiner Website – nicht das Markup in sechs Vorlagen.

Praktisch bedeutet das, dass Ihr Team Muster als Code erstellt, sie in einem gemeinsamen Plugin registriert und die theme.json auf jeder Kundenseite die Gestaltung übernimmt. Die Klassennamen des Musters werden zu Ihrer Architektur; die Werte werden zu den Variablen. Sie können sogar noch weiter gehen und theme.json um benutzerdefinierte Einstellungen für Beitragstypen oder Plugin-Ausgaben erweitern, auch wenn Sie an einem bestimmten Punkt eher eine Konfigurationsoberfläche als eine Website bauen – eine Falle, die in unserem Blick auf die Erweiterung von theme.json besprochen wird. Halten Sie die gemeinsame Ebene schlank: Sie sollte nur das enthalten, was über Kunden hinweg wiederkehrt. In dem Moment, in dem Sie eine Einstellung hinzufügen, „nur falls jemand sie eines Tages will“, haben Sie eine Abstraktion geschaffen, die mehr Wartung kostet, als sie spart.

Wenn Sie einen neuen Kunden einrichten, sollten die ersten dreißig Minuten so aussehen: Klonen Sie das gemeinsame Muster-Plugin, erstellen Sie eine neue theme.json mit der Palette und dem Schriftmaßstab des Kunden und registrieren Sie dessen Logo und Footer. Das ist kein individueller Build; es ist eine Konfigurationsaufgabe. Die verbleibende kundenspezifische Arbeit fließt in Inhalte, Struktur und wirklich maßgeschneiderte Funktionen ein. Das ist der Unterschied zwischen dem Bau jedes Hauses von Grund auf und dem Besitz eines Satzes vorgefertigter Grundrisse, die Sie neu streichen und neu tapezieren können. Der Vergleich ist lose, aber das Prinzip gilt: Je mehr Sie in theme.json-Werte stecken, desto weniger müssen Sie das Markup anfassen.

Einer der einfachsten Gewinne ist, sich anzusehen, wie Block-Muster tatsächlich funktionieren. Ein Muster ist nur eine Sammlung von Blöcken mit vordefinierten Inhalten und Stilen. Sie können jede Blockkonfiguration als Muster speichern, und ein Kunde kann es einfügen, ohne zu wissen, wie es aufgebaut ist. Das bedeutet, dass das Muster zu einem „Einstiegspunkt“ für nicht-technische Benutzer wird. Wenn Ihr Team das zugrunde liegende Muster im Code pflegt, erhält der Kunde eine konsistente Bibliothek, ohne ein einziges PHP-Tag anzufassen.

Nun zur Einschränkung, auf die ich immer wieder zurückkomme: Überzentralisieren Sie nicht. Eine theme.json mit einer Einstellung für jede erdenkliche Nuance ist ein Wartungssumpf. Gemeinsame Muster sollten eine klare Meinung haben, nicht allmächtig sein. Wenn ein Kunde ein radikal anderes Layout benötigt – sagen wir eine Magazin-Startseite mit einem großen Feature-Raster – passt das möglicherweise nicht in Ihre Standard-Musterbibliothek. Das ist in Ordnung. Standardisierung bedeutet, dass Sie bei den 80 % der Projekte gewinnen, die ähnlich sind, nicht dass Sie jede Website in dieselbe Form zwingen.

Der Einwand „Individuelle Blöcke sprengen das Budget“

Hier ist ein Gegenprinzip, das langweilig klingt, aber Geld spart: Die meisten Dinge, von denen Sie denken, dass sie einen individuellen Block benötigen, tun das nicht. Kernblöcke plus ein Muster können die überwältigende Mehrheit der Layouts abdecken. Der individuelle Block ist die letzte Option, nicht die erste Absicht.

Das klassische Beispiel ist das Team-Raster. Wenn es einmalig ist, verwenden Sie die Kernblöcke „Spalten“ und „Gruppe“ und lassen Sie den Kunden das Avatar-Bild von Hand einfügen. Wenn drei Kunden dasselbe Raster mit derselben Struktur „Social-Links unter dem Namen“ anfragen, haben Sie jetzt einen Kandidaten für ein Block-Muster. Wenn dieses Muster beginnt, neue Optionen zu sammeln – Hover-Effekte, Sortierung, Bewertungssterne – wird das Muster zu einem unhandlichen Sammelsurium, und dann ist es Zeit, einen individuellen Block zu schreiben. Der budgetschädigende Fehler ist, direkt zum ersten Anfragetermin zum individuellen Block zu springen.

Eine heimtückischere Variante: Der Kunde fragt nach einem „Case-Study-Karussell“. Der erste Instinkt ist zu denken: „Ich brauche einen Karussell-Block.“ Aber braucht er ein Karussell? Vielleicht braucht er eine horizontal scrollbare Gruppe von Beiträgen, die Kernblöcke mit einem „Gruppe“-Block und etwas CSS bewältigen können. Oder vielleicht braucht er eine dynamische Liste aktueller Fallstudien, die ein dynamischer Block ist, der den CPT abfragt. Die Frage ist nicht: „Welche Funktion will der Kunde?“, sondern: „Von welchen Daten hängt sie ab?“ Wenn die Daten statisch und vom Kunden bearbeitbar sind, reicht ein Muster. Wenn die Daten aus einer Datenbankabfrage stammen, ist ein dynamischer Block gerechtfertigt. Wenn die Daten in Echtzeit von einer API aktualisiert werden müssen, könnte es sich um eine REST-API-Integration handeln – das geht in eine andere Art von Build über.

Wenn Sie einen Block bauen, ist block.json Ihr Freund. Es ist die einzige Quelle der Wahrheit für Attribute, Skripte und Stile, was den Block über Projekte hinweg portabel macht. Sie können damit auch Abhängigkeiten und Übersetzungen sauber deklarieren, was wichtig ist, wenn Sie eine Bibliothek über viele Kundenseiten verteilen. Für Inhalte, die von Live-Daten abhängen, rendert ein dynamischer Block auf dem Server, sodass Sie bei jedem Seitenaufruf kein JavaScript-Bundle ausliefern müssen. Und wenn sich Ihr Block weiterentwickelt, können Sie Deprecations elegant behandeln, sodass bestehende Inhalte nicht kaputtgehen – unser Leitfaden zur Block-Deprecation führt das genaue Muster vor.

Bevor Sie etwas bauen, ziehen Sie die Entscheidung durch dieses Raster:

Ansatz	Am besten geeignet für	Vermeiden, wenn
Kernblock	Einmalige Inhalte, einfache Seiten	Das Layout wird über viele Kunden hinweg wiederholt und benötigt umfangreiche Optionen
Block-Muster	Wiederholbare Layouts ohne Logik	Das Layout benötigt Bedingungen, dynamische Daten oder komplexe Interaktionen
Individueller Block	Wiederholtes, datengetriebenes oder hochspezifisches Verhalten	Der einzige Grund ist ein einmaliger Abschnitt, der mit einer Klasse behandelt werden kann

Sie sollten auch von Anfang an über die Benennung von Blöcken nachdenken. Ein Blockname ist im Wesentlichen ein Vertrag mit Ihrem Inhalt. Wenn Sie ihn wagent/team-grid nennen und später in wagent/team-carousel umbenennen, brechen Sie vorhandene Inhalte, es sei denn, Sie bieten einen Deprecation-Pfad. Wählen Sie generische, zweckbasierte Namen, die mit der Weiterentwicklung des Blocks keine falsche Werbung darstellen. Das ist eine Variante der Benennungsdisziplin, die wir alle aus Plugin-Präfixen gelernt haben, und sie gilt genauso für Blocknamen.

Die konträre Sichtweise hier ist das Nützlichste, was ich sagen kann: Der individuelle Block, den Sie bauen, weil ein Kunde „nur ein Teil“ angefragt hat, ist fast immer ein Fehler. Lehnen Sie höflich ab, liefern Sie einen Kernblock mit einer Klasse und sparen Sie die Stunden. Sie haben mehr Respekt beim Kunden – und eine kleinere Zeile im Wartungsbudget.

Der Einwand „Kunden werden den Editor kaputt machen“

Dieser Einwand ist zur Hälfte richtig. Der Block-Editor selbst ist nicht das Problem; das Problem ist, dem Kunden zu viel Spielraum zu geben. theme.json kann sperren, was bearbeitet werden kann: Deaktivieren Sie den Template-Editor, beschränken Sie die erlaubten Blöcke und legen Sie Standardstile fest, sodass eine falsch platzierte Spalte weniger Schaden anrichtet. Einige Kunden werden es trotzdem schaffen, Dinge zu kaputt zu machen, aber Sie können eine Seite mit einem Klick auf ein gespeichertes Muster zurücksetzen – etwas, das der klassische Editor nicht bieten konnte.

Lassen Sie mich ein Szenario schildern. Ein Kunde ruft an und sagt: „Ich habe einen Abschnitt verschoben, und jetzt sieht die ganze Seite falsch aus.“ Mit einem klassischen Theme würden Sie sich einloggen, das CSS inspizieren und wahrscheinlich eine Stunde damit verbringen, das Layout zu reparieren. Mit einem Block-Setup können Sie die Seite öffnen, den Inhaltsbereich auswählen und auf das gespeicherte Muster zurücksetzen. Das Muster ist die Basislinie; die Änderungen des Kunden sind die Überlagerung. Wenn die Überlagerung schiefgeht, entfernen Sie sie. Das ist nicht nur ein netterer Workflow; es ist ein grundlegend nachsichtigerer Editor.

Nun zur Nuance: Die meisten Kunden wollen gar nicht so viel bearbeiten. Sie wollen Text ändern, Fotos austauschen und vielleicht einen Abschnitt neu anordnen. Das Block-Muster gibt Ihnen genau das, ohne die gesamte Seitenstruktur offenzulegen. In diesem Sinne ist der Editor kein Spielzeug, sondern ein Sucher. Ihre Aufgabe ist es, zu kalibrieren, was Kunden sehen können. Das bedeutet, Sie können die Einstellungen unter „Vorlagen“ deaktivieren, den Block-Inserter auf eine kuratierte Liste beschränken und leere Muster sogar mit Platzhalterarbeit vorbelegen. Der Editor wird zu einem Formular zur Inhaltseingabe und nicht zu einer Webdesign-Leinwand.

In puncto Barrierefreiheit sind das Fokusmanagement und die Tastaturunterstützung des Block-Editors im Allgemeinen besser als die Vorlagenfelder eines klassischen Editors. Sie müssen jedoch weiterhin sicherstellen, dass Muster eine ordnungsgemäße Überschriftenhierarchie und zugängliche Namen haben. Da das Muster über Kunden hinweg geteilt wird, beheben Sie diese Probleme nur einmal, was ein weiterer verborgener Gewinn der Standardisierung ist.

Der wirklich schwierige Teil ist intern. Für Ihr Team erfordert das Erlernen des Prototypings mit Blöcken das Verlernen der Gewohnheit, „es in PHP zu machen“. Das sind echte Kosten, aber es sind einmalige Kosten pro Person. Es ist kein Grund, den Ansatz zu vermeiden; es ist ein Grund, mit einer Musterbibliothek und einem nachsichtigen Kunden zu beginnen, bevor Sie überall ausrollen. Lassen Sie nicht die Floskel „Meine Kunden kommen mit Blöcken nicht klar“ die Tatsache verbergen, dass Sie noch kein Block-Setup konfiguriert haben, das ihnen entgegenkommt.

Der Einwand „Wir haben bereits Hooks und Filter“

Das Prinzip hier ist: Sie verwerfen Hooks nicht; Sie fügen eine Ebene darüber hinzu. Blöcke sind die Präsentationsgrenze; Hooks sind weiterhin der Weg, um Logik zu injizieren. Der Render-Callback eines dynamischen Blocks läuft in PHP, was bedeutet, dass Sie dieselben Funktionen aufrufen und dieselben Filter anwenden können, denen Sie bereits vertrauen.

Stellen Sie sich ein Plugin vor, mit dem Sie über einen Filter ein Feld „Vorgestelltes Produkt“ zu jedem Beitrag hinzufügen können. Mit einem dynamischen Block können Sie einen serverseitig gerenderten Block einbinden, der diesen Filter ausführt und die Ausgabe innerhalb des Block-Wrappers ausgibt. Der Kunde fügt den Block ein; die vorhandene PHP-Logik erledigt die schwere Arbeit. Nichts wird weggeworfen. Für ein noch konkreteres Beispiel: Betrachten Sie einen individuellen Block, der kürzliche Projektbeiträge auflistet. In seinem Render-Callback rufen Sie get_posts() auf, durchlaufen dann die Schleife und wenden the_title() und the_permalink() an – dieselben Template-Tags, die Sie seit Jahren verwenden.

Hier ist auch der Ort, um ehrlich zu sein, was nicht übertragbar ist. Einige clevere alte Themes verwenden template-parts mit komplexen Bedingungen, die Argumente basierend auf dem Seitenkontext annehmen. Das als Block nachzubilden, kann unübersichtlich werden. Sie müssen es aber nicht auf einmal nachbilden. Der inkrementelle Weg besteht darin, die PHP-Logik zu behalten, sie in einen dynamischen Block zu packen und das Markup in die Blockvorlage zu verschieben. Sie werden oft feststellen, dass Ihre vorhandenen Filtermuster die neue Ausgabe verarbeiten können. Und wenn die Logik eng an eine Vorlagenhierarchie gekoppelt ist (z. B. „Bei Suchergebnissen anders anzeigen“), können Sie die klassische Vorlage für diese spezifischen Ansichten weiterhin verwenden, während Sie für normale Seiten Blöcke verwenden.

Die REST-API eröffnet auch eine andere Tür: Sie können Blöcke bauen, die Daten von anderen WordPress-Sites oder Drittanbieterdiensten abrufen. Ein dynamischer Block kann wp_remote_get() aufrufen, um JSON abzurufen und es auf der Frontend-Seite zu rendern. Das ist ein leistungsstarkes Muster für Agentur-Builds, bei denen Kunden soziale Feeds, Produktlisten oder interne Daten anzeigen möchten, ohne eine separate Integration zu verwalten. Der Kompromiss sind Caching und Fehlerbehandlung – wenn die Remote-API langsam ist, ist Ihre Seite langsam. Halten Sie API-basierte Blöcke aus kritischen Above-the-fold-Inhalten heraus oder verwenden Sie clientseitiges Rendering mit einem ordnungsgemäßen Ladezustand.

Actions und Filter laufen weiterhin rund um das Speichern und Rendern; die Hook-Architektur verschwindet nicht, wenn Sie Blöcke übernehmen, sie zieht nur in einen neuen Kontext um. Wenn Sie Ihr Verständnis darüber auffrischen möchten, wo Actions und Filter auf diese neue Blockwelt treffen, ist unser Hook-Deep-Dive eine nützliche Auffrischung.

Der Einwand „FSE ist nicht produktionsreif“

Das ist fair, aber fragen Sie, was „riskant“ tatsächlich bedeutet. Full Site Editing hat mehrere Versionen durchlaufen, und theme.json hat sich zu einem stabilen Schema entwickelt. Das Risiko besteht nicht darin, dass der Editor „plötzlich kaputtgeht“ – das Risiko besteht darin, dass Ihr eigener benutzerdefinierter Code auf alten PHP-Vorlagen basiert, die unangenehm neben Blockvorlagen existieren. Auch gehen einige Drittanbieter-Plugins immer noch vom klassischen Editor oder Customizer aus. Das ist eine Kompatibilitätsentscheidung, kein Grund, das gesamte Modell über Bord zu werfen.

Eine sinnvolle Betrachtungsweise: Einfache, wiederholbare Websites mit Inhalten in Blöcken sind am wenigsten riskant. Kunden mit stark angepassten klassischen Themes oder proprietären Plugins, die ihr eigenes Frontend rendern, sind Hochrisiko-Kunden. Das ist ein legitimer Grund, für diese kleine Nische bei klassischen Themes zu bleiben. Der Fehler ist, so zu tun, als wäre „produktionsreif“ ein einzelner Schalter, der entweder ein- oder ausgeschaltet ist.

Bevor Sie einem Kunden ein Block-Theme vorschlagen, gehen Sie eine kurze Checkliste durch:

• Hat der Kunde ein stark angepasstes Theme, das eine Migration erfordern würde?
• Unterstützen die unverzichtbaren Plugins den Site-Editor und die REST-API?
• Erlaubt die Hosting-Umgebung den Dateizugriff, den das Block-Theme erwartet?
• Haben Sie Zeit für die Muster-Design eingeplant, nicht nur für die Block-Registrierung?
• Wird das Team des Kunden die Editor-Änderungen tolerieren oder braucht es eine gesperrte Vorlage?

Wenn eine Antwort Nein ist, passen Sie den Umfang an oder verwenden Sie einen Hybrid-Ansatz. Das ist kein Kompromiss; es ist technisches Urteilsvermögen. Und wenn Sie hybrid bauen, denken Sie an die Hooks-und-Filter-Geschichte oben – Sie können alte Logik weiterhin in dynamische Blöcke packen, während die theme.json den globalen Look übernimmt.

Die Versionierung Ihrer theme.json ist nicht nur ein theoretisches Anliegen. Ich habe erlebt, wie die individuelle Blockbibliothek einer Agentur kaputtging, als der Kunde WordPress aktualisierte und der style-Block, der mit wp_register_style() unter einem geänderten Handle registriert war, Probleme verursachte. Die Lösung war einfach, aber die Panik war real. Ein einfacher Testprozess – das Update auf einer Staging-Kopie der Website ausführen, die wichtigsten Seiten durchklicken, dann veröffentlichen – löst die meisten dieser Überraschungen.

Der Einwand, den Sie sich selbst noch nicht gemacht haben

Hier ist der Meta-Einwand, der Agenturen von der Standardisierung abhält: „Es ist eine große Änderung, und während der Kundentermine ist keine Zeit dafür.“ Das stimmt – also tun Sie es nicht während der Kundentermine. Wählen Sie ein internes Projekt oder einen kleinen Kunden und bauen Sie eine Musterbibliothek auf. Verwenden Sie theme.json als System für Design-Tokens. Fügen Sie einen individuellen Block nur hinzu, wenn er gerechtfertigt ist. Wickeln Sie die alten Hooks dort ein, wo sie helfen. Iterieren Sie.

Hier ist ein grober Plan für die ersten 30 Tage:

1. Prüfen Sie Ihre letzten fünf Kunden-Builds und listen Sie die zehn am häufigsten wiederholten Layout-Teile auf.
2. Verwandeln Sie diese zehn Teile in Block-Muster, mit einer kleinen Menge an CSS-Klassen.
3. Erstellen Sie ein gemeinsames Plugin (oder mu-plugin), das diese Muster registriert. Wenn Sie noch nicht über die Plugin-Organisation nachgedacht haben, überfliegen Sie zuerst diesen Leitfaden zum Bau robuster Plugins.
4. Erstellen Sie eine theme.json, die zu Ihrem Basis-Design passt; fügen Sie kundenspezifische Werte hinzu, während Sie Projekte aufsetzen.
5. Wählen Sie ein kleines internes Projekt oder einen freundlichen Kunden und migrieren Sie es auf den Stack.
6. Dokumentieren Sie eine Heldengeschichte über einen Kunden, der seine Startseite bearbeitet hat, ohne Sie anzurufen.

Am Ende dieses Experiments haben Sie kein „Block-First“-Abzeichen, das Sie an die Wand hängen können. Sie haben ein Team, das eine neue Kundenseite von einer gemeinsamen Basis aus aufsetzen kann, ohne sich für die Timeline zu entschuldigen. Sie sind auch besser in der Lage, Nein zu der Anfrage des Kunden nach einem 42. individuellen Block zu sagen – weil Sie genau wissen, was die Kernblöcke können, oder weil Sie zeigen können, warum ein dynamischer Block tatsächlich schneller wäre.

Werden Sie trotzdem einige maßgeschneiderte Websites bauen? Ja. Manche Kunden werden immer eine individuelle Vorlage, eine maßgeschneiderte Seite oder eine proprietäre Integration benötigen, die es nicht wert ist, in das gemeinsame Modell gezwungen zu werden. Das Ziel ist nicht, maßgeschneiderte Arbeit zu eliminieren – es ist, sie zur Ausnahme statt zur Regel zu machen.

Die Wiederholbarkeit kommt von den langweiligen Teilen: einem soliden theme.json-Schema, einer klaren Musterbibliothek und der Disziplin, die gemeinsame Ebene schlank zu halten. Das ist nicht die glänzende Version, die Sie in Webinaren hören. Es ist die, die den Montagmorgen-Blues des leeren Themes besiegt.