Gutenberg: Die Zukunft von Themes?
2020
Mit der Ankündigung des neuen Blockeditors in WordPress standen die Zeichen an der Wand: Was wird aus den WordPress Themes? Denn, wozu noch Theme Templates verwenden, wenn man jede Seite mit den entsprechenden Blöcken einfach entsprechend einrichten könnte?
Gutenberg gibt der Editorin ungewohnte Freiheiten (zumindest wenn man vom bisherigen TinyMCE kam) und eine Vielfalt von Möglichkeiten. Diese Möglichkeiten beschränken sich bisher allerdings auf ein kleines Rechteck, in welcher von den Theme Templates der Inhalt des Beitrags ausgegeben wird.
Themes anpassen mit Hilfe von Child-Themes
Sidebar, Footer, Header und andere Elemente werden derzeit von den Template Dateien des Themes bestimmt und sind nicht von Redakteurinnen oder Administratorinnen veränderbar. Will man das Theme selbst anpassen muss man heute über das sogenannte Konzept der Child-Themes gehen. Das heißt im Wesentlichen selber ein Theme zu entwickeln und dieses in Abhängigkeit eines anderen Themes stellen. Es klingt komplizierter als es ist, hat aber seine eigenen Probleme.
Wenn man nun all diese Elemente, welche derzeit von einem Theme festgelegt werden, selbst als einen Block betrachten würde… Statt irgendwelche komischen PHP-Dateien im Trial-and-Error-Verfahren schreiben zu müssen und dann über FTP in irgendein komisches Verzeichnis auf so einem „Server“ laden zu müssen… Wäre es da nicht schöner diese ganzen Blöcke über ein modernes Interface einfach hin und herschieben, löschen und erstellen zu können?
Blockbasierte Themes
Genau dahin scheint die Reise zu gehen. Im Gutenberg Handbuch findet sich mittlerweile eine Sektion „Block-based Themes“. Das Konzept befindet sich derzeit in der Experimentierphase und es wird sicherlich an einigen Schrauben noch gedreht werden müssen, bis alles passt, aber grob geht es um Folgendes:
Templates in einem Theme sind nicht mehr länger PHP-Dateien, sondern HTML-Dateien, welche die HTML-Syntax von registrieren Blöcken enthalten. Über die bisherigen Blöcke wie „Absatz“ oder „Überschrift“ würde WordPress nun weitere Blöcke zur Verfügung stellen wie „Post Content“ oder „Post Title“, welche in diesen Templates als Platzhalter für beispielsweise den Inhalt oder den Titel eines Beitrags dienen würden.
Bisher befindet sich dies alles in einem experiementellen Stadium. Möchte man es allerdings ausprobieren, so kann man derzeit das Gutenberg Plugin herunterladen und unter Gutenberg > Experiments die Sektion „Enable Full Site Editing“ aktivieren:
Achtung: Dies sollte wirklich nur in einer Testumgebung gemacht werden, denn die Folge davon ist, dass letztlich jedes normale Theme nicht mehr dargestellt wird und, wie gesagt, blockbasierte Themes ein Experiment darstellen!
Johannes. Ein blockbasiertes Theme
Mel Choyce, eine Designerin für WordPress, hat ein derartiges Theme schon einmal entwickelt, mit dessen Hilfe man sich einen Eindruck verschaffen kann: Johannes. Noch sind viele Blöcke, welche nötig wären, um ein komplettes WordPress Theme zu erstellen, nicht vorhanden, doch das Theme zeigt schon recht gut, wohin die Reise gehen kann.
Blockbasierte Themes anpassen
Das spannende an diesem Experiment ist nun eigentlich nicht das Theme selbst, sondern wie man dieses Theme jetzt im WordPress Admin selbst gestalten kann. Denn die Template-Dateien des Themes können nun komplett im WordPress Admin mit Hilfe von Gutenberg überschrieben werden!
Hat man den Full Site Editing Modus aktiviert finden sich zwei neue Menüpunkte unter Design: „Templates“ und „Template Parts“. Hier kann man nun neue Themetemplates erstellen. Würde man beispielsweise ein Themetemplate „Index“ erstellen, so würde dies das index.html-Template vom Theme überschreiben.
In diesem Video stelle ich das Feature kurz vor:
Auf der Grundlage von Mel Choyce‘ „Johannes“ Theme habe ich lokal schnell mal mein eigenes Websupporter Theme umgestellt und versuche es nun mit Hilfe von Gutenberg zu verschönern.
Was haben Themes denn noch zu tun?
Wenn ich nun mit Hilfe von Gutenberg das Theme beliebig gestalten kann, wozu braucht es überhaupt noch ein Theme? Nach wie vor ist das Theme für das Styling der Seite verantwortlich. Es definiert Abstände, Farben, Schriftarten und so weiter und definiert das Aussehen der einzelnen Core Blöcke.
Das ist nicht gerade wenig. Darüber hinaus denke ich, dass Themes jede Menge von Block-Styles zur Verfügung stellen müssen. Nehmen wir das leidige Thema Menüs. Der WordPress Core stellt einen Menüblock zur Verfügung. Doch wenn wir über moderne Webseiten gucken, dann findet man da selten einfach nur ein Menü. Häufig findet sich irgendwo ein „Social“-Menü, ein Hauptmenü, ein Footermenü und so weiter und so fort. All diese Menüs sind üblicherweise unterschiedlich gestaltet. Das Hauptmenü ist häufig eine Leise von Menüpunkten, während das Footermenü eher einer Liste von vertikal angeordneten Menüpunkten entspricht. Diese verschiedenen Styles würden vermutlich von Themes bereitgestellt werden.
Darüber hinaus bieten die Template-Dateien von block-basierten Themes natürlich das erste Gerüst, welches die einzelnen Blöcke und Styles in ein harmonisches Miteinander bringen. Aus meiner eigenen Erfahrung wirklich nicht gut im bestimmen von Abständen, Whitespaces, Größen und Breiten, kurz, nicht wirklich gut im Designen zu sein: Administratorinnen und Administratoren wollen sich vermutlich nur selten das komplette Design antun.
Meines Erachtens werden wir auch in Zukunft nach einem schönen Theme Ausschau halten und dieses dann kurz an unsere eigenen Bedürfnisse anpassen wollen. Was denkt Ihr? Welche Zukunft haben Themes in einer blockbasierten WordPress-Welt?
Tolle und hilfreiche Einführung zum Thema! Das sieht doch alles überschaubar aus und bietet bisher Hoffnung für, lassen wir sagen, Entwicklerinnen die sich hauptsachlich auf Themes fokussieren.
Danke. Ja, irgendwie reduziert es Themes auf das Wesentliche 🙂
Hallo David, was mir in der Diskussion „Themes werden sterben“ fehlt ist der finanzielle Aspekt: was werden Themes, die aus wenigen Zeilen HTML-Code und einem mehr oder weniger großen (modularem? SASS?) Stylesheet bestehen, den Anwender kosten? Werden Anwender bereit sein, „nur für Stylesheets“ 70$ oder mehr zu zahlen? Wird es Multipurpose-Themes geben? Oder Themes mit eigenen Blöcken – und dem bisher oft diskutierten Lock-In-Effekt? Oder wie grenzen sich Theme-Entwickler künftig von ihren Mitbewerbern ab? Es bleibt spannend.
Hi Bego.
Ich weiß es nicht. Ich kann mir vorstellen, dass es für Multipurpose Themes schwieriger wird und Aspekte wie „Das sieht aber hübsch aus“ bei der Wahl des Themes noch stärker in den Vordergrund rücken. Wobei ich mir durchaus Themes vorstellen kann, die auch mit 20.000 Styleeinstellungen daherkommen, wie ja letztlich derzeit auch, oder auch Themes, die quasi mit „Style A“, „Style B“, „Style C“ drei Themes auf einmal sind :affe_sieht_nix:
Themes mit Blöcken? Darauf wette ich, warum sollte sich nur wegen einer neuen Technik plötzlich alle auf deren „best practices“ einstellen? Wurde vorher ja auch nicht gemacht.
Tatsächlich glaube ich, je länger ich darüber nachdenke, dass Themes eben nicht tot sind. Wäre ich ein professioneller Themeentwickler würde ich mein Geschäft jedenfalls nicht an den Nagel hängen. Aber spannend bleibt es allemal.
Veränderungen wird es sicherlich geben. Aber ob Themes deswegen anders werden oder gar nicht mehr nötig sind. Wer weiß das schon. Die Entwicklung von WordPress ist immer vorrangeschritten.
Ich weiß noch vor einigen Jahren war der Aufschrei wegen Gutenberg als Editor groß. Viele wollten den Editor patu nicht haben. Dabei lieferte er damals schon sehr viele Vorteile!
Heute ist mit den Blöcken vieles einfacher geworden. Im Grund kann Jeder ohne Kenntnisse von HTML/CSS/PHP mittels ein paar Blöcken und vielleicht noch dem Costomizer für die Feinheiten eine tolle Webseite gestalten.
Ich glaube die Themes werden dennoch nicht ganz wegfallen. Warum? Nun gerade die Premium Versionen bieten viele Vorteile für den Laien, um genau das zu schaffen, was der Einzelne benötigt. Mit ein paar Plugins können da schon tolle Webseiten zusammengestellt werden.
LG
Ronny
Hi Ronny,
ich halte den Totengesang auch für verfrüht. Selbst wenn man ganz simple blockbasierte Themes annimmt übernehmen sie in dem Konzept doch noch immer eine ganz entscheidende Funktion ein. Sie bestimmen über Farben, Formen, Abstände und insgesamt über das Design und den Eindruck einer Seite. Ich glaube sogar, dass die Entwicklung eines guten blockbasierten Themes eine komplexere Angelegenheit ist als die Entwicklung eines herkömmlichen Themes. Das Design muss sich nun in einer sehr viel dynamischeren Umgebung bewähren, was in meinen Augen gar nicht so einfach ist.
Interessant, gibt es dazu schon einen groben Zeitplan ab wann es das geben könnte?
Wird dadurch die Seite langsamer?
Hi Stefanie,
danke für Deinen Kommentar. Das Projekt gehört zu der zweiten Phase der Gutenberg-Implementierung. Phase eins war der Gutenberg Editor selbst. In der zweiten Phase geht es nun darum, diesen Editor auf andere Bereiche der Webseite zu erstrecken. Phase drei soll die Möglichkeit eröffnen, dass mehrere Personen gleichzeitig an einem Dokument schreiben können und schließlich in der vierten Phase soll es um Mehrsprachigkeit gehen. Ich habe jetzt nochmal geguckt, aber nicht wirklich gefunden, wann diese zweite Phase abgeschlossen sein soll. Mein Tipp wäre Ende diesen Jahres oder irgendwann im Laufe des nächsten Jahres.
Erstmal von meinem Gefühl her: Als ich das an meiner Seite ausprobiert hatte, hatte ich keine Unterschiede in den Ladezeiten gefühlt. Ich hatte auch einmal einen kursorischen Blick über den Code geworfen und da keinen Grund gefunden, weshalb die Seite signifikant langsamer werden sollte. Von meinem Verständnis her: Letztlich wird hier ein Konzept, welches schon in WordPress vorhanden ist nur „ein wenig“ erweitert. Statt nur die Blöcke im Inhaltsbereich zu rendern müssen nun eben noch ein paar Blöcke außerhalb dieses Bereichs gerendert werden. Da Gutenberg bei der Einführung keine signifikanten Auswirkungen auf die Ladezeit im Frontend hatten, müsste man schon einiges falsch machen, wenn dem jetzt so wäre.
Hallo, David,
vielen Dank für den Artikel und für das Video.
Ich werde das gleich mal ausprobieren!
„(…) Themes, die aus wenigen Zeilen HTML-Code und einem Stylesheet bestehen (…)“
Ich fänd das toll.
Ich weiß, CSS ist nicht besonders hoch angesehen, gerade unter den „harten Jungs“.
Aber gutes CSS zu schreiben ist nicht leicht. Ich sehe viel fürchterliches CSS, auch und gerade von Menschen, die einen Developer-Hintergrund haben.
CSS hat sehr viel mit Struktur und Planung zu tun. So wie gutes Design auch.
Damit eine Website gut aussieht, konsistent in der Bedienung ist und die Inhalte gut lesbar präsentiert braucht es Struktur und Planung. Man sieht davon von aussen nix, aber die Struktur ist da und trägt das Ganze. CSS und Design sind immer etwas mehr als nur „hübsch“.
***
Ich kann mir übrigens nicht vorstellen, dass ein Theme wirklich nur noch aus einem Stylesheet und ein bisschen HTML bestehen wird. Auch ein block-basiertes Theme braucht eine Farbpalette, spezielle Styles für Blöcke, zusätzliche Blöcke und Funktionen. Da wird’s schon ein bisschen was an Coding zu tun geben. Und genügend Raum, sich von Mitbewerbern abzusetzen.
***
Ein Argument, das man im Zusammenhang vom Konzept der block-basierten Themes immer wieder hört, ist, dass die Anwender damit ganz viele fürchterliche Websites bauen werden, weil sie schnell und einfach unter der Haube rumschrauben können.
Aber das wäre nichts Neues, das passiert jetzt schon.
Themes, die aus PHP-Templates bestehen, können die Anwender zwar vielleicht nicht direkt bearbeiten. Aber sie können sich einen PageBuilder installieren. Der transferiert sämtliche Optionen auf eine Benutzeroberfläche. Es gibt für alles ein Dropdown oder ein Häkchen.
Damit kann sich jede/r eine Website bauen. Manche haben dabei ein gutes Händchen, mache bauen damit gruseliges Zeug.
Wenn die Theme-Basis einfacher zugänglich wird, ändert sich am Output wenig, die Veränderung betrifft eher die Tools. Also in diesem Fall die PageBuilder. Die werden die Anwender irgendwann nicht mehr brauchen.
Schöne Grüße
von Kirsten
Hi Kirsten,
vielen Dank für Deinen Kommentar!
Aber gutes CSS zu schreiben ist nicht leicht. […] CSS hat sehr viel mit Struktur und Planung zu tun. So wie gutes Design auch. CSS und Design sind immer etwas mehr als nur „hübsch“.
Danke Dir, dass Du da nochmal den Finger draufzeigst und entschuldige dann auch gleich die flapsige Ausdrucksweise meinerseits. Design ist ein Feld, das mir tatsächlich einfach fremd ist. Da habe ich zwei linke Hände. Und CSS ist eine Programmiersprache und nicht die leichteste unter den vielen, die sich da so finden. Würden Themes nur aus HTML und CSS bestehen wäre das eigentlich schon komplex genug. Wenn man drüber nachdenkt hat WordPress da einen massiven Overhead drüber, der eigentlich weg müsste.
Ich glaube Farbpalette und Styles wären die zentralen Elemente, welche ein Theme nutzen müsste. Blöcke werden ja allgemein als „Pluginterritory“ begriffen, weil man ja einfach fähig sein soll das Theme zu wechseln, ohne das etwas kaputt geht. Interessant ist hier der Gedanke, das Themes Blockabhängigkeiten definieren können sollten, was glaube ich, in eine interessante Richtung zeigt.
XD
Liebe Grüße,
David.
„entschuldige dann auch gleich die flapsige Ausdrucksweise meinerseits“
War nicht böse gemeint. Anwesende sind ausserdem ausgenommen :o)
Stimmt, Blöcke sind Plugin-Territory. Es wird wahrscheinlich auf so Kombis hinauslaufen aus Theme und Block-Plugin. So wie man es ja schon oft sieht (Go-Theme/CoBlocks, Aino-Theme/Aino-Blocks usw.).
Das mit den Blockabhängigkeiten hatte ich noch gar mitgekriegt. Danke für den Link, das Blog kommt gleich in meinen Feed-Reader.
Wenn mit Full Site Editing und einem großen Blockverzeichnis die Themes und vor allem Page Builder an Relevanz verlieren, hört evtl. auch der „Wildwuchs“ an Themes und Page Buildern auf. Das hätte den Vorteil, dass wir WordPress Dienstleinster uns nicht jedes mal in ein neues Theme oder Page Builder einarbeiten müssen, wenn ein Kunde von uns ein uns bisher Unbekanntes im Einsatz hat.
Außerdem wird dadurch vielleicht der Einstieg für WordPress Anfänger einfacher, weil sie schon mit „Boardmitteln“ sehr viel machen können und sich nicht erst in die verschiedenen Page Builder einarbeiten müssen.