In der jährlichen State of the Word Präsentation auf dem WordCamp US 2016 kündigte der WordPress Mitbegründer Matt Mullenweg an, wieder die Leitung der WordPress-Produktentwicklung zu übernehmen und dabei drei Hauptfokusse zu haben. Die REST-API, den Editor und den Customizer. Die drei Bereiche bilden die Grundlage für das Projekt mit dem Codenamen „Gutenberg“. Dieses Projekt hat es sich zum Ziel gesetzt das Erstellen und Verwalten von Inhalten auf Webseiten möglichst einfach und intuitiv zu gestalten. Aktuell gibt es viele verschiedene Konzepte (Beiträge, Widgets, Shortcodes, Menüs, Benutzerdefinierte Felder …) um Inhalte zu verwalten und die Art von Inhalten hat sich in den letzten Jahren immer weiter diversifiziert. Gutenberg soll die Grundlage für die nächsten Jahre in WordPress und somit für 30% des Internets schaffen. Die Entwicklungsphase von Gutenberg kann dabei in drei Schritte unterteilt werden.
Blöcke als Bausteine
Der erste Schritt, der mit WordPress 5.0 kommen wird, widmet sich der Erstellung und dem Bearbeiten von Beitrags- und Seiteninhalten und liefert die Grundlagen für die nächsten beiden Schritte.
Das grundlegende Konzept von Gutenberg haben wir vor zwei Wochen bereits erklärt. Alles ist aus Blöcken aufgebaut und jeder Block hat spezifische Eigenschaften, die individuell angepasst werden können. Blöcke können beispielsweise ein Text, eine Tabelle, ein Video, ein Tweet oder eine Liste von Beiträgen sein. Dies sind nur einige wenige Beispiele, die von Haus aus mitgeliefert werden. Da WordPress sehr leicht erweiterbar ist, kann jedes Theme und jedes Plugin bestehende Blöcke anpassen oder auch neue Blöcke mitliefern. Denkbar wären hier beispielsweise ein Block für Google Maps, eine Slideshow, ein Formular oder eine WooCommerce-Produktliste. Den Entwicklern sind hier keine Grenzen gesetzt, diverse Filter und Hooks bieten eine mächtige Schnittstelle für Erweiterungen.
Diese Blöcke können beliebig angeordnet werden, sei es untereinander, nebeneinander oder ineinander verschachtelt. Sie können auch global abgespeichert und in verschiedenen Seiten einfach wiederverwendet werden. Dynamische Blöcke bieten die Möglichkeit Inhalte nicht vorher zu definieren, sondern erst beim Laden der Seite zu berechnen und individuell für jeden Benutzer anzuzeigen.
Der Editor als Baukasten
Um diese Blöcke erstellen und bearbeiten zu können, wird der neuer Editor entwickelt. Bei der Entwicklung wird darauf geachtet, dass alles intuitiv und barrierefrei bedienbar ist. Als Autor sieht man sofort beim Erstellen in einer Vorschau, wie der Block später aussehen wird und kann die Inhalte beliebig anpassen. Je nach Block und Kontext werden verschiedene Optionen und Werkzeuge bereitgestellt. Bestehende Inhalte, die im alten Editor angelegt wurden, können weiterhin bearbeitet werden und sind einfach in Blöcke umwandelbar. Es wird auch Copy & Paste aktiv unterstützt, damit beispielsweise Inhalte aus Word oder Google Docs automatisch erkannt und in die jeweiligen Blöcke umgewandelt werden. Bilder sind einfach per Drag & Drop zu Galerien hinzufügbar oder können als Coverbild mit individuellen Texte und Buttons angepasst werden. Ein weiterer Unterschied zur bestehenden Lösung ist, dass der neue Editor vom ersten Moment der Konzeption an schon auf responsive Design hin entwickelt wird, damit die Erstellung und das Bearbeiten von Inhalten endlich auch auf mobilen Geräten ohne Einschränkung möglich wird.
Dies sind nur einige wenige Eigenschaften und Funktionen des neuen Editors. Noch ist nicht alles umgesetzt, einige Funktionen sind auch noch fehlerhaft. Den aktuellen Stand der Entwicklung könnt ihr euch im Video der diesjährigen State of the Word anschauen. Dort präsentierte Matías Ventura, der Designleiter von Gutenberg, ab Minute 35:00 die Version 1.8 und einige Funktionen die in den nächsten Wochen noch kommen werden. Wer sich eine Testumgebung aufsetzen kann oder eine Installation hat, auf der er den Editor ausprobieren möchte, kann sich schon den aktuellen Stand von Gutenberg als Plugin aus dem Verzeichnis auf einer Website installieren. Es wird allerdings davon abgeraten das Plugin bereits auf einer produktiven Website einzusetzen.
Themes und Customizer
Neben der kontinuierlichen Weiterentwicklung des Editors werden nun die nächsten Phasen gestartet, die nahtlos ineinander übergehen, da auch sie voneinander abhängen. In diesen Schritten kommen die Bereiche Customizer und Themes als Bestandteile von Gutenberg hinzu.
Aktuell besteht nur der Inhalt des Editors aus Blöcken, Ziel ist es aber die vollständige Webseite aus Blöcken aufzubauen und durch den Customizer verwaltbar zu machen. Logos im Header, Menüs, Inhalte in der Sidebar, Header oder Footer werden Blöcke werden. Ob Widgets durch Blöcke abgelöst, Blöcke als Widgets genutzt oder Widgets auch als Blöcke verwendet werden können, ist dabei im Moment noch offen.
Mit diesem Konzept wäre dann auch ein Frontend-Editor umsetzbar, sodass man sofort sehen kann, wie die Inhalte der Website auf Smartphone, Tablet oder am Desktop dargestellt werden.
Themes könnten beispielsweise feste Listen von Blöcken bereitstellen, die der Benutzer dann nur noch ausfüllen muss. Dies kann anhand eines Inhaltstyps oder eines Templates definiert werden. Im Theme kann darüber hinaus auch angegeben werden, welche Funktionen, beziehungsweise welche möglichen Werte den Blöcken bereitgestellt werden. Das kann zum Beispiel sein, ob Bilder auch breiter als der Inhalt sein dürfen oder welche Farbe ein Button haben darf.
Denkbar sind dann auch Themes, die dynamisch aufgebaut sind und vollständig über den Customizer mit Hilfe von Drag & Drop definiert werden können. Auf diese Art kann ein echtes WYSIWYG-Prinzip mit WordPress-Websites erreicht werden.
Fazit und Ausblick
Es wird sich also vieles in WordPress fundamental ändern und dies betrifft alle, egal ob Autor, Administrator, Designer, Theme- oder Plugin-Entwickler. Die Entwicklung ist nun soweit fortgeschritten und die Version 5.0 nicht mehr allzulange entfernt, dass es sich lohnt, sich mit dem Thema Gutenberg weiter zu beschäftigen.
Viele Themen haben wir bis jetzt noch nicht angesprochen, möchten darauf aber in den nächsten Wochen weiter eingehen. Wie sieht es beispielsweise mit der Abwärtskompatibilität aus? Werden alte Plugins und Themes weiter funktionieren? Wie wird das alles technisch umgesetzt? Wer entscheidet woran gearbeitet wird und was in die nächste Version kommt? Falls Ihr noch Fragen zu Gutenberg habt, könnt ihr diese gerne in den Kommentaren stellen und wir versuchen sie direkt oder in einem der nächsten Beiträge zu beantworten.
„Als Autor sieht man sofort beim Erstellen in einer Vorschau, wie der Block später aussehen wird und kann die Inhalte beliebig anpassen.“ Kann sein, kann nicht sein, je nachdem, wie viel Mühe man sich beim Entwickeln gibt. Kann auch nur ein schnödes Eingabeformular sein. Abgesehen von Daten, die keine direkte visuelle Entsprechung finden.
„Themes könnten beispielsweise feste Listen von Blöcken bereitstellen, die der Benutzer dann nur noch ausfüllen muss.“ ff
Wird das nicht ein Theme-Lock, den man eigentlich vermeiden will?
1. Das ist richtig. Es gibt mit Gutenberg bessere Möglichkeiten den Inhalt im Backend so aussehen zu lassen wie im Frontend, das muss aber nicht bei jedem Block so sein. Ist auch nicht für jeden Block sinnvoll.
2. Es gab gerade gestern ein eine Diskussion im Slack #core-editor. Dabei war man sich einig, dass Blocks nicht in Themes definiert werden sollten. Bei der Liste (Block Template) definiert man aber nur welche Blöcke bereits für den Inhalt ausgewählt sein sollen. Beispielsweise ein Seiten-Template, das immer oben ein Bild, dann einen Text und danach ein Video hat. Wechselt man das Theme, bleibt der Inhalt auf der Seite bestehen und bearbeitbar, aber das vordefinierte Template ist für neue Seiten nicht mehr auswählbar.
Und mit einer festen Liste von Modulen lassen sich viele Fälle abdecken, für die man heute eher mit Custom-Post-Types und Custom-Fields arbeiten würde.
danke für den ausführlichen kommentar – etnspricht wohl dem zeitgeist des modernen website buildings (nicht nur des blogs an sich), denn viele verwenden wordpress als werkzeug zum verfassen von websites
Ich hätte noch eine Anregung für weitere Folgen, und zwar stoße ich beim Herumspielen auf ein Themenfeld, das mich ziemlich ratlos zurücklässt: die Eignung von Gutenberg für Applikationen, die über „Inhalt genauso raus wie rein“ hinausgehen, sprich wo Daten validiert, verarbeitet, neu zusammengestellt werden.
Beispiel 1 Validierung: Ein E-Mail-Eingabefeld, bei dem ich sicherstellen muß, dass es eine im Unternehmen gültige Adresse enthält. Sprich ein serverseitiger Check gegen ein LDAP-Directory mit einer aussagekräftigen Meldung für den User. Per Metabox machbar, aber nicht mehr unter Gutenberg. Kann bei der gewählten Implementierung, bei der Server-Rückgaben schlank ignoriert werden, auch nie werden.
s. https://github.com/WordPress/gutenberg/issues/3964
Bei einer Portierung als Gutenberg-Block mit Rest-API finde ich – zumindest mit der offiziellen Doku – keine Möglichkeit, ein Update zu prüfen, ggfs. zurückzuweisen und eine clientseitig verarbeitbare Fehlermeldung zurückzubekommen.
Beispiel 2 Datenspeicherung: Mit dem in den Github-Beispielen enthaltenen Rezept-Block kann ich meinen München-Reisebericht mit der Zubereitung von Butterbretzn aufhübschen. Wenn ich dann aber eine Übersichtsseite mit all meinen Rezepten bauen will: Eine performante Query „Finde alle Rezepte in meinen Beiträgen“? Nicht vorhanden. Also alle einzeln parsen. Den Titel aus dem Block extrahieren? Ist im HTML irgendwo vorhanden, aber php-seitig nicht auszulesen, da nur der Client um das Mapping weiß.
Und: Daten, die ich in eigenen DB-Tabellen oder gar in externen Systemen speichern
will?
Beispiel 3 Multi-Step-Forms: — das wird alles zu lang—
Eure Einschätzung / Hintergrundinfos wären da interessant.
Mir ist klar, dass das nur eine Minderheit betrifft, und die Lösung (abschalten) liegt auch auf der Hand, aber m.E. lässt Gutenberg derzeit eine ganze Klasse von Anwendungsfällen einfach mal aussen vor. Ja, erste Version, ich weiss, aber ist das überhaupt auf der Agenda?
Hallo, Sören,
Danke für den Artikel, ich les und guck zur Zeit immer fleissig mit, was Du so erzählst!
Eine Frage beschäftigt mich seit einer Weile: Ich würde gern mehr über das Block-Konzept erfahren. Was es dazu im Umfeld von Gutenberg gibt, kenne ich, glaube ich.
Aber das Prinzip ist ja keine neue Erfindung bzw. es kommt anderswo auch vor. Mit fallen hier Stichwörter wie Adaptive Content und Atomic CSS ein.
Da gibt’s sicher noch viel mehr. Hast Du Tipps für mich, wo ich weiterlesen könnte? Gibt es Apps/CMSe, die den Block-Gedanken schon konsequent verfolgen?
Schöne Grüße
Kirsten
Ich habe mir den neuen Gutenberg angeschaut, der ja heute mit dem automatischen Update mitgeliefert wird und bin nicht so begeistert. Es sind einige Dinge, die ich stören bzw. die ich vermisse:
1. Ich finde in den Blöcken keine Möglichkeit mehr, benutzerdefinierte Felder anzulegen.
2. Auch die Möglichkeit, Beitragsfotos zu definieren, ist verschwunden.
3. Ich nutze oft Fotos, die in Texten verkleinert eingebunden werden und die dann auf Klick vergrößert werden können. Diese Funktion gibt es anscheinend auch nicht mehr. Fotos einbinden geht zwar, aber weder kann ich sie innerhalb des Textes mit align an den Rand ausrichten und umfließen lassen, noch mit sich selber verlinken und vergrößert darstellen. Jedenfalls nicht mehr per einfachem Klick.
Das alles finde ich keine positive Entwicklung. Ich hoffe, dass da noch was nachgebessert wird oder es Plugins zum einen oder anderen Problem geben wird.