Eigene Inhaltstypen statt Seitenbau-Chaos

Die kurze Antwort: Alles, was auf einer Website mehr als zweimal vorkommt, sollte ein eigener Inhaltstyp mit festen Feldern sein. Ein Teammitglied hat Name, Funktion, Foto, Telefon und Mail. Ein Hotelzimmer hat Größe, Belegung, Ausstattung und Bilder. Eine Stelle hat Titel, Ort, Pensum und Ansprechperson. Wer das als Formular anlegt, statt jede Karte im Builder einzeln zu bauen, bekommt eine Website, die die Redaktion selbst pflegen kann.

Der typische Weg sieht anders aus: Die Teamseite wird im Builder gestaltet, jede Person ist ein Block aus Bild, Überschrift und Text. Das sieht beim Launch gut aus. Ein Jahr später sind drei Karten etwas anders formatiert, weil drei verschiedene Leute sie kopiert haben, die neue Kollegin fehlt auf der Startseite, weil sie dort ein zweites Mal eingetragen werden müsste, und eine Sortierung nach Abteilung ist nicht möglich, weil es keine Abteilung gibt, nur Text. Wir nennen das Seitenbau-Chaos. Es ist kein Fehler einzelner Redakteure, sondern eine Folge der Architektur.

WordPress hat für dieses Problem eine eingebaute Antwort. Neben den fünf Standard-Inhaltstypen Beitrag, Seite, Anhang, Revision und Menü lassen sich eigene Inhaltstypen registrieren ^[2]. WordPress speichert sie in derselben Tabelle wie Beiträge und Seiten ^[1]. Die zusätzlichen Angaben wie Funktion oder Zimmergröße hängen als Metadaten am jeweiligen Eintrag, also als Information über die Information ^[3].

Zu Inhaltstypen gehören meist Taxonomien, also eigene Kategorien: Abteilung beim Team, Branche bei Referenzen, Region bei Standorten. Sie machen aus einer Liste etwas, das sich filtern lässt, und sie sind der Grund, warum eine Startseite später „die drei neuesten Referenzen aus dem Tourismus“ zeigen kann, ohne dass jemand sie dort von Hand einträgt.

Ein Inhaltstyp allein ist nur Datenhaltung. Sichtbar wird er über zwei Werkzeuge in Bricks. Die Abfrage-Schleife, in Bricks „Query Loop“, holt Einträge eines oder mehrerer Inhaltstypen und wiederholt ein gestaltetes Element für jeden Treffer ^[4]. So entsteht die Teamübersicht, die Referenzliste oder der Zimmerfilter, ohne dass jemand einzelne Karten baut. Die dynamischen Daten setzen die Feldinhalte in dieses Element ein, also Namen, Bild, Funktion oder Preis-Hinweis ^[5].

Bricks liest dabei Felder aus den verbreiteten Feld-Plugins, etwa Advanced Custom Fields, Meta Box, Pods oder Toolset, und auch native WordPress-Felder ^[5]. Wir arbeiten mit ACF Pro. Für die Detailansicht eines Eintrags, zum Beispiel die Seite eines einzelnen Zimmers, gestalten wir eine Vorlage, die für alle Einträge des Inhaltstyps gilt.

Was Ihr Kunde davon merkt: Im Backend steht in der Seitenleiste ein Punkt „Team“ oder „Zimmer“, dahinter ein Formular mit genau den Feldern, die es braucht, und Hinweisen, welches Bildformat passt. Kein Builder, keine Abstände, kaum etwas, das sich versehentlich verschieben lässt. Das hält die Einarbeitung kurz und senkt die Zahl der Rückfragen.

Eigene Inhaltstypen registrieren wir in einem eigenen kleinen Plugin, nicht im Theme. Das WordPress-Handbuch empfiehlt genau das, damit Inhalte auch nach einem Theme-Wechsel übertragbar bleiben ^[2]. Warum uns das wichtig ist, steht im Artikel WordPress mit Bricks ohne Lock-in.