Gutenberg 24.2 und React 19: was Sie in eigenen Blöcken prüfen sollten

Aktualisierung, 3. November 2026. Gutenberg 24.3 ist da (Plugin mit Datum 28. Oktober; What’s-new-Beitrag vom 2. November). Redaktionelle Änderungen, die auf einer Live-Site zählen: Text über eine Mehrblock-Auswahl formatieren, Emoji-Reaktionen an Notizen (Herz, Party, Augen und ein paar mehr), Media-Inserter auf dem DataViews-Raster mit Vorschauen für Nicht-Bilder sowie Speicher-/Autosave-Fehlerhinweise mit Details, HTTP-Status wenn verfügbar, Kopieraktion und Countdown bis zum nächsten Versuch. Das Release enthält außerdem die Sicherheitsfixes aus WordPress 7.1.4 - aktualisieren Sie das Gutenberg-Plugin, wenn es auf Produktion läuft. React 19 bleibt wie in 24.2 standardmäßig an; die Test-Checkliste unten gilt weiter.

Gutenberg 24.2 ist am 14. Oktober 2026 erschienen. Redaktionen bekommen Notizen am Rand des Editors, eine einheitliche Linksuche im Menü und sortierbare Galerien. Für Plugin- und Theme-Autoren zählt eine Änderung mehr: Das Plugin Gutenberg lädt jetzt standardmäßig React 19 statt React 18. Wer auf seiner Website eigene Blöcke oder Einstellungsseiten in React hat, sollte sie jetzt prüfen, bevor React 19 in WordPress selbst ankommt.

Dieser Beitrag stützt sich auf den offiziellen Beitrag zum Release 24.2, die Änderungsliste im Gutenberg-Repository, zwei Beiträge auf Make WordPress Core zu React 19 und den Migrationsleitfaden zu React 19.

#Was ist neu in Gutenberg 24.2?

Das Release bringt fünf wichtige Änderungen:

• Notizen an den Rand neben den Inhalt verlegt,
• eine gemeinsame Suche für alle Linkarten im Navigationsblock,
• Sortierung und ein gemeinsamer Duotone-Filter im Galerieblock,
• weitere Blöcke mit denselben Gestaltungswerkzeugen (rund 80 Codeänderungen),
• React 19 standardmäßig eingeschaltet und zwei Ergänzungen in der Interactivity API.

Dazu kommen über 60 Fehlerkorrekturen sowie Änderungen bei Barrierefreiheit und Leistung. Einige kleinere Änderungen spielen im Alltag eine Rolle. Der Schieberegler für die Spaltenzahl im Spaltenblock ist verschwunden: Eine Spalte fügen Sie mit dem Plus-Knopf neben dem Blockknopf in der Werkzeugleiste hinzu und entfernen sie wie jeden anderen Block. Nach dem Zuschneiden eines Bildes können Sie im Bildeditor zum Original zurückkehren, ohne die Mediathek zu öffnen. Das Autorenfeld eines Beitrags hat immer eine Suche und sucht Benutzer auf dem Server, sodass auf Websites mit vielen Konten die richtige Person in der Liste erscheint.

Gutenberg 24.2 korrigiert auch die Adressen neuer Beiträge. Bisher konnte ein neuer Beitrag mit dem URL-Slug auto-draft veröffentlicht werden, wenn jemand vor der Veröffentlichung in das Slug-Feld geklickt hatte. In 24.2 passiert das nicht mehr. Wenn Sie auf einer Website mit dem Plugin Gutenberg Beiträge mit einer solchen Adresse gesehen haben, war das die Ursache.

Von Plugins hinzugefügte Seitenleisten sind im Optionsmenü des Editors in ein Untermenü für Seitenleisten gewandert, neben die neuen Untermenüs für Darstellung und Notizen. Angeheftete Knöpfe dieser Seitenleisten in der Werkzeugleiste bleiben, wo sie waren. Plugin-Autoren mit eigener Seitenleiste sollten prüfen, ob ihre Anleitungen für Benutzer noch die richtige Stelle beschreiben.

#Ist React 19 schon in WordPress?

Nein. WordPress 7.1 läuft auf React 18.3. Im Juli 2026 hat Jarda Snajdr auf Make WordPress Core beschrieben, warum der Wechsel auf React 19 aus 7.1 herausgefallen ist: Nach kurzem Einschalten im Plugin Gutenberg zeigten sich unerwartete Unverträglichkeiten zwischen alter und neuer React-Version sowie in der Art, wie Plugins React nutzen, und die Änderung musste zurückgenommen werden.

„Wir brauchen eine längere Testphase, in der wir die Kompatibilitätsschicht verbessern und verfeinern, damit bestehende Plugins ohne Probleme funktionieren.“

Quelle: Jarda Snajdr, Make WordPress Core, 24. Juli 2026, eigene Übersetzung

Ab Version 23.4 hatte das Plugin Gutenberg ein Experiment React 19, das man von Hand einschalten musste. Gutenberg 24.2 kehrt diese Einstellung um: Das Experiment ist standardmäßig eingeschaltet. WordPress selbst lädt ohne das Plugin Gutenberg weiterhin React 18.3.

Der Release-Plan für WordPress 7.2 sieht die Veröffentlichung Anfang Dezember 2026 vor. Zu React 19 heißt es dort, dass Typen, Abhängigkeiten und Korrekturen am Rendering in Gutenberg größtenteils fertig sind, der vollständige Wechsel in 7.2 aber unwahrscheinlich ist. Für Teams, die Websites betreuen, heißt das: React 19 im Plugin Gutenberg ist jetzt eine Testphase, kein Einführungstermin in WordPress. Den Hintergrund der Entscheidung aus dem Sommer beschreiben wir im Beitrag zum Plan für WordPress 7.1.

#Wann lässt Gutenberg 24.2 eine Website bei React 18?

Laut dem Release-Beitrag laden Websites mit dem Plugin React 19 für die Skripte react und react-dom, außer ein Theme oder Plugin mit bekannten Kompatibilitätsproblemen ist aktiv. Dann bleibt die Website bei React 18. Die Liste solcher Themes und Plugins begann mit Problemen, die auf WordPress.com beobachtet wurden, und wurde in diesem Release erweitert (Änderung #84607).

Daraus folgen zwei praktische Dinge. Erstens kann dieselbe Gutenberg-Version auf zwei Websites je nach Plugin-Ausstattung unterschiedliche React-Versionen laden. Prüfen Sie beim Testen eines Blocks, welche Version der Editor tatsächlich bekommen hat. Es genügt, in der Browserkonsole auf dem Editorbildschirm React.version einzugeben, denn WordPress stellt React als globale Variable bereit. Zweitens beweist das Ausbleiben von Problemen auf einer Website, die auf der Ausnahmeliste steht, gar nichts. Der Block wurde dann unter React 18 getestet.

Die Ausnahmeliste ist eine Übergangslösung. Steht Ihr Plugin darauf, kehrt das Problem an dem Tag zurück, an dem React 19 in WordPress kommt.

#Wie schalte ich React 19 in Gutenberg ab?

Das Gutenberg-Team schreibt klar, was zu tun ist, wenn etwas nicht mehr funktioniert:

„Wenn Sie ein Plugin oder Theme betreuen, das React verwendet, testen Sie es mit Gutenberg 24.2 und melden Sie jedes Problem, das Sie finden. Wenn auf einer Website etwas nicht mehr funktioniert, schalten Sie React 19 unter Gutenberg > Experiments ab.“

Quelle: What’s new in Gutenberg 24.2, Make WordPress Core, 14. Oktober 2026, eigene Übersetzung

Im WordPress-Adminbereich ist das das Menü Gutenberg, die Seite der Experimente, das Kontrollkästchen bei React 19. Der Juli-Beitrag zum Experiment beschrieb dieselbe Seite als Teil der Gutenberg-Einstellungen. Das Abschalten gilt für die ganze Website, ist also eine Notlösung für die Live-Seite und keine Reparatur des Blocks. Ein Block, der nur bei abgeschaltetem React 19 funktioniert, muss vor einer WordPress-Version mit React 19 korrigiert werden.

Die zweite Möglichkeit ist, das Plugin Gutenberg auf der Live-Seite nicht zu installieren. Eine Website ohne dieses Plugin bekommt React von WordPress, heute also 18.3. Das Plugin Gutenberg gehört auf die Live-Seite, wenn der Kunde Funktionen braucht, die es in WordPress noch nicht gibt. Braucht er sie nicht, testen Sie React 19 auf einer Kopie der Website.

#Welche APIs hat React 19 entfernt und was geht dadurch in WordPress-Blöcken kaputt?

Der Juli-Beitrag auf Make WordPress Core nennt zwei typische Ursachen für Ausfälle von Plugins. Die zweite sind alte React-Funktionen, die seit mindestens sechs Jahren veraltet sind und in React 19 entfernt wurden. Einen Teil davon ergänzt die Kompatibilitätsschicht in Gutenberg, aber nicht alle. Der Migrationsleitfaden zu React 19 nennt die vollständige Liste samt dem Datum, ab dem jede API veraltet war:

Klassenkomponenten behalten defaultProps, weil es für Klassen in der ES6-Syntax keine Entsprechung gibt. Entfernt wurden auch react-dom/test-utils und react-test-renderer/shallow, was Unit-Tests betrifft, nicht den Block selbst.

Im WordPress-Code stößt man am häufigsten auf render, das eine Einstellungsseite oder ein Widget im Adminbereich einbindet. Ältere Plugins importieren es aus @wordpress/element, das intern ReactDOM.render aufruft. Neuere Versionen dieses Pakets exportieren createRoot, und genau das müssen Sie verwenden:

import { createRoot } from '@wordpress/element';

const container = document.getElementById( 'my-plugin-settings' );
if ( container ) {
	createRoot( container ).render( <SettingsPage /> );
}

Der zweite häufige Fall sind defaultProps an einer Funktionskomponente im Blockeditor. In React 19 werden die Standardwerte einfach nicht gesetzt, die Komponente bekommt also undefined und wirft meist keinen Fehler, sondern zeigt ein leeres Feld an oder rechnet einen Wert falsch. Ein solcher Fehler wird leicht übersehen, weil die Konsole schweigt.

Der Leitfaden bietet einen fertigen Satz automatischer Korrekturen: npx codemod@latest react/19/migration-recipe. Führen Sie ihn in einem eigenen Zweig aus und lesen Sie jede Änderung, denn er kennt die Besonderheiten der Pakete @wordpress/* nicht.

React 18.3, auf dem WordPress 7.1 läuft, ist laut dem React-Team identisch mit 18.2, gibt aber Warnungen zu veralteten APIs und anderen Änderungen aus, die für React 19 nötig sind. Wenn Sie in der Editorkonsole eines normalen WordPress 7.1 Warnungen mit dem Namen Ihres Plugins sehen, haben Sie eine fertige Liste der Dinge, die zu korrigieren sind.

#Wie prüfe ich, ob ein Plugin eine eigene Kopie von React mitbringt?

Die erste Ursache aus dem Juli-Beitrag ist häufiger und im Quellcode schwerer zu erkennen, weil sie erst in der gebauten JavaScript-Datei sichtbar wird.

„Wenn alle ihr JavaScript korrekt bauen würden, gäbe es die meisten Kompatibilitätsprobleme gar nicht.“

Quelle: Jarda Snajdr, Make WordPress Core, 24. Juli 2026, eigene Übersetzung

Gemeint ist Code von react/jsx-runtime, der direkt in die Plugin-Datei gepackt wurde, statt das Skript react-jsx-runtime zu nutzen, das WordPress bereitstellt. Dann laufen auf der Website React 18 aus dem Plugin-Paket und React 19 aus WordPress nebeneinander, und Datenstrukturen, die die alte Version erzeugt hat, landen bei der neuen. Die Komponente sieht im Code korrekt aus, wird im Editor aber nicht eingebunden oder wirft einen Fehler zu einem ungültigen Element.

Die Prüfung dauert ein paar Minuten pro Plugin:

1. Öffnen Sie die Datei *.asset.php neben dem gebauten Skript (zum Beispiel build/index.asset.php). Wenn der Code JSX verwendet, sollte react-jsx-runtime in der Liste der Abhängigkeiten stehen.
2. Durchsuchen Sie die gebauten Dateien nach Code von React selbst, zum Beispiel mit grep -l "react.element" build/*.js. Ein Treffer in der Plugin-Datei ist ein Hinweis, dass ein Teil von React im Paket steckt. Das ist ein Grund, die Konfiguration zu prüfen, kein Urteil.
3. Prüfen Sie, ob die Build-Konfiguration den Mechanismus umgeht, der Importe von react und @wordpress/* durch die Skripte von WordPress ersetzt. Das passiert meist bei eigenem webpack oder Vite statt @wordpress/scripts.
4. Bei Plugins, die Sie bei einem externen Anbieter gekauft haben und deren Quellen Sie nicht haben, bleiben der Test im Editor aus dem nächsten Abschnitt und eine Meldung beim Autor.

Das Gutenberg-Team arbeitet daran, diese Probleme im Plugin „Plugin Check“ automatisch zu erkennen. Bis das funktioniert, liegt die Prüfung beim Autor des Plugins.

#Wie teste ich eigene Blöcke mit React 19 auf einer Kopie der Website?

Der Juli-Beitrag definiert den Kompatibilitätstest einfach: alle Teile des Plugins benutzen, die React verwenden, also meist Blöcke, Editor-Erweiterungen und eigene Seiten im Adminbereich, und prüfen, dass die Oberfläche nicht kaputt ist und die Browserkonsole keine Fehler zeigt. Auf einer Testkopie der Website geht das so:

1. Erstellen Sie eine Kopie der Website mit derselben Version von PHP, WordPress und Plugins wie auf der Live-Seite. Enthält die Kopie Kundendaten des Shops, anonymisieren Sie diese vor dem Kopieren.
2. Installieren Sie Gutenberg in der Version des Releases: wp plugin install gutenberg --version=24.2.0 --activate.
3. Setzen Sie in der wp-config.php der Kopie define( 'SCRIPT_DEBUG', true );. WordPress lädt dann die unkomprimierten Fassungen der Skripte, darunter die Entwicklerfassung von React, die vollständige Warnungen statt verkürzter Fehlercodes zeigt.
4. Geben Sie im Editor in der Konsole React.version ein und vergewissern Sie sich, dass es 19 ist. Sehen Sie 18, steht ein aktives Plugin auf der Ausnahmeliste, und der Test muss ohne dieses Plugin wiederholt werden.
5. Fügen Sie jeden eigenen Block in einen neuen Beitrag ein, ändern Sie jede Einstellung im Blockfeld, speichern Sie, laden Sie den Editor neu und prüfen Sie, ob der Block eine Meldung über ungültigen Inhalt zeigt.
6. Öffnen Sie jede Einstellungsseite des Plugins und jede Seitenleiste, die das Plugin dem Editor hinzufügt. Seit 24.2 stehen diese Seitenleisten im Untermenü für Seitenleisten im Optionsmenü.
7. Sehen Sie sich zum Schluss die gespeicherten Beiträge auf der Website an. Dynamische Blöcke rendert PHP, dort spielt React keine Rolle, aber Blöcke mit Interactivity API und Skripten auf der Seite müssen Sie durchklicken.

Die Liste für Punkt 5 sollte die Blöcke umfassen, die der Kunde tatsächlich verwendet, nicht nur die registrierten. Hat die Website eine Bibliothek mit Dutzenden Blöcken, beginnen Sie mit denen auf der Startseite, der Produktseite und in Formularen. Allgemeine Regeln für die Arbeit auf einer Testkopie beschreibt unsere Anleitung zum Einspielen von Änderungen über eine Kopie der Website, und für eine schnelle Prüfung eines einzelnen Blocks auf einer frischen Installation genügt WordPress Playground.

Melden Sie jedes gefundene Problem mit der Gutenberg-Version, der React-Version aus der Konsole und dem Wortlaut des Fehlers. Das Team bittet um Meldungen im Gutenberg-Repository auf GitHub, bei externen Plugins bei deren Autoren.

#Wie funktionieren Notizen am Rand des Editors?

Bisher konnten schwebende Notizen und das Einstellungsfeld nicht gleichzeitig offen sein, und die Notizspalte nahm dem Inhalt Platz weg. In 24.2 reserviert der Editor einen Rand neben dem Bearbeitungsbereich und zeigt dort die Notizen an, sodass sie beim Wechsel zwischen Blöcken und Beitragseinstellungen sichtbar bleiben.

Bei einem schmaleren Fenster klappt jeder Gesprächsfaden auf den Avatar des Autors zusammen, und ein Klick auf den Avatar klappt ihn wieder auf. Im neuen Untermenü für Notizen im Optionsmenü lassen sie sich ausklappen, minimieren oder ausblenden, und der Editor merkt sich die Wahl. Drei Änderungen verringern das Risiko, Arbeit zu verlieren: Das Löschen einer Notiz lässt sich rückgängig machen, eine nicht abgeschickte Notiz oder Antwort verschwindet nicht, wenn ein anderer Block markiert wird, und Notizen scrollen mit dem Inhalt mit.

Für eine Redaktion, die Texte im Editor bespricht, heißt das weniger Wechsel zwischen Feldern. Für Blockautoren gibt es eine praktische Folge: Der Bearbeitungsbereich hat weniger Platz, wenn Notizen sichtbar sind. Blöcke mit fester Breite oder eigenem Layout im Editor sollten Sie bei geöffneten Notizen ansehen.

Der Plan für WordPress 7.2 kündigt weitere Änderungen an den Notizen an: einen Vorschlagsmodus, in dem eine vorgeschlagene Textänderung angenommen oder abgelehnt werden kann, Emoji-Reaktionen und einen eigenen Knopf zum Hinzufügen einer Notiz in der Werkzeugleiste des Blocks.

#Was hat sich im Navigationsblock und in der Galerie geändert?

Wer dem Menü etwas anderes als eine Seite hinzufügen wollte, musste bisher wissen, welchen Block er braucht, etwa einen Link zu einer Kategorie oder einen Link zu einem Schlagwort, und erst darin suchen. Jetzt durchsucht die Linksuche im Navigationsblock alle Inhaltsarten gleichzeitig und zeigt bei jedem Ergebnis dessen Typ. Einen vorhandenen Link können Sie von einer Kategorie auf eine Seite umstellen, ohne ihn zu löschen und neu anzulegen. Dieselbe Suche zeigt auch Blöcke, die das Menü aufnimmt, sodass die Eingabe von Home den Block für den Link zur Startseite findet.

Die Ergebnisse werden jetzt nach Typ sortiert: Beiträge und Seiten vor Kategorien, Schlagwörtern und Medien. Diese Reihenfolge gilt für jede Linksuche im Editor, nicht nur im Menü. Auf großen Websites drängen Schlagwörter und Anhänge den gesuchten Beitrag nicht mehr aus der Ergebnisliste. Für Autoren von Plugins, die eigene Inhaltstypen in die Linksuche einbringen, ist das ein Grund zu prüfen, wo ihre Ergebnisse landen.

Die globalen Stile können jetzt die Zustände von Navigationslinks gestalten (Hover, Fokus, sichtbarer Fokus, aktiv), vorerst nur bei der Typografie. Themes, die das mit eigenem CSS gelöst haben, können einen Teil der Regeln in die theme.json verlagern, sollten aber vorher prüfen, welche Angabe Vorrang hat.

Im Galerieblock funktioniert die Sortieroption jetzt auch bei Galerien aus von Hand ausgewählten Bildern. Die Sortierung nach neuesten, ältesten und alphabetisch in beide Richtungen ordnet die Bilder einmal, danach lassen sie sich weiter verschieben. Die Zufallsoption steht an derselben Stelle und mischt die Bilder bei jedem Laden der Seite. Für Websites mit Ganzseiten-Cache ist das wichtig: Die zufällige Reihenfolge ändert sich erst, wenn der Cache erneuert wird, nicht bei jedem Besuch.

Die Galerie unterstützt jetzt auch Duotone. Ein Filter färbt alle Bilder der Galerie, eingestellt im Block oder für alle Galerien der Website in den globalen Stilen. Ein Duotone an einem einzelnen Bild hat Vorrang vor der Einstellung der Galerie. Duotone gibt es jetzt auch in den Blöcken Medien und Text sowie Video. Prüfen Sie bei Produktfotos, ob ein global eingestellter Filter keine Farben dort verändert, wo der Kunde das nicht will.

#Was ist neu in der Interactivity API?

Die neue Direktive data-wp-html zeigt HTML aus dem Zustand an, so wie data-wp-text Text anzeigt. Sie nimmt nur Werte an, die mit asDangerousHTML() als vertrauenswürdig markiert sind. Das Beispiel aus dem Release-Beitrag:

import { asDangerousHTML, store } from '@wordpress/interactivity';

store( 'myPlugin', {
	state: {
		get description() {
			return asDangerousHTML(
				'<p>A <strong>formatted</strong> description.</p>'
			);
		},
	},
} );

<div data-wp-interactive="myPlugin">
	<article data-wp-html="state.description">
		<p>Loading description.</p>
	</article>
</div>

Der Plan für 7.2 erklärt, dass die erste Fassung nur Werte anzeigt, die der Anwendungscode ausdrücklich als vertrauenswürdig markiert hat, und dass die Unterstützung bereinigter normaler Zeichenketten später kommt. Geben Sie an asDangerousHTML() nichts weiter, was von Benutzern oder aus Blockattributen stammt, ohne es auf der PHP-Seite zu bereinigen. Im selben Release hat die Gutenberg-Dokumentation einen Hinweis bekommen, dass Blockattribute und Werte aus den globalen Stilen beim Rendern als nicht vertrauenswürdig zu behandeln sind. Wenn Sie eine Sicherheitsprüfung eines Plugins durchführen, nehmen Sie die Suche nach asDangerousHTML in die Liste der Dinge auf, die ein Mensch liest.

Der Router stellt jetzt state.navigating und state.initiator bereit, sodass ein Block weiß, dass eine Navigation auf der Clientseite läuft und welcher Block sie gestartet hat. Laut Plan für 7.2 ersetzt das das veraltete Paar state.navigation.hasStarted und state.navigation.hasFinished. Blöcke mit eigener Ladeanzeige bei der Navigation sollten Sie auf die neuen Felder umstellen, bevor die alten entfernt werden.

#Sind die Notizen in Gutenberg schon Zusammenarbeit in Echtzeit?

Nein. Notizen sind Kommentare an Blöcken, die man jederzeit lesen und hinzufügen kann. Zusammenarbeit in Echtzeit steht nicht im Plan für WordPress 7.2. Der Plan sagt, dass wie bei 7.1 mehr Zeit für Architekturentscheidungen nötig ist, deshalb wurde das Thema ausgelassen, statt es aufzunehmen und später zurückzuziehen.

Die Arbeit läuft im experimentellen Plugin gutenberg-sync-engines, beschrieben im Leitfaden zu Synchronisationsmechanismen vom 14. Oktober. Getestet werden drei Mechanismen: yjs-server, DE-RTC und intent-log. Das Plugin verlangt WordPress 7.0 oder neuer und das Plugin Presence API und enthält dazu eine eigene, leicht veränderte Kopie von Gutenberg. Es läuft also nicht neben einem aktiven Plugin Gutenberg, und den Test von React 19 und den Test der Live-Zusammenarbeit kann man nicht auf derselben Kopie der Website machen.

Unter dem Leitfaden hat der Autor der Bibliothek Yjs, Kevin Jahns, auf die Serverkosten hingewiesen:

„Echtzeitbearbeitung erzeugt eine Menge kleiner Nachrichten. Wenn jede davon einen PHP-Prozess starten, das gemeinsame Dokument laden, es prüfen, zusammenführen und wieder in die Datenbank schreiben muss, ist das ein großer Aufwand für Kommunikation, Verarbeitung und Datenbank.“

Quelle: Kommentar von Kevin Jahns unter dem Leitfaden zu Synchronisationsmechanismen, 15. Oktober 2026, eigene Übersetzung

Für Betreiber von Websites auf günstigem Shared Hosting ist das ein Hinweis, dass Live-Zusammenarbeit eines Tages ein anderes Hosting verlangen kann.

Aktualisierung, 3. November 2026. Das Feature-Plugin Presence API steht seit 1. November auf 0.20.0 (WordPress.org-Eintrag; etwa 10 aktive Installationen). Die Meeting-Zusammenfassung vom 26. Oktober, veröffentlicht am 1. November, sagt, dass die Merge-Checkliste weiterhin externe Nutzertests und ein Security-Audit von außerhalb des Repos braucht und dass der 3. Dezember der früheste Termin für einen ersten Trac-Vorschlag ist (acht Wochen ohne breaking API-Änderung ab 0.17.0). Die Versionen 0.18.4 bis 0.20.0 bringen einen Logout-Fix für Beitragssperren, keepalive/roomChanged-Hooks für Push-Relays und wp_presence_admin_state(), damit ein Relay dieselben Zeilen schreiben kann wie Heartbeat. Presence bleibt Abhängigkeit von gutenberg-sync-engines, kein Ersatz für Notizen in 24.2/24.3, und liefert weiterhin kein Echtzeit-Co-Editing in WordPress 7.2.

#Wer sollte Blöcke vor WordPress 7.2 testen?

Der Test lohnt sich für jede Website mit eigenen Blöcken, Editor-Erweiterungen oder Einstellungsseiten in React sowie für Autoren von Plugins und Themes, die solche Elemente haben. Eine Website, die nur aus WordPress-Blöcken und verbreiteten, aktiv gepflegten Plugins besteht, hängt davon ab, ob deren Autoren den Test machen. Das Gutenberg-Team bittet genau jetzt darum.

Wenn in Ihrem Team niemand die gebauten Dateien durchsehen und die Blöcke auf einer Kopie der Website durchklicken kann, erledigt das ein WordPress-Entwickler als einzelnen Auftrag, und bei einer laufenden Betreuung der Website gehört der Test neuer Gutenberg-Versionen vor dem Update der Live-Seite zur Arbeit. Warum eine solche Prüfung einen Menschen braucht, beschreiben wir auch im Beitrag über die Einstellung von Entwicklern, die mit KI arbeiten.

Nennen Sie in der Anfrage die Version von WordPress und PHP, die Liste der Plugins mit eigenen Blöcken, ob auf der Live-Seite das Plugin Gutenberg läuft und ob Sie eine Testkopie der Website haben. Der Preis ist individuell und richtet sich nach dem Umfang. Das Formular finden Sie auf der Seite Kontakt.