Ich bin ein großer Fan von Gutenberg. In den letzten Wochen hatte ich allerdings gleich mehrfach das zweifelhafte Vergnügen, bei dem Seiten nach dem Aktualisieren plötzlich im Frontend zerschossen waren, obwohl nicht groß etwas geändert wurde.
Der Grund: ein Block-Plugin hatte ein Update spendiert bekommen, mit dem das Markup der Blöcke geändert wurde. Dadurch griffen CSS-Änderungen nicht mehr, die ich im Theme gemacht hatte. Gut, das hätte auch mit Markup passieren können, das über Shortcodes generiert wird.
Wenn Gutenberg-Blöcke aber so umgesetzt sind, dass das Markup statisch in der Datenbank gespeichert und nicht erst beim Seitenaufruf generiert wird (zumindest bei meinen Blöcken der Normalfall, wenn ich nicht auf Informationen dynamisch zugreifen muss), dann sieht die Website nach dem Update des Plugins erst mal weiter normal aus, weil sich das Markup erst aktualisiert, wenn die Seiten oder Beiträge aktualisiert werden.
Daran hatte ich nicht gedacht, und deshalb flog dem Kunden dann das Seitendesign ein bisschen um die Ohren, statt mir direkt nach dem Update. Bei einem anderen Fall haben die Blöcke im Backend nicht mehr funktioniert, da ich etwas naiv die von Gutenberg bereitgestellten Filter genutzt hatte, um die Bearbeiten-Funktionalität eines Blocks umzubauen.
Mein kurzfristiges Fazit daraus ist, dass ich möglichst nur Blöcke von Drittanbietern nutze, wenn sie zu 100 Prozent passen, also keine Anpassung notwendig ist. Da das nicht oft der Fall ist, wird es erst mal auf mehr Eigenentwicklung von Blöcken hinauslaufen.
Idee für eine Problemlösung
Das kann langfristig natürlich nicht das Ziel sein, aber ich möchte auch ungerne nach einem Update alle Seiten und Beiträge manuell aktualisieren, um dann zu prüfen, ob noch alles heile ist. Daher überlege ich an einer Lösung herum, die automatisch die Seiten und Beiträge aktualisiert, nachdem ein Update eingespielt wurde. Das sollte nicht allzu schwer umzusetzen sein (berühmte letzte Worte eines Entwicklers vor einer dann doch schwierigen Aufgabe).
Am besten wäre natürlich, das Tool würde vorher einen Screenshot des Inhalts machen, um nach dem Update vergleichen zu können, ob alles weiter korrekt dargestellt wird.
Das Sahnehäubchen wäre noch eine automatische Rollback-Funktion, wenn bei der Prüfung ein Fehler gefunden wird, aber das (und die Screenshot-Vergleichfunktion) führt für den Anfang vielleicht etwas zu weit.
Da haben diese Blockentwickler wohl vergessen, das tolle Deprecated Blocks Feature zu nutzen:
https://developer.wordpress.org/block-editor/developers/block-api/block-deprecation/
Das ist die offizielle "Lösung" für Dein Problem.
Natürlich ist das Konzept des komplexeren statischen HTMLs im post_content per se unsinnig, daher benutzen auch alle, die sich nur ansatzweise mit Gutenberg und seinen Shortcomings befasst haben, nur noch dynamische Blöcke mit server-side "Live Rendering":
https://developer.wordpress.org/block-editor/tutorials/block-tutorial/creating-dynamic-blocks/
Dieses PHP Rendering Feature wurde allerdings eigentlich ursprünglich nur für die Transition von Shortcodes zu Gutenberg Blöcken geschaffen, was auch unmissverständlich in der Doku steht:
> Server-side render is meant as a fallback; client-side rendering in JavaScript is always preferred (client rendering is faster and allows better editor manipulation).
Aber nunja, das ist dann eben die "digital debt", die man jetzt bezahlt, wenn man ein mangelhaftes Konzept in den WordPress Core ausrollt, bevor es eine anständige Fieldes API o.ä. Grundlage für strukturierte Daten für Blöcke gibt, siehe auch uraltes Ticket #2718 im Gutenberg github.
Hi,
Nein, haben sie nicht, dass das Frontend zerschossen war lag an meinen CSS-Anpassungen. Und in dem anderen Fall mit den kaputten Blöcken ging er kaputt, weil ich die Edit-Komponente umgebaut habe.
Ich wage mal zu behaupten, dass ich mich mindestens ansatzweise mit Gutenberg und den Shortcomings befasst habe, und trotzdem nicht ausschließlich dynamische Blöcke nutze. Dein »alle« würde ich also mal in Frage stellen 🙂
Viele Grüße
Florian
Denke eher das in dem beschriebenen Fall ein Issue bei dem entsprechenden Block-Hersteller sinnvoll wäre. Dort auf die Nachteile der Arbeitsweise hinweisen und zukünftigt das Problem für sich und andere Benutzer auszuräumen.
Denke nur so bekommt man "bad practice" durch "best practice" ersetzt.
Einen riesigen Technologie-Aufwand auf ein unzureichendes aber abstellbares Verhalten des Herstellers zu werfen ist nicht gerade Aufwand- und Ressourcen-schonend.
Betreibe ein "Visual Regression Testing" für größere Projekte. Das frisst ziemlich viel Zeit und ist auch nicht 100% automatisierbar.
Es grüßt
derRALF
Hi Ralf,
danke für deinen Kommentar!
Klar, am besten wäre, das Markup würde gar nicht geändert, aber das ist denke ich eher unwahrscheinlich zu erreichen (ich vermute, es wird auch Fälle geben, wo Markup geändert werden muss).
Ich werde die Devs aber mal anschreiben, gute Idee, vielleicht hilft es ja.
Viele Grüße
Florian
Nachtrag: die Änderung war zumindest in einem Major Update, das heißt man hätte mit Breaking Changes rechnen können 😬