WordPress mit Bricks: Warum wir ohne proprietäres Theme bauen

Wir bauen WordPress-Seiten mit Bricks und halten Layout und Inhalt auseinander. Das Layout entsteht in Bricks, Team, Referenzen und andere wiederkehrende Inhalte liegen in den Strukturen, die WordPress selbst vorsieht: eigene Inhaltstypen, Felder, Beiträge und Medien. Wechselt Ihr Kunde in drei Jahren die Agentur, findet die neue Agentur seine Inhalte dort, wo jede WordPress-Entwicklerin sie sucht. Genau das meinen wir mit „kein Lock-in“.

Warum das zählt: WordPress läuft auf 39,5 % aller Websites und auf 58,3 % der Websites mit bekanntem Content-Management-System ^[4]. Für Ihren Kunden heißt das, dass er praktisch überall jemanden findet, der WordPress kann. Dieser Vorteil schrumpft, sobald die Inhalte in einem Format stecken, das nur ein bestimmtes Theme versteht. Dann kann zwar jeder WordPress, aber nicht jeder genau diese Seite.

Mit „proprietärem Theme“ meinen wir ein Theme, das Inhalt, Gestaltung und Funktion in einem Paket bündelt: Inhaltstypen, die das Theme selbst registriert, Module, die nur das Theme ausgibt, Einstellungen, die an seine Optionsseite gebunden sind. Das ist bequem, solange alles bleibt, wie es ist, und es gibt gute Themes dieser Art. Teuer wird es beim ersten Relaunch, weil die Inhalte erst wieder freigelegt werden müssen.

Bricks ist ein Theme mit eingebautem visuellem Builder. Was im Builder entsteht, speichert Bricks als eigene Daten zum jeweiligen Beitrag, getrennt vom normalen WordPress-Inhalt. Ein Beitrag kann WordPress-Inhalt, Bricks-Daten oder beides haben. Stellt man die Darstellung auf WordPress um, bleiben die Bricks-Daten gespeichert, die Seite zeigt aber den WordPress-Inhalt ^[1].

Wir nutzen diese Trennung bewusst. Einzelseiten wie Startseite, Leistungsseiten oder Kampagnenseiten bauen wir in Bricks. Wiederkehrende Inhalte wie Team, Referenzen, Zimmer, Stellen oder Veranstaltungen legen wir als eigene Inhaltstypen mit Feldern an und gestalten sie über eine Bricks-Vorlage, die diese Felder als dynamische Daten ausliest ^[5]. Der Inhalt steckt dann in Feldern, nicht im Layout. Wer später ein anderes Theme einsetzt, baut die Vorlage neu, tippt diese Inhalte aber nicht neu ein. Wie das im Detail aussieht, steht im Artikel Eigene Inhaltstypen statt Seitenbau-Chaos.

Die Inhaltstypen selbst registrieren wir nicht im Theme, sondern in einem eigenen kleinen Plugin. Das empfiehlt auch das WordPress-Handbuch, damit Inhalte beim Wechsel des Themes erhalten bleiben ^[2].

Ganz ohne Aufwand ist kein Wechsel, das sagen wir offen. Will eine Nachfolge-Agentur Bricks nicht weiterverwenden, muss sie die Layouts der in Bricks gebauten Seiten neu umsetzen und deren Texte übernehmen. Die wiederkehrenden Inhalte aber liegen frei, und das ist bei einem Relaunch meist der teure Teil. Bleibt die Nachfolge bei Bricks, kann sie die Vorlagen als JSON exportieren und in einer neuen Installation weiterverwenden ^[3].