Ist der Block-Editor zu progressiv für WordPress?
Veröffentlicht: – 15 Kommentare
Der Block-Editor ist in seiner Entwicklung ein kompletter Neuanfang. Doch passt diese Art der Entwicklung überhaupt zu WordPress? Diese Frage stelle ich mir immer wieder, wenn ich vor diversen Problemen stehe, insbesondere wenn neue Versionen des Block-Editors veröffentlicht werden – oder noch kritischer – wenn sie im WordPress Core landen.
Dabei verfolge ich die Entwicklung des Block-Editors bereits einige Jahre und war von Anfang an dabei, eigene Blöcke zu entwickeln, als er Teil des WordPress Cores wurde. Das ist mittlerweile knapp drei Jahre her. Und in diesen knapp drei Jahren sind mir einige Dinge aufgefallen, die beim Block-Editor grundsätzlich anders in der Entwicklung ablaufen als im Rest von WordPress. Dabei meine ich nicht unbedingt technischen Dinge, für die sich nur Entwickler interessieren brauchen.
Änderungen bestehender Seiten
Für mich am dramatischsten, und vermutlich auch für die meisten am nachvollziehbarsten, ist die teilweise regelrecht rücksichtslose Art, Änderungen derart progressiv voranzutreiben, dass damit die Abwärtskompatibilität teilweise oder vollständig missachtet wird. Das führt dann wiederum zu Änderungen an bestehenden Seiten ohne ein aktives Einwirken seitens der Administration bzw. den Erstellenden der Seiten.
Konkret heißt das: du kannst dir nach einem Major-Update von WordPress, also bei Veränderungen der ersten oder zweiten Stelle der Versionsnummer, zu keinem Zeitpunkt mehr sicher sein, dass die Seite vorher genauso aussieht wie danach. Das trifft insbesondere dann zu, wenn du individuelles CSS oder ein vom Standard abweichendes Theme verwendest.
Ein Auszug an Änderungen, die das Layout beeinflussen
Diese Liste ist definitiv nicht vollständig, aber das sind die Dinge, die mir spontan hierzu einfielen.
- Klassen zur Ausrichtung des Button-Blocks wurden komplett entfernt (WordPress 5.9)
- Das Element
.wp-block-group__inner-container
wurde vom Gruppen-Block entfernt (WordPress 5.8) - Der Spalten-Block hat keine Klasse mehr, der die Anzahl der Spalten via
.has-<Anzahl>-columns
anzeigt (WordPress 5.3)
Viele Usability-Änderungen
Wer die Entwicklung des Gutenberg-Editors schon früh mitbekommen hat, der wird sich noch an den Punkt erinnern, an dem es – endlich – möglich war, Blöcke ineinander zu verschachteln. Und sicherlich können sich alle, die das mitbekommen haben, noch sehr gut daran erinnern, wie schwierig es war, innerhalb der verschachtelten Blöcke zu navigieren. Das wurde nicht nur einmal angepasst und selbst heute noch, mehrere Jahre später, ist es insbesondere für Einsteiger und Fachfremde – für die WordPress immer noch eine sehr große Zielgruppe ausmacht – immer noch schwierig und teils zu komplex.
Doch das ist nur ein Beispiel für mehrere radikale Änderungen an der Usability des Block-Editors. Mindestens zweimal seit der Veröffentlichung in WordPress 5.0 gab es fundamentale Änderungen, die oft mit einem Neu Erlernen der Funktionalität des Editors einher gingen. Klar, für Power-User ist das kein Problem, aber das ist eine verschwindend kleine Zielgruppe für WordPress. Dass es ein extremes Ärgernis für alle ist, die sich nicht sofort in veränderte technische Gegebenheiten einarbeiten können, wurde entweder vorher ignoriert oder billigend in Kauf genommen – Hauptsache, die Version wird veröffentlicht (und das war in WordPress 5.0 tatsächlich der Fall).
Wenn man bedenkt, dass das restliche Interface des WordPress-Backends sehr lange stabil war und ist (ob das nun nach so vielen Jahren noch gerechtfertigt ist, sei mal dahin gestellt), zeigt schon sehr gut, dass es innerhalb des Gutenberg-Projekts anders zugeht.
Experimentelle Funktionen im Core
Neue Funktionen werden mittlerweile oftmals als „experimentell“ gekennzeichnet und auch dementsprechend innerhalb des Codes benannt. Während das grundsätzlich eine gute Herangehensweise ist, um explizit anzugeben, dass eine Funktion experimentell ist, so ist es meiner Meinung nach nicht sinnvoll, dass solche experimentellen Funktionen in der finalen Version des Cores landen. Genau das passiert aber immer wieder.
Das Hauptproblem, das ich aus Entwicklersicht hierbei sehe, ist dass man zwar eine neue Funktion im Core verwenden kann, diese aber als experimentell gekennzeichnet ist und damit in einer Produktivumgebung eigentlich nicht verwendet werden sollte. Gleichzeitig habe ich nicht erst einmal eine solche Funktion dann doch benötigt. Das heißt dann, dass ich diese Funktion, sobald diese nicht mehr experimentell ist, nochmal neu testen und gegebenenfalls die Implementierung anpassen muss. Meiner Meinung nach wäre es wesentlich besser, experimentelle Funktionen nicht mitzuliefern. Und wenn sie innerhalb des Block-Editors erforderlich sind, sollte man vor dem Release dafür sorgen, dass sie eben nicht mehr experimentell sind. Nicht selten sind nämlich genau das dann Funktionen, die, sofern sie nicht mehr experimentell sind, anders funktionieren wie noch in ihrem experimentellen Stadium.
Zu viele unbearbeitete Fehler
Aktuell (Stand: 14. März 2022) gibt es 837 offene Issues auf GitHub mit dem Label „Bug“, die also bereits als Fehler verifiziert wurden. Daneben gibt es unter den restlichen der über 3.900 Issues noch eine große Dunkelziffer. Allein von meinen aktuell sechs offenen Issues sind nur zwei mit dem Label „Bug“ versehen, obwohl auch die anderen ganz klare Fehler innerhalb des Block-Editors sind.
Ebenso hat ein Issue, das von mir gemeldet wurde, seit November 2020 das Label „In Progress“, also in Bearbeitung. Seither hat sich aber praktisch nichts mehr getan. Das ist frustrierend, insbesondere wenn man auf die defekte Funktionalität angewiesen ist. In diesem konkreten Fall heißt das für mich, dass Personen, die keine ausreichende Berechtigung haben, HTML-Code innerhalb von wiederverwendbaren Blöcken unter Umständen kaputt machen, sofern sie eine Seite bearbeiten. Und dabei ist es egal, ob der wiederverwendbare Block selbst angepasst wird oder nicht.
Andere Systeme bleiben auf der Strecke
Einen interessanten kurzen Einblick in seine Arbeit mit der WP-CLI gab Alain Schlesser beim 80. Stuttgarter WordPress-Meetup. Leider ist der interessante Teil zum Gutenberg-Projekt aus einer Frage nach dem Vortrag entstanden, sodass diese nicht mehr Teil der Aufnahme ist (Anschauen lohnt sich dennoch). Grob gesagt ist aber für die WP-CLI das große Problem, dass der Block-Editor so aufgebaut ist, dass er praktisch nur über JavaScript und damit über einen Browser vernünftig und komplett benutzt werden kann. Dadurch ist es für weitere Werkzeuge wie eben die WP-CLI praktisch nicht möglich, Blöcke effektiv zu verarbeiten, da hierzu viele Informationen fehlen.
Weiterhin werden bestimmte Funktionen, die im Core vorhanden sind und dort überall beachtet werden, im Block-Editor teils komplett ignoriert. Jüngst fiel mir das bei der Standard-Bildgröße auf, die beim Medien-/Text-Block nicht korrekt beachtet wird.
Doch auch Funktionen, die der Block-Editor selbst mitbringt, werden mittlerweile nach meiner Erfahrung teils nicht mehr mit einbezogen, wenn es darum geht, Änderungen vorzunehmen, die dadurch beeinflusst werden können. Als Beispiel sei hier die Funktion genannt, das Frontend-CSS des Block-Editors komplett zu deaktivieren und eigenes Styling mitzubringen. Denn das heißt, dass man sämtliche Anpassungen, die hier im Rahmen einer neuen Version gemacht werden, adaptieren muss. Ich erwarte nicht, dass Änderungen zurückgehalten werden, weil es Websites gibt, die eigenes Styling mitbringen. Aber genau dann erwarte ich, dass man derartige Anpassungen übersichtlich im Rahmen eines Changelogs erwähnt findet, statt sie sich selbst jedes Mal aus dem Code heraussuchen zu müssen. Insbesondere bei der Menge an Blöcken nimmt das immer mehr Zeit in Anspruch.
Wichtige Neuerungen werden oft nicht angekündigt
Mit jeder neuen Major-Version des WordPress-Cores ist es wieder ein Katz-und-Maus-Spiel, ob man alle für sich relevanten Änderungen findet. Die Ankündigungen auf make.w.org sind zwar nützlich, aber keineswegs auch nur ansatzweise komplett. Auch die Changelogs sind oftmals nicht hilfreich, ohne dass man wirklich jeden Eintrag manuell und genau ansieht. Bei weit über 100 Änderungen jedes Mal eine Mammut-Aufgabe.
So wurde beispielsweise in WordPress 5.9 nicht nur die Ausrichtung des Button-Blocks entfernt, sondern gleichzeitig eine neue Funktion implementiert, die Styling für ebenjene Ausrichtung und ähnliches dynamisch generiert und als Insite-CSS direkt innerhalb der jeweiligen Seite hinzufügt. So etwas muss dann in einer Testumgebung auffallen und tut es das nicht, hat man unter Umständen kaputte Buttons auf der eigenen Website.
Fazit
Ja, dieser Beitrag ist sehr negativ. Vollkommen bewusst. Damit möchte ich aber nicht sagen, dass der Block-Editor oder das Gutenberg-Projekt als solches schlecht ist. Ganz im Gegenteil, ich liebe den Block-Editor und arbeite sehr gern mit ihm. Umso schlimmer finde ich es, dass er auf eine ganz andere Art entwickelt wird wie der WordPress Core. Denn gerade die Abwärtskompatibilität, die gleichbleibende Funktionalität einer vorhandenen Funktion und die eher konservative Art, Neuerungen zu veröffentlichen, sind meiner Meinung nach große Standpfeiler, warum das WordPress-Projekt so erfolgreich wurde und ist.
Und genau hier läuft man nun Gefahr, sich so sehr zu verändern, dass das gesamte Projekt in Mitleidenschaft gezogen wird. Denn dass diese progressive Entwicklung des Block-Editors alle Entwickelnden auf Trab hält, ist die eine Sache. Dass aber auch diejenigen, die WordPress nur verwenden, um Inhalte zu pflegen, sich immer wieder teils dramatischen Änderungen ausgesetzt sehen, ist ein ganz anderes und viel gravierenderes Problem. Denn wer das nur ab und zu macht, wird sich kaum sinnvoll einarbeiten können. Insbesondere wenn sich ein Teil der Benutzeroberfläche alle paar Monate wieder ändert.
Und wenn dann noch Inhalte visuell im Frontend verändert werden, die man beim Test vielleicht nicht bemerkt hat, dann ist das der Worst Case.
Einen Teil der Dinge, die ich hier anspreche, habe ich auch bereits als Feedback hinterlassen (engl.). Ich hoffe daher sehr, dass sich hier zumindest in die ein oder andere Richtung etwas ändert. Aber das wird erst die Zukunft zeigen …
Die automatisch generierten IDs bei Überschriften setzen Umlaute nicht korrekt um (ü wird nicht zu ue, sondern zu u, usw.).
Diakritische Zeichen, die aus zwei Zeichen zusammengesetzt werden (statt als ein Zeichen) werden im Titel nicht korrekt umgewandelt. Beim Kopieren innerhalb des Editors (z.B. vom Titel in den Inhalt) auch nicht. Beides gemeldet und noch offen.
Viele weitere Bugs werden nicht gefixt, weil nicht relevant (insbesondere zu Rückwärtskompatibilität), wie z.B. Gutenberg-Kommentar-Markup wird in der Suche erfasst, Visuellen Editor im Profil ausschalten hinterlässt einen reinen HTML-Editor inkl. Gutenberg-Kommentar-Markup, etc. etc.)
Ich will den Editor ja gut finden, aber das Ganze ist an so viel Stellen unfertig, kaputt, nicht zu Ende gedacht und ein „fast moving target“ als Benutzer *und* Entwickler. Frustrierend.
Also ich habe da auch an vielen Stellen Probleme mit. Vor allem wird aufgrund der jetzigen Logik natürlich das CSS von den einzelnen Blöcken mitgebracht. Das verursacht oft Kopfschmerzen, wenn man mal wieder CSS überschreiben muss. An ein paar Stellen ist mir das dann besonders aufgefallen. Zum einem bei dem automatischen Stapeln bei der Mobilansicht und auch bei dem Hamburger Menü. Breakpoints sind da z.B. hart im WordPress CSS Code drin, was je nach Layout aber nicht unbedingt immer Sinn macht.
WordPress verfolgt außerdem nicht mehr den Ansatz des responsive, sondern den des intrinsischen Layouts. Das klingt zwar erstmal gut, aber trotz allem brauch man für gewisse Dinge Breakpoints wie z.B. für das Hamburger Menü.
Außerdem verstehe ich nicht, warum man Dinge wie Margin, Paddings usw. erst freischalten muss per theme.json. Da könnte man auch nochmal ran, das macht nämlich auch Probleme bei älteren Themes. Da eine theme.json einfach ins Child Theme einbauen, wo vorher keine war ist nämlich auch kaum machbar…
Ansonsten muss ich zumindest sagen, dass der Editor an sich mittlerweile besser zu bedienen als noch am Anfang. Da hat sich ein wenig was getan. Auch wenn er immer wieder etwas frickelig ist. Schaumer mal, was noch kommt.
Ich weiß ja ihr auf dem Sofa wollt Divi nicht und Divi wird sterben (ja, das meine ich leider ganz unironisch), aber als Beispiel wie es da ist:
Der Admin hat alle Möglichkeiten die es gibt, einzelnen Rollen kann dann granular jede einzelne Möglichkeit gestattet / verboten werden. zB ein Autor darf nichts in Sachen Layout, ein Redakteur aber eben z.B. solche Sachen wie Border / Padding oder Animationen.
Diese Idee mit der theme.json finde ich persönlich als äusserst frickelig für etwas was man 2022 einführt, das fühlt sich eher wie aus dem letzten Jahrzehnt an …
Ich mag den neuen Editor, aber inzwischen bin ich auch ganz schön müde. Es geht zwar ständig weiter, aber es ist öfter mal ein ziemliches Überraschungspaket, das einem auf die Füße fällt. Andererseits bewegen sich viele Dinge auch gar nicht. Und FSE ist eine Baustelle.
Sicher kommt meine Müdigkeit auch woanders her und Müdigkeit macht bekanntermaßen grantig. Aber mit fällt es gerade sehr schwer, mich mit Gutenberg und FSE konstruktiv zu befassen.
Können wir mal ein Meetup machen zum Thema „Was mach ich jetzt, wenn ich ein neues Projekt anfange?“
Wahrscheinlich gab es das schon tausend Mal und ich hab’s verpasst ;o)
Ich hab irgendwie das Gefühl, ich hab den Überblick verloren.
Ich halte das für eine gute Idee. Die Vorgehensweise hat sich in den letzten Monaten ordentlich geändert und das ist nur bei wenigen angekommen und noch weniger wissen es im Detail genau.
Und ich sitze nebendran, und beobachte, wie jeder unglücklich mit dem üblichen Geschluder Marke Auttomatic ist .. trinke nen Tee, und benutze weiterhin ClassicPress. Ohne Gutenborg, ohne bizarre JS-Verrenkungen, die selbst mit ACF Blocks nur halbherzig funktionieren, und mit einem Page Builder meiner Wahl 😎🦇
Das „Argument“ verstehe ich nicht. Man kann auch WordPress beibringen, den klassischen Editor zu verwenden. Entweder durch das entsprechende Plugin oder aber manuell mit einem Code-Schnipsel.
Dennoch möchte ich klar hervorheben, dass ich durchaus gern mit dem Gutenberg-Editor arbeite und er rein funktional die richtige Entscheidung ist, wenn man auf moderne Weise Inhalte veröffentlichen will. Mit dem klassischen Editor hat man schlichtweg keine wirkliche Freiheit im Layouting der Seite und somit immer mehr vom Gleichen. Spaß macht mir das nicht. Dann doch lieber etwas progressives, als in der Vergangenheit festzuhängen.
@fwolf: CP ist toll, aber täglich fallen etliche Plugins aus, weil deren Hersteller das „veraltete WP“ nicht mehr unterstützen. Und wegen der paar 1000 CP Sites werden die das nicht ändern, sondern bei WP bleiben und sich vom GutenBorg assimilieren lassen.
Ich bin auch lieber Blogger statt Blocker und FSE Allergiker – muss aber WP wählen.
CP hat nur dann eine Chance, wenn man genug eigene Plugins bringt oder mit WP zusammenarbeitet. Oder?
In diesem Artikel geht es lediglich um den Block-Editor, nicht um ClassicPress, geschweige denn um ClassicPress vs. WordPress. Daher bitte ich, die Diskussion auch auf den Block-Editor zu beschränken. Ich behalte mir daher vor, zukünftige Beiträge, die dies thematisieren, nicht mehr freizuschalten.
Also, ich bin Laie in der Programmierwelt. Ihre Fachsprache verstehe ich kaum. Mein jüngerer Sohn hat mir WordPress eingerichtet. Das Gutenberg-Plagin habe ich selber heruntergeladen. Es steckt voller Überraschungen, an die ich mich erst einmal gewöhnen musste. Hatte einmal eine Seite mit fünf Gedichten überarbeitet. Hernach zeigte diese Seite fünfzen Gedichte – mit Wiederholungen natürlich!
Ich glaube, jetzt in etwa zu wissen, wie ich mit Gutenberg umzugehen habe: Alle Veränderungen in einer einzigen Sitzung vornehmen! Die HTML-Seite dabei nicht verlassen! HTML-Befehle hineinkopieren! Zwischen ihnen große Abstände lassen (mindestens zwei Leerzeilen!)!
Versucht es auch mal. Viel Spaß!
Ich kann dir zumindest empfehlen, das Plugin zu deinstallieren. Das ist seit WordPress 5.0 eigentlich nur noch für Entwickler sinnvoll, da hier laufend neue Funktionen hinzukommen, die auch teils noch sehr umfangreichen Änderungen unterliegen. Dadurch wird die gesamte Funktionalität natürlich noch stärker verändert, da es hier wesentlich häufiger Aktualisierungen gibt als dann im WordPress Core.
Nach mehr als 50 Jahren Tätigkeit in der grafischen Welt, in Zeiten, in denen man durch die Erfindung Gutenbergs (die bewegliche Letter) ein ausgezeichnetes Einkommen erzielen konnte, in denen man für eine Kugelkopf-Schreibmaschine, die sagenhafte 2000 Schriftzeichen speichern konnte, 25.000 DM bezahlte und in denen für eine 800 MB externe Festplatte mal eben 18.000 DM hingeblättert wurden, ist es mal an der Zeit, darauf hinzuweisen, wie großartig das kostenlose Programm WordPress mit seinem Gutenberg Block-Editor doch ist.
Die von uns, als reine WordPress-Amateure, seit vielen Jahren gepflegte und immer wieder auf den neuesten Stand gehaltene Webseite ist nicht fehlerfrei, sie wird es wohl auch nie sein, und das ist auch gut so. Sogar Google Lighthouse und andere Webseitentester strahlen mit höchsten Punktzahlen nach einem erfolgten Testlauf unserer Webseite. Und das alles funktioniert mit kostenlosem WordPress, kostenlosem Theme und kostenlosen Plugins. Es ist einfach atemberaubend, wie sich die Welt vom Gutenberg Bleisatz bis zum heutigen Gutenberg Blockeditor verändert hat.
In diesem Sinne. . . .
Take a break and relax.
Ich bin mir nicht sicher, ob ich das richtig verstehe, was du sagen willst. Wie ich es aber verstehe: WordPress ist kostenlos, also beschwert euch nicht.
Das kann ich nicht nachvollziehen. Denn auch, wenn ich hier einen kritischen Beitrag über den Block-Editor geschrieben habe, so finde ich dessen grundlegende Funktionalität durchaus sinnvoll und habe Spaß dabei, Blogbeiträge zu schreiben. Die Entwicklung des Block-Editors selbst ist ein logischer Schritt und klar ein Fortschritt beim Schreiben und der Gestaltung von Blogbeiträgen und anderen Inhalten. Kritik ist aber wichtig, egal ob etwas kostenlos zur Verfügung steht oder nicht.
Als Anwender kann ich nur sagen, Gutenberg ist (im Vergleich zum Classic Editor) einfach viel besser, weil ich die alte Blogartikel Form, wie man sie mit Classic meistens vorfindet – Bild, Text, Bild, Text – extrem langweilig und total antiquiert finde. Endlich kann man anspruchsvoller layouten und ich nütze nicht alle Funktionen, komme aber langsam hinter die Feinheiten und bin sehr glücklich darüber. Habe schon ca. 100 Artikel mit Gutenberg geschrieben und stelle voll um. Davor habe ich Classic und Avada benutzt, aber der Source Code mit Avada ist aufgebläht und seine Bildergalerien sind Mist. Als Entwickler kann ich nicht mitreden, aber als Anwender bin ich zuversichtlich, dass es zwar Zeit braucht, aber di Fortschritte können sich sehen lassen.
Dieser Artikel spricht mir aus der Seele. Ich mache meine Seite seit Jahren selbst, bin aber Berufsfremd, d. H. Kein Programmierer. Der blockeditor ist unwichtig für mich,mir auch zu kompliziert, mich reinzuarbeiten. Ich habe das mal für eine neue Seite probiert, aber verworfen.
Wichtig für mich ist, dass die abwärtskompatiblitat länger bestehen bleibt.
Sonst geht es wordpress wie filemaker. Es macht keinen Spaß, ständig neue Strukturen umzulernen für immer das gleiche Ergebnis