Erste Erfahrungen mit Gutenberg: Wie mich der neue Editor von WordPress zum Zappeln brachte

Gutenberg ist da. Der Editor soll WordPress im Kern erneuern. Und außerdem die Welt verbessern. Ich habe ihn ausprobiert – dabei fühlte ich mich wie ein Versuchskaninchen.

Gutenberg ist ein gewaltiger Fortschritt. WordPress wird durch den neuen Editor zum Page-Builder. Mehr noch: Block für Block verändert die Software das Web-Publishing vom Grund auf. Und damit die ganze Welt. Das meint zumindest Matt Mullenweg, Chef von Automattic, der Firma hinter WordPress. Schon lange vor dem Update blies Mullenweg, obendrein Jazzfan, kräftig in die Trompete. Fraglich ist, ob es ein Solo bleibt.

Derweil wurde der Tonfall in den Wortgefechten, in die sich Gutenberg-Befürworter und -Gegner stürzten, immer pampiger. Das klang mehr nach Schwermetall. Tech-Blogs diskutierten jede Code-Änderung als Wegscheide für WordPress. Und freie Entwickler fürchteten, von der Revolution überrollt zu werden, mit der ihnen Mullenweg einen Boom bescheren will. Dass die Gutenberg-Anpassung viel Arbeit und damit Geld koste, sei Kunden nicht vermittelbar.

Anfangs neugierig, wurde mir der Lärm um den neuen Editor bald zu laut. Ich habe deshalb alles ignoriert, auch die Vorabversionen, und auf  WordPress 5.0 gewartet. Vorigen Donnerstag war es so weit. Nach monatelangen Ankündigungen kam das Update mit nur zwei Tagen Vorlaufzeit. Aber bitte:

Klick. Und Startpfiff! Vorher hatte ich noch eine Einführung überflogen (und natürlich ein Backup gespeichert). Meine Erfahrungen mit Gutenberg dokumentiere ich in diesem Text, für den ich den Editor erstmals verwendet habe. Im Hin und Her des Schreibens, Testens und der Fehlersuche ist er zu epischer Länge angewachsen.

Wer in Eile ist, hüpft zu meinem Fazit.

Der erste Eindruck enttäuscht

Als Gutenberg-Anfänger gehe ich ohne Vorurteile an den neuen Editor heran, den alten mochte ich nie. Dennoch ist mein erster Eindruck beim Erstellen dieses Beitrags kein positiver:

• Schwerfällig: Der Aufbau der Editorseite und die Vorschau eines Beitragsentwurfs könnten rascher gehen. Und wenn ich schnell tippe, kommt mir die Texteingabe nicht hinterher.
  
• Unübersichtlich: Die Menüs und Optionen sind nach einem Prinzip über die Benutzeroberfläche verteilt, das ich nicht verstehe. Zumindest meiner Arbeitsweise entspricht es nicht.
  
• Unruhig: Die Bewegung des Mauszeigers löst vielerorts Mouseover-Effekte aus und lässt Menüs aufpoppen. Ablenkungsfreies Schreiben geht anders.
  

Zum Zappeln der Pop-up-Menüs und Tooltips kommt noch das regelmäßige Aufflackern der Autosave-Funktion in der oberen Editorleiste hinzu. Alle 18 Sekunden wird ein Beitragsentwurf automatisch gespeichert.

Ich vermute, die schnelle Taktung ist eine Vorsichtsmaßnahme angesichts des unreifen Zustands von Gutenberg. Für meine Zwecke ist die Autosave-Funktion dennoch zu eifrig. Kann ich die Zeitintervalle vergrößern? Das muss ich noch herausfinden. Sobald ich eine Lösung gefunden habe, trage ich sie hier nach.

Wie sich die zappeligen Pop-up-Menüs aus dem Sichtfeld schieben lassen, weiß ich bereits: In der oberen Editorleiste klickt man das Icon mit den drei Punkten für Weitere Werkzeuge und Optionen und wählt Zugang zu allen Blöcken und Dokument-Werkzeugen von einem Platz aus. Setzt man die Arbeit an einem Entwurf ein andermal fort, macht man das erneut – Gutenberg merkt sich die Einstellung nicht.

Klar, die Benutzeroberfläche ist ungewohnt. Deswegen mag ihre Gestaltung nicht besonders intuitiv auf mich wirken. Aber ich kann mir jetzt noch nicht vorstellen, dass ich irgendwann gern mit Gutenberg schreiben werde. Lange Blogbeiträge werde ich weiterhin zuerst mit einem anderen Editor verfassen.

Testobjekt: mein klassisches WordPress-Blog

Weiter im Probelauf: Quo 28 eignet sich als Testobjekt – es ist ein klassisches Blog und kommt ohne komplexe Seiten aus. Mit dem WordPress-Framework Genesis, das ich verwende, habe ich einige Widget-Bereiche gecodet, die sich je nach Seite oder Archiv anders zeigen. Aber die eigentlichen Blogtexte sind einfach gehalten.

Es gibt ein paar Absatztypen mit eigenen CSS-Klassen: einen Vorspann, der typografisch anders gesetzt ist als der Fließtext; einen Absatz mit Initial für den Textanfang und diverse Infoboxen, die ich mit je besonderen Stilen ausgestattet habe.

Mal sehen, wie gut sich Gutenberg schlägt.

Bequem: CSS-Klassen für Absätze

Die Grundeinheit Block umfasst einen einzelnen Absatz. Hier gibt es beim Gebrauch des neuen Editors Positives zu melden: Unter Einstellungen in der Seitenleiste lassen sich unter Erweitert rasch zusätzliche CSS-Klassen für einen Absatz eingeben. Auch für weitere von mir verwendete Blocktypen wie Bild, Liste und Titel ist diese Funktion verfügbar.

Während ich zuvor in der Textansicht des Editors Code eintragen musste, kann ich jetzt den Namen einer Klasse bequem in ein Feld eingeben. Das erleichtert das Schreiben eines Beitrags.

Schlicht: der HTML-Block

Ich habe aber auch Infoboxen mit eigenen Stilvorgaben im Einsatz, die nicht in das Schema des Absatzblocks passen. Die Gründe: weil ich zur Auszeichnung von Inhalt, der Zusatzinformationen zum eigentlichen Blogtext liefert, das semantische HTML5-tag <aside> verwende. Oder weil die Boxen mehrere Absätze beinhalten (siehe oben den Kasten mit technischen Eckdaten). Bei der vorliegenden Gutenberg-Version muss ich dafür den HTML-Block wählen.

Das Menü für die Blockauswahl bietet eine Suchfunktion:

Damit finde ich rasch den HTML-Block, den ich jetzt brauche:

Zwar hat der HTML-Block eine Vorschaufunktion, aber Gutenberg ist hier sehr schlicht gehalten. In der Textansicht des alten Editors gibt es zumindest eine Leiste mit gebräuchlichen HTML-tags. Gutenberg bietet nur ein Eingabefeld. Hier ist die Ansicht für die Infobox, die ich in diesem Beitrag zwei Abschnitte weiter oben verwendet habe:

Das Gleiche gilt für die HTML-Bearbeitung von Infoboxen, die mehrere Absätze umfassen. Schon weil die Leiste mit HTML-tags der Textansicht des alten Editors fehlt, ist die Arbeit etwas mühsamer geworden.

Gutenberg braucht einen Containerblock

Was Gutenberg noch abgeht, ist ein Blocktyp, der als Container für weitere Blocks dient. Es sollte möglich sein, Blöcke zu verschachteln, sodass ich innerhalb eines Blocks untergeordnete Blöcke einsetzen kann, die mittels der CSS-Klasse des Hauptblocks eine Stilvorgabe erhalten. Beispielsweise um einen Infokasten zu bauen, der nicht nur einen Absatz mit einem Rahmen umfasst, sondern mehrere Absätze.

Es gibt mittlerweile WordPress-Plugins, die das Repertoire an Blocks ausbauen. Die Erweiterung „Editor Blocks for Gutenberg“ bietet zum Beispiel einen „Wrapper Block“, der als Container dient. Ich habe das Plugin nicht getestet. Denn ich warte lieber ab, was sich die Community der Gutenberg-Coder einfallen lässt.

Ein Blick auf ihre Seite bei GitHub, einer Plattform für kollaborative Software-Entwicklung, zeigt: Ein Container steht in der Liste neuer Blocks, die in Arbeit sind.

Bildblock mit semantischem Markup

Auch Bilder lassen sich über einen eigenen Blocktypus in einen Beitrag einfügen. Wenn man sich den Code ansieht, den die Funktion produziert, gibt es eine Überraschung: Für Gutenberg haben die Entwickler Markup eingeführt, das das Element <img> umschließt. Und zwar sind jetzt die Elemente <figure> und <figcaption> im Einsatz.

Das ist von Vorteil, weil es sich dabei um semantisches HTML5 handelt. Was die Maschinenlesbarkeit und Barrierefreiheit verbessert.

Und es hat einen kleinen Nachteil: Weil nun <figcaption> für die Auszeichnung von Bildunterschriften zuständig ist, sind die CSS-Regeln hinfällig, die in früheren WordPress-Themes p.wp-caption-text gestylt haben. Das CSS für die Beschriftung einer Abbildung stiftet nun das Gutenberg-Stylesheet.

In dem Dokument finde ich für Bildunterschriften im Bildblock diesen Eintrag:

.wp-block-image figcaption {
 margin-top:.5em;
 margin-bottom:1em;
 color:#555d66;
 text-align:center;
 font-size:13px
}

Änderungen am Gutenberg-Stylesheet ergeben keinen Sinn, da sie das nächste WordPress-Update wieder überschreiben würde. Damit die Farbe und Schriftgröße von Bildunterschriften zu meinem Design passen, habe ich den Code modifiziert und in der Datei style.css meines Child-Theme ergänzt.

Mit dieser Lösung habe ich nur ein Detail bereinigt, das mich nach dem WordPress-Update im Frontend stört, dem öffentlich sichtbaren Teil des Blogs. Damit Gutenberg als WYSIWYG-Editor schon beim Verfassen von Beiträgen die Gestaltung umsetzt, ist mehr Aufwand notwendig. Webdesigner und Entwickler, die mit WordPress arbeiten, werden wohl ein Stylesheet für Gutenberg-Anpassungen einbinden.

Klecksen mit Gutenberg

Es gibt noch andere Stile, die Gutenberg in seinem eigenen Stylesheet mitliefert: Regeln für gigantische Initiale, die sich in der Seitenleiste des Editors aktivieren lassen. Gut für Neulinge, aber ich behalte die CSS-Regeln bei, die ich für diesen Zweck selbst entworfen habe. Die Gutenberg-Stile für vergrößerte Blockquotes und hervorgehobene Zitate aus dem Text (Pull-Quotes) werde ich mir noch genauer ansehen.

Die Einstellungen für Schriftgrößen, Hintergrund- und Textfarben, die sich in der Seitenleiste finden, sind Geschmackssache. Ich halte sie für eine überflüssige Spielerei. Webdesigner und Entwickler gruseln sich bei der Vorstellung, dass ihre Kunden den neuen Editor mit einem Malkasten verwechseln. (Aber vielleicht ist Minimalismus im Netz bald Geschichte, und es wird Zeit für ein MySpace-Revival.)

Ich hoffe trotzdem, dass der Editor in den folgenden WordPress-Updates nicht mit zu vielen Blocks für Bastelstunden aufgebläht wird. (Der Cover-Block weckt Befürchtungen.) Was sich auch am Gutenberg-Stylesheet bemerkbar macht. Ich bin bei CSS knauserig. Derzeit ist die Datei 27 Kilobyte groß.

Der Code für spezialisierte Blocks ist in Erweiterungen, die ein Admin je nach Bedarf installieren kann, ohnehin besser aufgehoben: Das offizielle Verzeichnis sammelt bereits WordPress-Plugins für Gutenberg-Blocks in einer eigenen Sektion.

Fehlfunktionen, Usability-Probleme und Code-Schrott

Bug (englisch für Wanze, Käfer, Insekt) ist im IT-Jargon ein liebevoller Spitzname für Programmfehler. Beim Ausprobieren der verschiedenen Gutenberg-Blocktypen jucken Stiche der Biester an jeder Stelle. Allerorts tauchen Fehlfunktionen und auch Probleme mit der Usability auf, der Tauglichkeit für den Gebrauch.

Schon die Überarbeitung von Blöcken wird zum Glücksspiel. Sie verdoppeln sich beim Copy and Paste von Text manchmal auf rätselhafte Weise. Jahrelang bei der Nutzung von Software eingeübte Tastenkombinationen, etwa für „Eingabe widerrufen“, führen zu unerwarteten Resultaten. Hat das überhaupt jemand getestet?

Anfällig ist der Listenblock, von mir auch „King Crash“ genannt. Im visuellen Editor Stichpunkte nachträglich zu bearbeiten erfordert schon mal Geduld. Doch ich traute mich mehr: ein Inhaltsverzeichnis mit hierarchisch verschachtelten Einträgen zu bauen. Mit dem Classic Editor sind komplexe Listen bereits ein Puzzle, bei dem eine Geisterhand die Teile vermischt, mit Gutenberg bahnen sie einen Weg in die Verzweiflung.

Schade, aber toll: Gutenberg erlöste mich irgendwann, indem er den Listenblock für kaputt erklärte. Ich konnte ihn nur noch löschen. Wenigstens das.

Tipp: Aufwendigere Listen schreiben Sie am besten mit irgendeinem anderen Editor in HTML vor und fügen diese anschließend in den entsprechenden Gutenberg-Block ein. Denken Sie an King Crash, und danken Sie mir später!

Zwanghafte Zeilenumbrüche

Der Blick in Gutenbergs Code-Editor, für HTML-Puristen sowieso kein Spaß, zeigt: Vielfach erscheint das HTML-tag <br> dort, wo es nicht hingehört: am Ende von Absätzen und Zwischenüberschriften. Es ist eigentlich für erzwungene Zeilenumbrüche gedacht.

Zum Ärgernis wird das überflüssige tag für mich, wenn es Inhalt, den ich mit dem CSS-Pseudoelement ::after hinzufüge, unerwünscht in die nächste Zeile verschiebt. Das tritt bei mir beim end mark auf, einem grafischen Element, das auf das Textende hinweist (siehe ebendort; schon korrigiert).

Kontrollblick in den Code-Editor

Bugs birgt auch der HTML-Block. Ein Block, in dem ich ein mit dem tag <code> ausgezeichnetes Beispiel aus dem Quelltext zeigen wollte, reagierte nicht mehr (dafür verwendete man auch besser den speziellen Code-Block von Gutenberg).

Jeder Klick auf das Feld wurde vom Editor als Versuch interpretiert, die Seite zu verlassen. Nicht schön. Wer hier unachtsam reagiert, darf sich zumindest über die fleißige Autosave-Funktion freuen.

Ein Löschen des Blocks war über das Kontextmenü nicht möglich. Also musste ich dafür in den Code-Editor wechseln, um dort die Zeilen zu entfernen. WordPress-Anfänger, an die sich Gutenberg unter anderem richtet, werden dabei nicht jubeln.

Aber solange Gutenberg Schrott-tags erzeugt, ist ein Kontrollblick in den Code-Editor vor dem Publizieren eines Beitrags ohnehin Pflicht.

Rätselhaft: die Platzierung des Cursors

Ein sehr nerviges Problem tritt bei der Auswahl von Absatzblöcken auf. Wenn ich zum Beispiel im Entwurf in einem zuvor verfassten Absatz ein Wort ändern möchte und den Block an der Textstelle anklicke, dann kann das zwei unterschiedliche Effekte haben: Mal landet der Cursor genau an der gewünschten Stelle. Ein andermal wird er ganz am Anfang des Absatzes platziert. Was nun?

Tippe ich im zweiten Fall los, ohne hinzusehen, muss ich die falsche Eingabe hinterher wieder löschen. Das macht mich nervös. An flüssiges Schreiben ist so nicht zu denken.

Nach mehrfachem Testen weiß ich um das Geheimnis, nach welchen Kriterien Gutenberg die Platzierung des Cursors bei der Auswahl eines Blocks bestimmt: Beim ersten Anklicken eines Blocks aus einem Entwurf, den ich zwischenzeitlich verlassen und dann neu aufgerufen habe, landet der Cursor am Anfang des Absatzes. Bei allen weiteren Klicks an der gewünschten Stelle. Ich darf auch hier eine Fehlfunktion vermuten.

Fehlerliste auf GitHub

Was ich erwähnen muss: Nahezu alle Probleme der Benutzeroberfläche und Bugs, auf die ich gestoßen bin, sind in der langen Fehlerliste der Gutenberg-GitHub-Seite bereits genannt. Die Entwickler werden einige Wehwehchen hoffentlich bis zum nächsten WordPress-Update versorgt haben. Meinen Beifall schicke schon mal voraus.

Um meine Kopfschmerzen nach der Arbeit an diesem Text, bei der sich die Blocks zu einer Blockade stapelten, darf ich mich selbst kümmern. Aber was tut man nicht alles für Matt Mullenwegs Programm zur Verbesserung der Welt!

Fazit meiner Erfahrungen

Langsam, unkomfortabel und fehlerhaft: Die mit WordPress 5.0 ausgelieferte Version des Gutenberg-Editors ist nicht ausgereift, um es höflich zu formulieren. Ich sehe die Veröffentlichung zu diesem Zeitpunkt kritisch. Und frage mich: Dienen Millionen von Anwendern des Web-Publishing-Systems als Versuchskaninchen? Der Ruf der Software wird darunter leiden.

Auf meinem Hobbyblog Quo 28 habe ich den Test gewagt. Hier werde ich den neuen Editor weiterhin verwenden, damit ich im Umgang damit Übung bekomme. Vielleicht stellt sich irgendwann ein besserer Schreibfluss ein. Dass ich das Mouseover- und Pop-up-Gezappel der Benutzeroberfläche eines Tages ignorieren kann, bezweifle ich aber.

Auf meiner beruflichen WordPress-Website, die in Teilen komplexer aufgebaut ist als dieses Blog, gehe ich das Wagnis auf keinen Fall ein. Dort verwende ich für eine Übergangszeit entweder das offizielle Plugin „Classic Editor“, das den alten Zustand wiederherstellt. Es wird bis Ende 2021 unterstützt. Oder ich installiere „Disable Gutenberg“ vom Entwickler Jeff Starr. Beide Erweiterungen habe ich noch nicht getestet.

Wenn ich das Update auf WordPress 5.0 überhaupt anpacke – die Macher wichtiger Plugins warnen vor zu großer Eile.

Gutenberg ist da und wird nicht mehr verschwinden. Trotz meiner negativen ersten Erfahrungen halte ich den neuen Editor für einen wichtigen Schritt. Und wenn ich mich auf der GitHub-Seite der Entwickler umsehe, entdecke ich schöne Ideen. Zum Beispiel den Vorschlag, den Titel von statischen Seiten und Blogbeiträgen selbst in einen Block zu verwandeln, der sich wie ein Absatz bearbeiten lässt. Das hört sich doch gut an!

Mir gefällt auch der Enthusiasmus des Teams, der aus den Diskussionen strahlt. Bei mir kann ihn Gutenberg leider noch nicht wecken.