Ein gezeichneter Computer im Cyberpunk Stil

Warum ich den Gutenberg Editor (nicht) mag

Ich habe selten ein WordPress-Plugin gesehen, das so schnell so viele beschissene Bewertungen erhalten hat wie der Gutenberg-Editor. Seit WordPress 5.0 hat er den Classic Editor abgelöst und für viele Diskussionen innerhalb der WordPress-Community gesorgt. Warum ich Gutenberg für den richtigen Schritt halte und ihn trotzdem nicht häufig benutze, erkläre ich in diesem Blogbeitrag.

Ich werd’ dich nicht vermissen, Classic Editor.

Ich war nie ein Fan des Classic Editors. Ein einfacher WYSIWYG-Texteditor mag zwar einfach zu bedienen sein, ist aber absolut unbrauchbar für das Entwerfen von Weblayouts. Kein Wunder, dass Plugins wie ACF oder MetaBox quasi unumgänglich waren, wenn es darum ging, Themes zu entwickeln, bei denen der Inhalt von Benutzer:innen nachträglich gepflegt werden kann.

Durch unsere Agentur werden wir oft gefragt, ob wir bestehende Themes auf Basis von z.B. ACF umprogrammieren können, da sich die Struktur auf verschiedenen Seiten verändern soll und diese Flexibilität bei der Entwicklung des Themes nicht berücksichtigt wurde.

Wenn die Seite nicht mit PageBuildern wie z.B. WPBakery oder Avada erstellt wurde, stößt man im individuellen Theme häufig auf feste Layoutstrukturen, die Inhalte dynamisch über Custom Fields anzeigen lassen, aber keine Änderungen an der Struktur zulassen.

Die Lösung des Problems: Gutenberg?

Gutenberg macht alles anders. Für Benutzer:innen sieht der Editor auf den ersten Blick einfach ziemlich leer aus, denn das ist er auch. Nicht mal eine Werkzeugleiste ist auf den ersten Blick erkennbar. Das kann natürlich enttäuschen, aber ich bin mir sicher, dass die meisten negativen Bewertungen von Leuten stammen, die einfach keine Lust hatten, sich das Tool mal im Detail anzuschauen. Was Gutenberg im Hintergrund macht und vor allem, welche mächtigen Programmiermöglichkeiten er Entwickler:innen an die Hand gibt, ist nämlich alles andere als “ziemlich leer”.

Der riesige Unterschied zum Classic Editor ist, dass Gutenberg auf sogenannten Blocks basiert. Blocks sind dabei nichts anderes als Elemente, die sich auf der Seite platzieren lassen. Es gibt standardmäßig zum Beispiel einen Textblock, einen Überschriftsblock, einen Video- oder Bildblock. Also alles ziemlich Standard und so auch erstmal mit dem Classic Editor umsetzbar.

Aber(!) Blöcke können frei entwickelt werden. Und zwar so dynamisch, dass Gutenberg uns die Möglichkeit bietet, eigene individuelle Felder für eigene Blöcke zu definieren. So können wir für Kunden genau die Bereiche dynamisch anlegen, die sie auch bearbeiten sollen.

Was das für Freiheiten im Design- und Entwicklungsprozess bedeutet, würde die Länge des Blogbeitrags sprengen. Deshalb habe ich ein separates Video gedreht, in dem ich vor allem auf den Theme Editor “Pinegrow” eingehe, mit dem sich ohne Programmierkenntnisse eigene Gutenberg-Blocks erstellen lassen.

Gutenberg Blöcke lassen sich flexibel einsetzen

Sobald Gutenberg-Blöcke einmal programmiert wurden, können sie innerhalb des Gutenberg-Editors frei verwendet werden. Dies hat den enormen Vorteil, dass diese Blöcke nicht nur auf den im Vorfeld vorhergesehenen Seiten platziert werden können, sondern auch in Blogbeiträgen oder in benutzerdefinierten Beitragstypen eingesetzt werden können. Wenn beispielsweise ein Call-to-Action-Block entwickelt wurde, kann dieser auch problemlos in allen Beitragstypen hinzugefügt werden.

Dadurch können neue Seiten, Landing-Pages oder Blogposts im Handumdrehen erstellt werden.

Es ist auch möglich, dass Gutenberg-Blöcke nicht nur im Theme definiert, sondern über ein Plugin erstellt und gestaltet werden. Dadurch können bestehende Themes um neue Blöcke ergänzt werden, was besonders praktisch ist, wenn Blöcke entwickelt wurden, die auf mehreren Kundenseiten zum Einsatz kommen. In diesem Fall muss das Theme nicht für jeden Kunden um die jeweiligen Blöcke erweitert werden, sondern es kann ein zentrales Plugin dafür entwickelt werden. Das macht auch die nachträgliche Pflege oder Erweiterung wesentlich einfacher.

Warum ich Gutenberg nicht gerne verwende

Das größte Problem bei Gutenberg ist das User Interface. Ich habe wirklich schon viele Tage in die Bedienung des Editors gesteckt, um dann jedes Mal festzustellen, dass vieles unnötig kompliziert gemacht ist.

Die Elemente in der Struktur-Liste lassen sich nicht umbenennen: Ein Punkt, der mich wirklich am meisten ärgert, ist, dass die Blöcke, die auf der Seite platziert werden, im Gutenberg Editor nicht umbenannt werden können. Gerade wenn ich z.B. eine riesige Landing-Page mit vielen Container-Blöcken erstelle, möchte ich doch die Elemente so benennen können, dass ich in vier Wochen noch weiß, welcher Block für welches Element auf meiner Seite steht.

Standardblöcke sind nicht Entwicklerfreundlich: Die Blöcke, mit denen Gutenberg standardmäßig ausgeliefert wird, sind für mich nicht wirklich benutzbar. Ich kann von Layout-Elementen wie Columns und Rows weder ID-Namen frei vergeben noch habe ich Zugriff auf Pseudo-Elemente (z.B. :after, :hover) oder Attribute.

Kein Klassen-orientierter Editor: Wie die meisten PageBuilder (lest gerne meinen Artikel über meine Probleme mit Elementor und WPBakery), ist auch der Gutenberg Editor nicht für das Arbeiten mit Klassen ausgelegt. Zwar kann ich Blöcken individuelle Klassen zuweisen, aber ich habe keine Möglichkeit, diese im Gutenberg zu gestalten.

Sieht einfach scheiße aus: Im Vergleich zu Oxygen, Elementor und Bricks macht Gutenberg einfach zu viel falsch. Sämtliche Panels sind irgendwie versteckt, jede Änderung braucht unnötig viele Klicks und die UI ist einfach nicht schön.

Mein hoffnungsvolles Fazit

Es war der richtige Schritt für WordPress, sich vom Classic Editor zu verabschieden, um den Anforderungen und dem technischen Stand der Dinge gerecht zu werden. Webseiten-Baukäste wie Webflow zeigen, wie gut ein grafisches Webentwicklungstool gestaltet sein kann, um individuelle Design- und Entwicklungsmöglichkeiten zu bieten. Davon ist Gutenberg leider noch meilenweit entfernt. Trotzdem glaube ich, dass der Gutenberg-Editor viel Potenzial hat, um für Entwickler:innen und Kunden ein flexibles, aber einfach zu pflegendes Werkzeug zu sein.

Manuel Schwarz

WordPress-Entwickler und Mitgründer von WP-Cologne

Avatar von Manuel Schwarz

Genug gelesen?

Du brauchst direkte Unterstützung bei deiner WordPress-Webseite?
Vereinbare unverbindlich und kostenlos ein Online-Meeting mit uns.

Borlabs Cookie Banner mit Automatic.CSS stylen

Keine Lust drauf, mehr als 20 Farbboxen im Borlabs Cookie Banner Plugin händisch auszuwählen, um das Look&Feel der Primärfarbe deiner Webseite anzupassen? Fühl ich. Nachdem mir der Support vom Borlabs Cookie Banner bestätigt hat, dass diese keine Unterstützung von CSS…...

Ein Screenshot vom Borlabs Cookie Banner

Kritische Sicherheitslücke im Bricks Theme <= 1.9.6

Am 10. Februar hat der Sicherheitsexperte Calvin Alkan von snicco eine Möglichkeit im Bricks Theme entdeckt, um fremden Code auf dem Server der betroffenen Webseite ausführen zu können. Er hat das Team von Bricks kontaktiert und eine Lösung präsentiert, die…...

Google Workspace E-Mails werden nicht versendet? (SPF Authentifikation)

Wir hatten diesen Monat mehrere Anfragen von Kund*innen, bei denen manche E-Mails nicht versendet wurden und die eine Infomail mit dem Hinweis "Die Nachricht wurde blockiert" erhalten haben. Wenn ihr Google Workspace nutzt, solltet ihr unbedingt drauf achten, die SPF…...