Ein Kommentar zu Gutenberg 16.0.0 und warum sich Contributing lohnt!

Dieser Artikel ist Teil unserer WordPress Community Reise. Wir sind auf ein Problem mit Gutenberg 16.0.0 gestoßen und so haben wir es behoben.

Tisch, auf dem ein Rechner, eine Kaffeetasse und ein WordPress Block liegen

Portrait von Sandra Kurze

Sandra Kurze /

04.08.2023


Natürlich hätten wir diesen Artikel auch etwas keck nennen können: Kompatibilitätsherausforderungen meistern: Ein genauer Blick auf Gutenberg 16.0.0. Aber in diesem Artikel geht es nicht nur um ein Problem in Gutenberg, das endlich behoben wurde.

Er soll allen zeigen, dass es sinnvoll ist, sich an den Diskussionen und Fehlerberichten auf GitHub zu beteiligen! Dies ist ein Teil unserer WordPress Community Reise. Denn egal, aus welchem Blickwinkel wir die Sache betrachten: Letztendlich ist WordPress das Mittel für unser tägliches Brot.

Bauen auf dem Block Editor

Als Team, das sein Produkt nativ auf dem Block Editor aufbaut, ist es unsere Aufgabe, 100%ige Kompatibilität zu gewährleisten. Das ist ein wichtiger Aspekt, um ein einwandfreies Nutzererlebnis zu bieten. Gutenberg-Updates beinhalten jedoch oft weitreichende Änderungen, die nicht immer vollständig nachvollziehbar oder dokumentiert sind. Deshalb führen wir ausführliche Tests durch, bevor wir unseren Kunden neue Core Updates empfehlen. Im Backend zeigen wir daher stets aktuelle Informationen über die unterstützten Versionen, damit unsere Nutzerinnen und Nutzer auf dem Laufenden bleiben.

Wir sind auf ein großes Problem gestoßen

Bei unseren jüngsten Tests mit Gutenberg 16.0.0 sind wir auf ein großes Problem im Zusammenhang mit dem iFrame Enqueuing gestoßen. (Falls dich die vielen Fachbegriffe verwirren, findest du am Ende dieses Artikels eine Erklärung).

Die Einführung der Enqueue-Warnung führte zu vielen Konsolenwarnungen, vor allem wenn die Vorschau auf “Tablet” oder “Mobile” geändert wurde. Infolgedessen waren sowohl unsere verarbeiteten Stile als auch unsere Inline-Stilelemente jetzt “falsch”. Obwohl diese Warnungen keine unmittelbaren Probleme darstellten, führten sie zu einem fatalen Fehler, wenn wir zurück auf den Desktop wechselten. Der ausgewählte Block konnte nicht mehr bearbeitet werden und zeigte die Meldung “In diesem Block ist ein Fehler aufgetreten und eine Vorschau ist nicht möglich.”

Wir haben auf GitHub nachgesehen, ob jemand anderes dieses Problem bereits gemeldet hatte. Wir fanden es im Pull-Request von ellatrix, der zwar verlinkt, aber seit mehreren Wochen unbeantwortet war. Da wir neu darin sind, Code oder Vorschläge zum Gutenberg-Projekt beizutragen, haben wir fälschlicherweise angenommen, dass dies Teil eines Tickets (Bug Report) war.

Die Auswirkungen des Problems

Dies war ein erhebliches Problem für uns. Die meisten unserer Stile sind dynamisch und basieren auf dem GREYD Styles Konzept. Eine Änderung war nicht möglich. Unsere Stilverarbeitung ist auch in der Classic Suite für die korrekte Anwendung der Thememods unerlässlich. Wir stellten fest, dass auch andere Tools wie Editor Plus betroffen waren, ohne dass es dafür eine Lösung gab.

Maßnahmen ergreifen

Da wir die Schwere des Problems und seine Auswirkungen auf die WordPress-Community erkannt haben, haben wir etwas getan, was wahrscheinlich nicht die eleganteste Lösung ist. Wir haben uns an Birgit Pauli-Haack gewandt, da wir wussten, dass sie ein Mitglied des 6.3-Release-Teams ist. 

Eine wichtige Lektion

Von Birgit erfuhren wir, dass der Grund für die ausbleibende Antwort darin lag, dass der PR bereits zusammengeführt war. Sobald das passiert, bekommt er nach der Veröffentlichung nicht mehr viel Aufmerksamkeit. Sie erklärte: “Obwohl es sich um ein schwerwiegendes Problem handelte, wurde es auf Seite 10 statt auf Seite 1 gemeldet, und bei dem Aufwand, der betrieben wird, um auf neu eingehende Fehlerberichte zu reagieren, wird ein Kommentar zu einem bereits abgeschlossenen PR kaum noch beachtet.” Danke, Birgit, das ist eine Lektion, die wir gerne mit anderen teilen, damit sie daraus lernen können.

Auf ihre Bitte hin haben wir ein offizielles Ticket zu den iFraming-Problemen beim Wechsel zur Vorschau erstellt (Issue #52648). Es wurde dann umgehend an die zuständigen Personen weitergeleitet.

Eine schnelle Lösung

Die gemeinsamen Bemühungen trugen Früchte und das Problem wurde innerhalb weniger Tage gelöst und in den WordPress Release 6.3 aufgenommen. Wir sind so glücklich! Vor allem, weil wir wissen, dass noch mehr Menschen und Plugin-Firmen von der Lösung profitieren werden. Sie wurde zu den Entwicklungsnotizen auf Make WordPress hinzugefügt.

Fazit

Die rasche Lösung des Problems zeigt die Stärke der WordPress-Entwicklergemeinschaft. Wir werden auch weiterhin mit ihrer Entwicklung Schritt halten und dafür sorgen, dass unsere Nutzerinnen und Nutzer immer die bestmögliche Usability bekommen, frei von Hindernissen und Störungen. Wir bedanken uns bei allen, die am Core und am Gutenberg-Projekt beteiligt sind, und versprechen, beim nächsten Mal den offziellen Weg zu gehen.

Die Geek Speak Übersetzung einiger Begriffe in diesem Artikel

Das Problem mit den Konsolenwarnungen in nicht-technischen Worten:

Stell dir vor, du versuchst, ein Buch zu lesen, aber jedes Mal, wenn du die Seite umblätterst, siehst du eine Warnmeldung, dass etwas falsch sein könnte. So ähnlich war es auch bei einer kürzlich durchgeführten Aktualisierung der von uns verwendeten Software. Wenn man versucht zu sehen, wie eine Website auf einem Tablet oder Mobiltelefon aussehen würde, zeigt dieses Update plötzlich viele Warnmeldungen an.

Zunächst schien noch alles in Ordnung zu sein, aber beim Zurückschalten, um zu sehen, wie die Website auf einem normalen Computer (Desktop) aussehen würde, trat ein großes Problem auf. Es war, als ob eine der Seiten im Buch zusammengeklebt wurde und man sie nicht mehr lesen konnte. Auf dem Bildschirm erschien die Meldung “In diesem Block ist ein Fehler aufgetreten, und eine Vorschau ist nicht möglich”, d. h. man konnte diesen Teil der Website nicht mehr bearbeiten oder gar ansehen.

Was ein “Pull Request” in nicht-technischen Begriffen bedeutet:

In WordPress tragen verschiedene Personen zur Software bei, indem sie Teile des Codes schreiben, um neue Funktionen hinzuzufügen oder Probleme zu beheben. Wenn jemand seinen Teil fertiggestellt hat, reicht er einen “Pull Request” ein. Das ist so, als würde man die Hand heben und sagen: “Hey Leute, ich habe ein paar Änderungen vorgenommen oder etwas Neues zum WordPress-Projekt hinzugefügt. Könntet ihr bitte einen Blick darauf werfen und überlegen, ob ihr es zum Hauptprojekt hinzufügt?”


Portrait von Sandra Kurze

Von Sandra Kurze

Texten ist eine absolute Leidenschaft von Sandra – am liebsten natürlich zu Themen, die sie auch inhaltlich fesseln. Mit Websites und Online Marketing beschäftigt sie sich seit mehreren Jahren – sowohl aus Dienstleister- als auch aus der Kunden-Perspektive. Perfekte Voraussetzungen also für den Greyd Blog!

Recent in Learn

Was tun, wenn deine WordPress-Seite gehackt wurde?

Mehr erfahren

A pen rests on top of a stylized table grid with the HTML tag prominently displayed in bold white text, symbolizing the structure of tabular data in web development.

Use Case Tutorial: Wann man eine Tabelle statt eines Divs verwenden sollte

Mehr erfahren

10 Tipps für nachhaltige Websites

Mehr erfahren

Skalierung von Inhalten (mit WordPress)

Mehr erfahren

ein alter PC mit einem futuristischen Wordpress-Logo

Lasst uns über die Zukunft von WordPress sprechen!

Mehr erfahren