Große Mängel bei der Erstellung von Block-Themes

In den letzten Monaten habe ich einige Male mit Block-Themes für WordPress gearbeitet. Und während ich mich daran gewöhnt habe, habe ich auch einige Probleme erlebt, über die ich sprechen möchte. Ich möchte klarstellen, dass nicht alles an Block-Themes schlecht ist, aber es gibt dir eine Vorstellung einiger grundlegender Probleme mit ihnen und einem möglichen Grund, warum sie so langsam von Theme-Erstellern adaptiert werden.

Template-Teile

Wenn es um Template-Teile geht, habe ich ein paar Probleme mit ihnen. Da diese vollständig innerhalb des Website-Editors verändert werden können, sind sie praktisch nur Text, also statisch. Du kannst ihnen keine Logik beibringen, da diese dynamisch wäre.

Nicht übersetzbar

Das heißt, Template-Teile sind praktisch nicht übersetzbar. Wenn du eine mehrsprachige Website mit beispielsweise Polylang oder WPML betreibst, würdest du jeden Template-Teil in jeder Sprache mit statischem Text benötigen.

Vordefinierte Bilder

Dasselbe Problem hast du auch mit vordefinierten Bildern in Template-Teilen. Du kannst hier keine dynamischen Inhalte verwenden (was erforderlich wäre, um die richtige Bild-URL zu erhalten) und kannst deshalb keine vordefinierten Bilder in Template-Teilen verwenden.

Referenzen

Was uns zum grundlegenden Problem mit Referenzen bringt. Der Navigationsblock beispielsweise benutzt eine Referenz zu einem Navigationsobjekt, um eine Navigation an mehreren Stellen verwenden zu können. Du kannst allerdings in einem Template-Teil keine Referenzen zu solchen Objekten erstellen (und auch nicht zu irgendwelchen anderen dynamischen Inhalten). Das heißt, du kannst nur eine neue Navigation erstellen, wenn du einen Template-Teil mit einer Navigation hinzufügst. Und das gilt für alle Blöcke, die eine Referenz erfordern.

Korrigiere es mit Vorlagen?

Man mag meinen, dass diese Probleme mit Vorlagen aka Block Patterns gelöst werden können. Das stimmt, wenn es darum geht, sie beim Einfügen dynamisch zu haben. Du kannst PHP-Code in Vorlagen ausführen, aber sobald sie in den Block-Editor eingefügt wurden, sind sie wieder statisch. Und nicht nur das, sie haben keine Referenz mehr zu ihrer Vorlage. Das heißt, änderst du die Vorlage, musst du auch alle Bereiche ändern, in die du vorher die Vorlage eingefügt hast – manuell.

Template-Erstellung außerhalb des Block-Editors

Da Templates nun Blöcke sind, muss auch die Erstellung von Templates außerhalb des Editors im Block-Markup vorliegen. Während es verhältnismäßig trivial ist, ein Template für einen Absatz-Block zu erstellen und zu bearbeiten, ist das für komplexere Blöcke schwieriger bis unmöglich. Außerdem erfordert es viel Erfahrung in der Verwendung von Blöcken, wenn du alle Änderungen selbst vornehmen möchtest.

Und wenn du es nicht richtig machst, musst du dafür beten, vom Block-Editor eine Fehlermeldung zu bekommen, die aussagekräftig ist (was übrigens für alle Fehlermeldungen des Block-Editors gilt).

Oftmals, insbesondere wenn du den Block nicht auswendig kennst, hast du keine andere Möglichkeit, als das Template oder den Template-Teil innerhalb des Block-Editors hinzuzufügen oder zu bearbeiten und ihn dann von dort herauszukopieren. Dann musst du immer noch sicherstellen, alle Referenzen innerhalb der Blöcke zu entfernen, die nur in dieser WordPress-Instanz vorhanden sind, wenn du das Theme danach teilen willst. Das macht den ganzen Workflow ziemlich kompliziert, insbesondere nachdem du dein Theme veröffentlicht hast und sicherstellen musst, dass immer die neueste Version deiner Templates geteilt wird (und am besten auch, dass bestehende veraltete Templates und Template-Teile nicht das Aussehen komplett zerstören).

theme.json-Dokumentation (gewissermaßen)

Während ich den Beitrag Ende letzten Jahres angefangen habe, konnte ich einige Dokumente zur theme.json finden. Allerdings waren die alle nicht ansatzweise vollständig und mehr nur beispielhaft dafür, wie man die theme.json verwendet. Glücklicherweise hat sich das geändert und wir haben nun hier eine richtige Dokumentation:
https://developer.wordpress.org/themes/global-settings-and-styles/

Allerdings ist es nach wie vor eine steile Lernkurve und die theme.json nicht immer selbsterklärend verwendbar. Auch wenn es um das Styling einzelner Blöcke geht, musst du dich praktisch zwangsweise testen, was funktioniert, oder direkt in den Quellcode des Blocks schauen, um zu sehen, was für Styling er unterstützt.

Beschränkter Query-Block

Für den Query-Block, der für die automatisierte Ausgabe von Beiträgen eines Inhaltstyps verwendet wird, gibt es schlichtweg nicht genügend Optionen. Du kannst den Inhaltstyp festlegen, die Reihenfolge und ob angepinnte Beiträge beachtet werden sollen. Außerdem die Anzahl der angezeigten Beiträge pro Seite, das Offset und die maximale Anzahl an anzuzeigenden Beiträgen. Und das war’s. Wenn du mehr benötigst, musst du es manuell hinzufügen, was umständlich wird. Du hast demnach nur einen sehr beschränkten Query-Block zur Verfügung, insbesondere wenn du ihn mit klassischen Themes vergleichst, bei denen du nur etwas PHP verwenden musst, um das volle Potenzial eines WP_Query-Objekts ausschöpfen zu können.

Nur einen minimalen Teil dafür zu haben macht die UI leichtgewichtig, aber raubt dem Ersteller auch viele Möglichkeiten.

Wo was geändert werden muss

Bei der Verwendung eines Block-Themes hast du immer die Möglichkeit, eine Seite oder die Website zu bearbeiten. Selbst für mich als Entwickler ist es nicht immer klar, wo ich nun was bearbeiten kann. Und ich habe es jetzt mehrfach erlebt, dass auch andere Personen damit ihre Probleme haben. Während es zum einen durchaus praktisch sein kann, dass man nun auch Templates und Template-Teile bearbeiten kann, ohne direkt das gesamte Theme zu bearbeiten, so muss man zuerst einmal das Konzept dahinter verstehen. Und viele wollen lediglich die Seite bearbeiten, die sie vor sich sehen, ohne wissen zu müssen, wie das Ganze im Hintergrund funktioniert, was ich vollkommen verstehen kann.

Ich denke, eine bessere Herangehensweise wäre hier, dass man eine Seite als ganzes Bearbeiten kann, während man bei Bereichen, die Teil eines Templates sind, ein Popup mit einem Hinweis erhält, dass dieser Teil auch auf anderen Seiten verwendet wird. Das wäre dann ähnlich zu der Bearbeitung synchronisierter Blöcke.

Zusätzlich ist man aktuell beim Bearbeiten eines Template-Teils in einem komplett anderen Kontext, da man dabei die ganze Seite gar nicht mehr sieht, sondern nur jenen einen Template-Teil.

Fazit

Es gibt definitiv einige Vorzüge in der Verwendung von Block-Themes, die ich durchaus mag. Allerdings gibt es auch einige, die ich nicht gut finde, wie oben beschrieben. Für viele davon wird es vermutlich keine schnelle Änderung in nächster Zeit geben, wenn überhaupt. Denn das würde einige fundamentale Änderungen erfordern und es wäre ziemlich komplett, insbesondere wenn man die Abwärtskompatibilität halten möchte (nicht dass das gesamte Gutenberg-Projekt großartig an Abwärtskompatibilität interessiert wäre, aber das ist eine andere Geschichte).

Aktuell kann ich den meisten Benutzern nicht empfehlen, Block-Themes zu erstellen. Sie lassen den Ersteller nicht nur mit einigen großen Hürden zurück, sondern auch mit einer schlechten Benutzererfahrung danach während der Verwaltung des Themes.

Wie siehst du das Ganze? Wie ist deine Meinung zu Block-Themes?