Die Version befindet sich noch in Entwicklung
Am 15. Oktober nennt der offizielle Zeitplan den 20. Oktober um 15:00 UTC für WordPress 7.2 Beta 1 und den 8. Dezember als geplanten Termin der finalen Version. Das sind aktuelle Projektziele, keine Garantie, dass Termin oder Umfang unverändert bleiben. Das Team plant 7.2 als letzte große WordPress-Version 2026 und sieht ein neues Standard-Theme vor.
Für Website-Teams ist jetzt die Vorbereitung einer Testumgebung sinnvoll, nicht ein Produktionsupdate. Vor Beta 1 wird noch entwickelt; Beta- und Release-Candidate-Versionen dienen dem Testen, nicht dem normalen Betrieb öffentlicher Websites. Folgen Sie der Release-Seite und den Entwicklerhinweisen, bevor Sie über das stabile Update entscheiden.
Eine Änderung am SQL-Modus ist bereits dokumentiert
Ein Entwicklerhinweis beschreibt eine konkrete Änderung: WordPress 7.2 behandelt den MySQL-Modus `NO_BACKSLASH_ESCAPES` als nicht unterstützt und entfernt ihn beim Verbindungsaufbau aus den Sitzungsmodi. WordPress verwendet Backslashes zum Escaping bestimmter Zeichen in SQL-Abfragen; mit diesem Modus interpretiert die Datenbank sie anders. Die Änderung betrifft die WordPress-Sitzung, nicht die globale Serverkonfiguration.
Das Core-Team sagt, dass die meisten Websites keinen Unterschied bemerken sollten, warnt jedoch vor Problemen, wenn der Modus aktiv bleibt. Wer ihn bewusst benötigt, sollte die Konfiguration prüfen lassen. Der dokumentierte Filter muss früh geladen werden, denn WordPress verbindet sich mit der Datenbank, bevor reguläre Plugins starten. Das ist kein Anlass, die Datenbankeinstellungen aller Server zu ändern.
Gutenberg-Releases sind keine Core-Zusage
Gutenberg wird in einem eigenen Rhythmus veröffentlicht; seine Neuerungen müssen nicht automatisch in einer bestimmten WordPress-Core-Version enthalten sein. Die 7.2-Roadmap nennt ein neues Standard-Theme und sagt, dass ausreichend fertige Funktionen berücksichtigt werden. Sie ist aber keine endgültige Liste aller Editoränderungen. Für Theme- und Pluginentwickler sind Beta-Hinweise und der spätere Field Guide maßgeblicher.
Agenturen sollten nicht fragen, was Gutenberg heute enthält, sondern welchen Code die 7.2-Beta und die finale Version tatsächlich enthalten. Vergleichen Sie die Version mit Theme, Plugins, Editor-Erweiterungen, eigenen Blöcken, PHP-Version und Hosting der jeweiligen Kunden. Testen Sie die echte Website, statt sich ausschließlich auf ein Kompatibilitätskennzeichen zu verlassen.
Eine sichere Vorbereitung in Schritten
Erstellen Sie ein Staging mit aktuellen Backups und einem getesteten Wiederherstellungsweg. Dokumentieren Sie WordPress-, PHP-, Datenbank- und Pluginversionen sowie eigenen Code, der SQL oder den Editor beeinflusst. Sobald Beta 1 vorliegt, testen Sie eine repräsentative Website: Bearbeiten und Veröffentlichen, Vorlagen, geplante Aufgaben, Formulare, Zahlungen oder Mitgliedschaften und Protokolle.
Lassen Sie Produktionsseiten auf einer unterstützten stabilen Version, bis WordPress 7.2 final veröffentlicht ist und Ihre Tests bestanden sind. Melden Sie während der Beta reproduzierbare Fehler mit Umgebungsangaben. Aktualisieren Sie nach dem Release zuerst Staging, prüfen Sie Backup und Rollback und planen Sie dann die Produktion passend zu Risiko und Wartungsfenster. Versprechen Sie keine Kompatibilität ohne Prüfung.
Quellen und weiterführende Informationen
Einen sachlichen Fehler melden oder eine Quelle vorschlagen? Redaktion kontaktieren.
