Gutenberg 24.2 und React 19: was Sie in Ihren Custom Blocks testen sollten

Gutenberg 24.2 ist ein kleines Produkt-Release für Redaktionen und ein Kompatibilitätssignal für Block-Autoren. Randnotizen und eine einzige Navigation-Suche senken die Reibung in Content Ops. React 19 standardmäßig im Gutenberg-Plugin verlagert die Tests eigener Blöcke auf Staging: eine jetzt gefangene Regression kostet weniger als dieselbe Regression, nachdem diese Linie in Core landet. Wer auf die Ankündigung „React 19 in WordPress X.Y“ wartet, lässt denselben Fehler auf der Produktionsseite des Kunden.

WordPress 7.1 hat React 19 nach Kompatibilitätsproblemen aus dem Zip gelassen. 24.2 hebt diese Entscheidung nicht auf; es beschleunigt die Testspur im Gutenberg-Plugin.

Eigene Blöcke oder ein FSE-Shop und kein Risiko für ein Production-Update? Beschreiben Sie den Stack (PHP, WP, WooCommerce, Editor-Plugin-Liste) über Kontakt. Sie erhalten einen Staging- und Abnahmeplan, nicht nur das Changelog.

#Was ist neu in Gutenberg 24.2

#Notes im Gutenberg-24.2-Editor

Notes sitzen neben dem Inhalt, nicht nur in der Seitenleiste. Beim Review eines Artikels oder einer Landing Page kommentiert die Redaktion am konkreten Block. Weniger Springen zwischen Panel und Canvas.

Für Agenturen mit mehrköpfigem Content Ops ändert das den Rhythmus:

• der Copywriter hinterlässt einen Hinweis am H2, nicht in einem Slack-Thread ohne Kontext,
• der Reviewer sieht im zweiten Durchgang einen Stapel Hinweise am Block,
• der Block-Entwickler sieht, welche UI-Stellen die meiste redaktionelle Reibung erzeugen (oft eigene Blöcke mit unklarem Inspector).

Code-Änderungen gehen weiterhin nach Linear/Jira. Notes ersetzen Screenshots mit rotem Pfeil im PDF beim Content-Review.

#Seiten und Kategorien im Navigation-Menü suchen

Seiten, Beiträge, Kategorien und Tags über ein einziges Suchfeld zur Navigation hinzufügen. Beim Umbau der IA (besonders mehrsprachig) sinken Klickzahl und Fehler „falsche Seite aus der Liste“.

Praktischer Staging-Test: Menü mit Mix aus page + category + custom link bauen, speichern, Front aktualisieren, Mobile-Overlay prüfen. Navigation-Regressionen zeigen sich oft erst am Front, nicht im Editor.

#Gallery in Gutenberg 24.2: Sortierung und Duotone

Die Steuerung Order by funktioniert jetzt auch bei Galerien aus handverlesenen Bildern (neueste, älteste, A bis Z, Z bis A oder zufällig bei jedem Seitenaufruf), und ein Duotone-Filter färbt alle Bilder einer Galerie, im Block oder seitenweit über Global Styles. Prüfen Sie:

• Custom-CSS, das altes Filter-Markup annimmt,
• Kindblöcke / Gallery-Variationen im Child Theme,
• Lazy Load und CLS bei geänderter Bildreihenfolge,
• Export nach AMP oder Headless (wenn Sie Blöcke außerhalb eines klassischen Themes ausliefern).

Duotone wirkt kosmetisch, bis es den Kontrast auf Produktfotos zerstört. Im Shop Gallery auf der Produktkarte prüfen, nicht nur im Blog.

#React 19 in Gutenberg 24.2 (standardmäßig)

Das ist das Hauptsignal für den Entwickler-Stack. Websites mit dem Plugin laden jetzt React 19 für die Skripte react und react-dom, außer ein Theme oder Plugin mit bekannten Kompatibilitätsproblemen ist aktiv; diese Websites bleiben auf React 18. Bricht etwas, lässt sich React 19 unter Gutenberg > Experiments abschalten. Für das Attribut inert gibt es das neue Paket @wordpress/react-inert-value, das mit React 18 und 19 funktioniert (Release-Beitrag zu 24.2).

Plugins und Themes mit React im Editor sollen testen und melden. Warten Sie nicht auf ein Datum im Core: die Roadmap to 7.2 hält eine vollständige Landung in 7.2 für unwahrscheinlich, also zeigen sich Regressionen zuerst im Plugin.

Typische Bruchstellen nach einem React-Upgrade:

• react/jsx-runtime im Plugin-Bundle statt des externen Skripts, das WordPress bereitstellt (dann laufen React 18 und 19 nebeneinander),
• in React 19 entfernte APIs: String Refs, Default Props bei Funktionskomponenten, Legacy Context,
• eigene Blöcke mit veraltetem @wordpress/scripts / altem webpack,
• Slot Fills und Plugin-Sidebars mit alten Lifecycles,
• React-18-Peers in der package.json des Kunden-Plugins,
• Playwright/Cypress-E2E, die auf Timings aus 18 fixiert waren.

Wenn Sie eine Block-Bibliothek für mehrere Kunden pflegen, ist ein Staging mit 24.2 auf einem repräsentativen Projekt günstiger als fünf Hotfixes nach Core.

#Gutenberg 24.2, WordPress 7.1 und React 19 im Core

In 7.1 kam React 19 nicht in Core. Die Entscheidung war für die Ökosystem-Stabilität richtig und für Teams, die schon vorbereitet hatten, unbequem. Gutenberg 24.2 ist der offizielle Ort, an dem das Ökosystem React 19 spüren kann, ohne es auf jede Installation ohne Gutenberg-Plugin zu erzwingen.

Für Agenturen bedeutet das drei Spuren:

1. Kunde ohne Gutenberg-Plugin in Produktion - bleibt vorerst auf Core-React (Linie 7.1). Tests planen; das Gutenberg-Plugin nicht „weil 24.2 raus ist“ installieren.
2. Kunde mit Gutenberg-Plugin (Early Features) - 24.2 ist Pflicht-Staging vor dem Update.
3. Eigene Produkte / Blöcke für viele Kunden - CI gegen Gutenberg 24.2 + PHP/WP-Matrix.

Vermischen Sie diese Botschaft nicht mit dem WordPress.com Agent: anderes Produkt, andere Spur (Agent und MCP write). Der Agent testet Ihre Blöcke nicht unter React 19.

#Checkliste: Gutenberg 24.2 auf Staging testen

1. Gutenberg 24.2 auf einer Produktionskopie installieren (nicht live beim Kunden). Unter Gutenberg > Experiments prüfen, ob React 19 aktiv ist: mit einem Plugin von der Inkompatibilitätsliste bleibt die Website auf React 18, und der Test sagt nichts über 19.
2. Beitrag mit Ihren Custom-Blöcken öffnen: insert, duplicate, move, save, preview, undo.
3. Navigation prüfen: Seite und Kategorie suchen, Menü speichern, Front und Mobile aktualisieren.
4. Gallery mit Duotone: Filter an, Reihenfolge ändern, speichern, Front prüfen.
5. Notes: Hinweis am Block, Editor neu laden, Persistenz prüfen, löschen.
6. WooCommerce-Smoke (falls Shop): Produkt, Warenkorb, Checkout, E-Mail.
7. Bei Fehler: minimale Reproduktion + PHP-/WP-/Gutenberg-/Plugin-Versionen im Issue-Tracker.

Erweiterung bei Block-Bibliothek (2-4 Stunden):

• Unit-/Integrationstests des Pakets,
• sauberer Asset-Build (npm ci + build),
• React-peerDependencies prüfen,
• Bundle-Größe vor/nach vergleichen (Regression oft mit doppeltem React).

#Was Sie bei der Aktualisierung von Gutenberg 24.2 vermeiden

• Das Gutenberg-Plugin nicht ohne Rollback-Plan und Wartungsfenster im Live-WooCommerce-Shop aktivieren.
• Dem Kunden nicht „React 19 morgen im Core“ versprechen. 24.2 ist ein Plugin.
• Notes nicht als Ticket-System für Entwickler behandeln.
• Nicht zehn Kunden am selben Tag updaten „weil 24.2 raus ist“. Ein repräsentatives Staging, dann die Welle.

#Gutenberg 24.2 im Wartungs-Retainer

Ein Kunde mit Retainer „WordPress-Updates“ sollte im Monatsbericht eine eigene Zeile bekommen: Test Gutenberg 24.2 / Spur React 19. Das ist eine Block-Kompatibilitätssession, getrennt vom normalen Core-Bump.

Deckt der Retainer keine Editor-Tests ab, Change Request vor dem Gutenberg-Update auf Staging. Einmal günstig. Teuer, wenn der Editor am Kampagnen-Publish-Tag stirbt.

#Notes und Navigation-Suche im redaktionellen Alltag

Notes

• ein Hinweis = eine Entscheidung (Copy / Layout / Legal),
• keine Philosophiefäden im Rand,
• nach Merge zum Final: Notes löschen oder archivieren, damit der Canvas nicht wie Graffiti aussieht.

Navigation-Suche

• Seitennamen im Admin müssen eindeutig und lesbar sein (doppelte „Angebot“-Seiten in zwei Sprachen ohne Locale-Präfix verwirren die Suche),
• nach Menü-Umbau: Struktur in ein IA-Dokument exportieren (auch Markdown-Tabelle) als Wahrheit außerhalb von WordPress.

#Gutenberg 24.2 an WooCommerce und Membership testen

Ist die Site ein Shop oder Membership statt Blog, reicht die allgemeine Checkliste nicht. Ergänzen Sie:

• Single-Product-Template im Site Editor (nicht nur klassisches Produkt),
• Warenkorb-/Checkout-Blöcke (Woo-Blöcke vs. Legacy-Shortcode),
• Restricted-Content-Blöcke (Membership, Paywall),
• Preview als eingeloggter Nutzer vs. Gast,
• Produkt-Draft mit Gallery + Duotone speichern (ob der Shop-Front den Filter auf Grid-Thumbnails erbt).

Eine React-Regression im Produkt-Inspector kann eine Black-Friday-Kampagne härter blockieren als eine Regression am Blogpost. Shop-Staging vor dem Firmenblog priorisieren.

#Gutenberg 24.2, Child Theme, FSE und theme.json

Agenturen halten oft „ein paar Zeilen“ in theme.json und Child-Theme-style.css. Nach 24.2 prüfen:

• Gallery- und Duotone-Overrides in theme.json,
• CSS auf Klassen, die Notes oder die neue Navigation-UI geändert haben können,
• synchronisierte Patterns mit altem Markup.

FSE entbindet nicht von Tests. Je mehr UI in JSON und Patterns lebt, desto mehr Stellen, an denen React 19 im Editor ein leeres Panel oder einen Endlos-Spinner zeigen kann. Hintergrund zu Blöcken, Patterns und Site Editor: Gutenberg-Blöcke und Full Site Editing.

#Wie Sie dem Kunden Gutenberg-24.2-Testergebnisse melden

Drei Absätze nach dem Staging-Test reichen:

1. Was getestet wurde (Blockliste + Navigation + Gallery + Notes).
2. Was gefunden wurde (konkret: „Inspector von Block X verliert Focus“, nicht „Editor verhält sich seltsam“).
3. Entscheidung: Gutenberg aktualisieren / auf Upstream-Fix warten / bis Datum Y auf Core ohne Plugin bleiben.

Kunden akzeptieren ein verzögertes Update, wenn sie eine Testliste sehen. Sie akzeptieren nicht „irgendwie kaputt nach Update“ ohne diese Liste.

#Wie Sie einen Bug in Gutenberg 24.2 melden

Ein Issue im Plugin-Repo oder auf Gutenberg GitHub sollte haben:

• Versionen: WP, PHP, Gutenberg, Browser,
• Reproduktionsschritte in fünf Zeilen,
• erwartet vs. tatsächlich,
• ob nur mit Ihrem Block oder auf Twenty Twenty-Five + Core-Blöcken.

„Bei uns geht es nicht“ ohne Reproduktion landet im Limbo. Eine gute Reproduktion auf sauberer Umgebung beschleunigt den Fix mehr als zehn „+1“-Kommentare.

#React-19-Testmatrix für eine Block-Bibliothek

Ein Staging bei einem Kunden reicht nicht, wenn Sie Blöcke an viele Marken verkaufen. Minimale Matrix:

Automatisierung: ein CI-Workflow, der Gutenberg 24.2 installiert, Blöcke baut, Playwright-Smoke auf insert/save fährt. Navigation, Gallery-Duotone und Notes manuell lassen - E2E ist an UI-Rändern fragil.

Matrix-Kosten amortisieren sich beim zweiten Kunden mit derselben Block-Bibliothek. Für ein statisches Landing reicht die 15-30-Minuten-Checkliste.

#Typische Regressionen nach React 19 in Gutenberg

Aus React-Upgrades im WordPress-Ökosystem (nicht nur 24.2) kommen oft:

• doppeltes React im Bundle (Symptom: seltsame Console-Warnungen, inkonsistenter State),
• Inspector-Controls, die bei jedem Keystroke den Focus „verlieren“,
• dynamische SSR- vs. Client-Blöcke: Hydrate-Mismatch nach Gallery-Markup-Änderung,
• ältere @wordpress/components-Peers inkompatibel mit neuem React,
• E2E auf Selektoren, die Notes oder die neue Navigation-Suche im DOM verschoben haben.

Jede Regression mit Gutenberg-Version im Issue-Titel speichern. „Editor kaputt“ ohne Versionsnummer ist für Bisect nutzlos.

#Gutenberg Notes und Echtzeit-Zusammenarbeit

In derselben Woche veröffentlichte Make WordPress Core einen Leitfaden zu den Sync Engines, die für Echtzeit-Zusammenarbeit evaluiert werden. In einem Kommentar unter diesem Beitrag warnte Yjs-Autor Kevin Jahns, dass Live-Bearbeitung sehr viele kleine Nachrichten erzeugt und ein PHP-Worker pro Nachricht viel Overhead bedeutet. Das ist nicht der Changelog von 24.2, aber Kontext für Tech Leads: Spur Mehrpersonen-Kollaboration und Spur React 19 sind getrennte Risiken. Randnotizen lösen asynchronen Review. Sie lösen keinen Konflikt zweier Cursor im selben Block.

Verkaufen Sie dem Kunden kein „Real-time Collaboration“, weil 24.2 raus ist. Verkaufen Sie effizienteren Review und getestete Blöcke.

#Wann Sie Gutenberg 24.2 in Produktion ausrollen

1. Staging grün auf Checkliste und WooCommerce-Smoke.
2. Wartungsfenster vereinbart (nicht Freitag nach 16:00 beim Shop).
3. Rollback: vorheriges Gutenberg-Zip + DB-Backup vor dem Update.
4. Monitoring 24-48 h: JS-Fehler im Editor, Publish-Tickets, Checkout-Failures.

Hat der Kunde Plugin-Auto-Updates an, Gutenberg-Auto-Update bis zum grünen Staging aus. Gutenberg ist nicht „noch ein SEO-Plugin“.

#Release Notes des Block-Plugins nach Gutenberg 24.2

Wenn Sie eigene Blöcke als Plugin verkaufen:

• Changelog-Zeile „tested with Gutenberg 24.2 (React 19 default)“,
• im Readme: minimale @wordpress/scripts / Build-Toolchain,
• in CI: Job gutenberg-next neben wordpress-stable,
• in der Support-Policy: „Meldungen ohne Gutenberg-Nummer schließen wir mit Bitte um Ergänzung“.

Enterprise-Kunden lesen Release Notes. Eine Zeile zu 24.2 baut mehr Vertrauen als vages „improved compatibility“.

#Gallery-Duotone und Marken-Design-System

Duotone in Gallery ist für Redaktionen bequem und für Marken mit striktem Design System gefährlich. Hat der Kunde definierte Filter und Farbtoken:

• Duotone in Produkt-Patterns aus,
• auf Blog / Social Proof lassen,
• Regel in Content-Guidelines festhalten (nicht mit WordPress.com-Agent-Guidelines verwechseln).

Agent und Gutenberg sind getrennte Produkte, aber dasselbe Problem: das Tool gibt der Redaktion Macht, die der Brand Guide nicht vorsah. Ownership des Design Systems bleibt bei der Agentur.

#Warum WordPress 7.1 React 19 verschoben hat

Fakten aus dem Sommer 2026 (Details in der 7.1-Roadmap): das Upgrade von React 18 auf 19 fiel aus 7.1, nachdem ein kurzer Versuch in Gutenberg unerwartete Inkompatibilitäten zwischen beiden React-Versionen und in der Art zeigte, wie Plugins React nutzen. Im Make-Core-Beitrag vom 24. Juli 2026 schrieb Jarda Snajdr, dass eine längere Testphase nötig ist, um die Kompatibilitätsschicht abzustimmen. 24.2 ist die Folge dieser Vorsicht: zuerst Gutenberg-Plugin, dann gegebenenfalls Core.

Für Leads: nicht die Narrative „Automattic kommt zu spät“, sondern „Sie haben ein Testfenster, das Sie nutzen müssen“. Agenturen, die im August die Vorbereitung „weil 7.1 ohne React 19“ abgelegt haben, bekommen im Oktober mit 24.2 eine zweite Chance. Ein drittes bequemes Fenster vor Core mag ausbleiben.

#Freelancer-Blöcke unter Gutenberg 24.2 abnehmen

Wenn ein Freelance-Autor sagt „bei mir läuft es auf Core“, nachfragen:

• ob Gutenberg 24.2 getestet wurde,
• ob in package.json React-19- oder noch React-18-Peers stehen,
• ob eine Reproduktion auf sauberem Staging geliefert wird.

Zahlung für einen Block ohne diese Checkliste ist Risikokauf. Im B2B-Vertrag Abnahme auf Umgebung mit Gutenberg 24.2 als Lieferbedingung.

#Editor-Performance nach React 19 in Gutenberg

Neueres React verbessert oft Concurrent Features, aber auf schwachen Redaktions-Laptops oder einem VPS mit schwerem Admin sehen Sie möglicherweise:

• längere Zeit bis Inspector-Interaktivität,
• Jank beim Drag-and-Drop einer großen Gallery,
• höheren Speicherverbrauch bei vielen Notes gleichzeitig.

Subjektiv auf Hardware der Redaktion messen (nicht nur M-Series des Entwicklers) und objektiv: DevTools Performance Panel beim Speichern eines Posts mit 40 Blöcken. Wenn Admin-LCP SEO nicht interessiert, interessiert es die Retention des Content-Teams. Wer drei Sekunden auf jede Inspector-Änderung wartet, kehrt zu Classic Editor oder Google Docs zurück.

#Barrierefreiheit von Notes und Navigation in Gutenberg 24.2

Randnotizen müssen per Tastatur erreichbar und für Screenreader lesbar sein. Navigation-Suche muss Ergebnisse für AT ansagen. Nach 24.2:

• per Tab durch Notes und Schließen einer Notiz,
• Focus Trap in Navigation-Modals prüfen,
• nicht annehmen „neue Automattic-UI = WCAG automatisch“.

Für Kunden unter BFSG / EAA / Barrierefreiheitsrecht ist das kein optionaler Test. Das ist Abnahmebedingung für das Template.

#Wann Sie bei WordPress Core ohne Gutenberg-Plugin bleiben

Auf Core bleiben (ohne Gutenberg-Plugin), wenn:

• der Shop so viele Bestellungen/Tag erzeugt, dass kein Fenster für eine Regression bleibt,
• Sie von Editor-Plugins ohne Maintainer abhängen,
• der Kunde „null Admin-UI-Änderungen in Q4“ vertraglich hat.

24.2 trotzdem auf Staging einschalten, damit Sie wissen, was kommt. Wissens-Baseline ist günstiger als die Überraschung am Core-Upgrade-Tag.

#Redaktionsschulung zu Notes in Gutenberg 24.2

Technisches Grünlicht ist die halbe Miete. Die andere Hälfte: 30-Minuten-Workshop für Redakteure.

Agenda:

1. Note am Block setzen und auflösen.
2. Wann Note, wann Ticket im Tracker (Code-Änderung = Ticket).
3. In Navigation suchen ohne Seitenduplikate.
4. Wann Duotone auf Produktfotos nicht anfassen.

Ohne Workshop werden Notes zur Müllhalde und Navigation-Suche zur Quelle schlechter Links. Den Workshop im Retainer als 24.2-Umsetzungszeile führen.

#Risiken von Gutenberg 24.2 für Tech Leads

Eine Tabelle für den Projektstatus:

Fürs Management: 24.2 ist auf Staging günstig und in Produktion ohne Checkliste teuer.

#Wann Gutenberg-24.2-Tests extern beauftragen

Beauftragen Sie einen Review, wenn:

• Sie eine Block-Bibliothek für mehrere Marken pflegen,
• der Shop Umsatz generiert und kein Fenster für Inspector-Regressionen hat,
• ein Freelancer Blöcke „funktionieren auf Core“ ohne 24.2-Test geliefert hat,
• der Retainer „Updates“ die React-19-Spur noch nicht abdeckt.

In der Anfrage: Staging-URL oder Plugin-Liste, WooCommerce-Version, ob HPOS aktiv ist, Deadline des Wartungsfensters. Das reicht, um Smoke versus volle Matrix zu kalkulieren.

#Gutenberg 24.2: Staging vor Produktion

Notes, Menü-Suche und Gallery sind redaktioneller Gewinn. React 19 im Plugin ist Staging-Pflicht für Agenturen, die Blöcke und FSE verkaufen. Update ohne Checkliste verschiebt das Risiko auf den Kunden.

Die Spur Agent / MCP write und die Gutenberg-Spur bleiben getrennt: der Agent testet kein React, React 19 im Plugin schließt kein Publish-Gate bei MCP write.

Block-Review oder Retainer mit Gutenberg-Spur: Kontakt. Breitere Entwicklung: WordPress-Entwickler.