WordPress 7.2 Roadmap: Sudo-Modus, Secrets API, Gutenberg-Notizen und das Release-Team

#Wer leitet das Release von WordPress 7.2

Matt Mullenweg ist laut der Release-Seite zu 7.2 Release Lead des WordPress 7.2 Release-Teams. Dieselbe Seite nennt die übrigen Mitglieder:

Der Release-Zyklus fällt mit einem kurzen Führungsstreit bei Automattic zusammen, dem Unternehmen, das Mullenweg leitet. Am 10. September 2026 teilte Automattic mit, er sei beurlaubt und CFO Mark Davies führe das Unternehmen als Interims-CEO. Am 12. September sagte ein Unternehmenssprecher gegenüber CMSWire, Mullenweg sei Chairman und CEO mit voller Unterstützung des Vorstands. Automattic bezifferte seine Abwesenheit später auf 33 Stunden und 20 Minuten, ohne die Beurlaubung zu erklären. Seine Rolle im Open-Source-Projekt WordPress änderte sich in diesen Tagen nicht: WordPress Executive Director Mary Hubbard erklärte, dass er das Projekt weiterhin leite (WebHosting.Today).

Das Release-Team trifft und kommuniziert die Entscheidungen zum Release und sammelt Rückmeldungen aus der Community. Die wöchentlichen Developer Chats finden mittwochs um 15:00 UTC im Kanal #core des Making WordPress Slack statt.

#Gutenberg-Notizen in WordPress 7.2

Die Notizen sind bereits im Core. WordPress 7.1 brachte Inline-Notizen zu markiertem Text, formatierten Text im Notizinhalt, Autovervollständigung für @-Erwähnungen und E-Mail-Benachrichtigungen für erwähnte Benutzer, wie das Issue zur Weiterentwicklung der Notizen in 7.2 festhält. Die Roadmap nennt drei Erweiterungen für 7.2.

Mit den Notizen in 7.2 sollen Redaktionsteams:

• Im Vorschlagsmodus eine Änderung vorschlagen, die der Autor annimmt oder ablehnt.
• Mit Emoji-Reaktionen auf Notizen schnell Feedback geben.
• Eine Notiz direkt aus der Block-Werkzeugleiste anlegen, weil die Option heute schwer zu finden ist.

Laut dem Stand dieses Issues vom 30. September steckt der Vorschlagsmodus hinter einem Experiment in neun Pull Requests, die noch nicht vollständig geprüft waren. Die Emoji-Reaktionen wurden aus 7.1 übernommen und auf einen neuen Emoji-Picker umgestellt, der Pull Request für die Abkürzung in der Werkzeugleiste war freigegeben. Ein eigenes Tracking-Issue für 7.3 sammelt alles, was nicht mehr hineinpasst. Lesen Sie daher die Dev Notes zu Beta 1, bevor Sie einem Redaktionsteam den Vorschlagsmodus zusagen.

#Echtzeit-Zusammenarbeit in WordPress 7.2

Gemeinsames Bearbeiten in Echtzeit ist nicht Teil von 7.2. Die Roadmap klammert es aus, solange Architekturentscheidungen offen sind. Die Echtzeit-Zusammenarbeit wurde aus WordPress 7.0 entfernt, und am 18. September 2026 schlug Chris Zarate einen serverseitigen Ansatz vor. Heute führen die Browser Änderungen direkt zusammen und senden das Ergebnis beim Speichern. Nach dem Vorschlag läuft jede Änderung über WordPress: Der Server hält fest, wer sie gemacht hat, prüft die Berechtigung, führt sie zusammen und speichert das Ergebnis. Danach schickt er den anderen Teilnehmern die Änderungen, die ihnen fehlen, oder meldet einen Konflikt zur Prüfung. Die Browser würden keine Änderungen mehr direkt untereinander austauschen.

Laut dem Beitrag steht die Untersuchung am Anfang und ist nicht reif für den Core. Drei mögliche Sync-Engines (Yjs-server, Distributed Editing und Intent log) liegen als experimentelles Plugin im Repository gutenberg-sync-engines. Offen sind die Kosten beim Hosting: Das Zusammenführen auf dem Server erzeugt Last, häufiges Polling ist auf schwach ausgestatteten Tarifen teurer, und ein WebSocket-Transport bräuchte einen Daemon außerhalb des PHP-Worker-Pools, den der Hoster betreibt.

#Was ist der Sudo-Modus in WordPress 7.2

Da sich das Web an automatisierte Scans und hochentwickelte Session-Hijacking-Skripte anpasst, reicht die herkömmliche Administrator-Authentifizierung nicht mehr aus. Wenn ein bösartiges Skript oder ein Angreifer die Cookies oder Session-Token eines aktiven Administrators abfängt, erhält er uneingeschränkten Zugriff auf die gesamte Website.

Die Roadmap nennt für 7.2 einen Sudo-Modus: eine erneute Authentifizierung vor hoch privilegierten Aktionen. Der Name stammt vom Unix-Befehl sudo. Ein gestohlenes Session-Cookie würde dann allein nicht mehr genügen, um eine privilegierte Aktion auszuführen, weil die Aktion die Zugangsdaten erneut abfragt.

Welche Aktionen geschützt werden, ist noch nicht öffentlich. Laut Roadmap folgen ein Vorschlag und ein Aufruf zur Mitarbeit, und bei unserer Prüfung am 12. Oktober 2026 war auf make.wordpress.org/core noch kein Vorschlag zum Sudo-Modus erschienen. Bis dahin ist eine Bestandsaufnahme die sinnvolle Vorbereitung: Listen Sie die eigenen Admin-Seiten und REST-Endpunkte Ihrer Plugins auf, die Benutzer, Rollen und Berechtigungen, Dateien oder Sicherheitseinstellungen ändern. Genau vor diese Abläufe würde sich ein Schritt zur erneuten Authentifizierung setzen.

#Secrets API in WordPress 7.2 für API-Schlüssel

Die Speicherung sensibler Anmeldedaten (wie Stripe-API-Schlüssel, Mailchimp-Token oder benutzerdefinierte Datenbank-Logins) war in WordPress historisch gesehen eine architektonische Schwachstelle. Über zwei Jahrzehnte lang hatten Entwickler keine andere Wahl, als Schlüssel fest in wp-config.php zu codieren oder sie unverschlüsselt in der Tabelle wp_options zu speichern.

Der Vorschlag für eine Secrets API von Eric Mann vom 25. August 2026 zielt auf 7.2 und sieht einen eigenen Speicher für Anmeldedaten im Core vor. Die Problembeschreibung ist konkret: Klartext-Schlüssel in der Optionstabelle landen in Datenbank-Dumps, Backups, Staging-Kopien und CLI-Ausgaben, und Plugins, die ihre Schlüssel selbst verschlüsseln, tun das jeweils auf eigene Weise. KI-Integrationen machen einen geleakten Schlüssel noch teurer.

Der vorgeschlagene Entwurf:

• Verschlüsselung ist immer aktiv. Jedes Secret erhält einen eigenen Datenschlüssel, der von einem Master-Schlüssel umhüllt wird, den wiederum der Site-Schlüssel umhüllt (Envelope-Verschlüsselung). Es gibt keinen Klartextmodus und keine Konstante, mit der sich die Verschlüsselung abschalten lässt. Die Kryptografie nutzt libsodium, mit sodium_compat als Fallback.
• Standardspeicher ist die Optionstabelle. Sie enthält nur Chiffretext mit autoload=no und ist von options.php und dem REST-Endpunkt für Einstellungen ausgenommen. Bevorzugte Schlüsselquelle ist eine eigene Konstante; Websites ohne sie greifen auf einen Schlüssel zurück, der aus den vorhandenen Salts abgeleitet wird.
• Externe Speicher werden über ein Drop-in angebunden. Ein secrets.php-Drop-in bietet zwei getrennte Erweiterungspunkte: Storage (zum Beispiel HashiCorp Vault oder AWS Parameter Store) und Keyring (ein KMS oder HSM).
• Im Fehlerfall wird gesperrt. Ist das Backend nicht erreichbar, schlägt der Aufruf fehl, ohne lokalen Fallback. Werte lassen sich nur schreiben: Einen Export gibt es nicht.

#Funktionen der Secrets API in WordPress 7.2

wp_set_secret( string $name, string $value ): bool|WP_Error
wp_get_secret( string $name, string $version = WP_Secret_Version::CURRENT ): WP_Secret|null|WP_Error
wp_delete_secret( string $name ): bool|WP_Error
wp_import_option_as_secret( string $option, string $name ): bool|WP_Error

wp_get_secret() gibt ein WP_Secret-Objekt zurück, keinen String. Den Wert liefert reveal(), und fingerprint() erzeugt eine Kennung, die gefahrlos geloggt werden kann. Das Objekt maskiert sich in Logs, in var_dump() und in Fehlerausgaben und verweigert die Serialisierung. Die Funktion gibt null zurück, wenn das Secret nicht existiert, und einen WP_Error, wenn es existiert, aber nicht entschlüsselt werden kann. Namen erhalten per Konvention einen Namensraum nach dem Muster plugin-slug/secret-name.

Zwei Berechtigungen schützen den Speicher: manage_secrets und manage_network_secrets. In Multisite-Installationen leitet ein Netzwerk-Root-Schlüssel Unterschlüssel pro Website ab, und Website- und Netzwerk-Secrets nutzen getrennte Funktionen ohne impliziten Fallback zwischen beiden. Die Rotation steuert der Betreiber über zwei Versionsplätze, CURRENT und PREVIOUS, und bei jedem Schreibvorgang feuert ein Hook mit dem Akteur, dem Zeitstempel sowie dem alten und dem neuen Fingerprint.

Auf dem Lesepfad gibt es absichtlich keinen Filter: Über einen Filter könnte jedes Plugin Anmeldedaten abfangen, deshalb binden sich Hoster stattdessen über Provider an. Der Vorschlag benennt auch seine Grenzen. Jeder Code, der innerhalb von WordPress läuft, kann wp_get_secret() aufrufen, und der Plugin-Slug im Namen eines Secrets wird nicht authentifiziert. Die API trennt die Secrets eines Plugins also nicht von denen eines anderen. Was sie beseitigt, sind Klartext-Schlüssel in Dumps, Backups und Staging-Kopien.

Für Agenturen und Entwickler, die moderne WordPress-Integrationslösungen entwickeln (einschließlich KI-Agenten-Integrationen, bei denen API-Schlüssel intensiv genutzt werden), bietet die Secrets API ein standardisiertes Framework, das die WordPress-Sicherheit näher an Enterprise-Standards heranführt.

#Plugin-API-Schlüssel zur Secrets API migrieren

Der Vorschlag bringt in 7.2 keine Admin-Oberfläche mit: Eine Einstellungsseite ist auf 7.3 verschoben. Unterstützung in WP-CLI gehört zum Umfang von 7.2, damit Anmeldedaten nicht mehr in der Shell-History und in Prozesslisten auftauchen. Die Befehlsnamen stehen aber noch nicht fest (das ist eine der offenen Fragen im Beitrag). Geplant ist zuerst ein Feature-Plugin und danach ein Core-Patch mit derselben API.

Im Plugin-Code ist die Migration ein bewusster Schritt pro Option über wp_import_option_as_secret(), kein automatischer Durchlauf. Importierte Secrets werden zur Rotation markiert, weil der alte Klartextwert bereits in jedem bisherigen Backup steckt. Ein versionssicheres Auslesen für ein Plugin, das unter 7.1 und 7.2 laufen muss, sieht so aus:

$name = 'my-plugin/stripe-key';

if ( function_exists( 'wp_get_secret' ) ) {
	$secret = wp_get_secret( $name );
	if ( null === $secret && get_option( 'my_plugin_stripe_key' ) ) {
		wp_import_option_as_secret( 'my_plugin_stripe_key', $name );
		$secret = wp_get_secret( $name );
	}
	$key = $secret instanceof WP_Secret ? $secret->reveal() : '';
} else {
	$key = (string) get_option( 'my_plugin_stripe_key', '' );
}

Die Signaturen stammen aus dem Vorschlag und können sich bis Beta 1 ändern. Behalten Sie daher die Prüfung mit function_exists() und den alten Pfad für Websites unter 7.1. Der Vorschlag sagt nicht, ob der Import die ursprüngliche Option entfernt, lesen Sie also die Dev Note, bevor Sie etwas löschen. Sobald der Schlüssel in der Secrets API liegt, rotieren Sie ihn beim Zahlungs- oder API-Anbieter.

#Warum Hoster den Vorschlag zur Secrets API kritisieren

Die Kommentare unter dem Vorschlag zeigen, wo der Entwurf noch umstritten ist. Chris Reynolds von Pantheon schrieb, dass Pantheon einen externen Secrets-Speicher betreibt, auf den Anwendungen nur lesend zugreifen. Er fragte, ob reine Lese-Provider vorgesehen sind und wie Plugins mit dem WP_Error umgehen sollen, den ein Schreibversuch zurückgäbe, und wies darauf hin, dass Plattform-Speicher, die Klartext benötigen, mit dem Drop-in-Modell kollidieren. Ryan McCue von Altis lehnte den Vorschlag in seiner jetzigen Form ab und argumentierte, WordPress solle Secrets nur lesen und die Verschlüsselung externen HSMs überlassen.

Eric Mann antwortete, dass ein reiner Lese-Provider den Setter zu einer wirkungslosen Operation machen kann und Hoster einen stärkeren Provider einsetzen können, mit einem Beispiel für AWS Secrets Manager in seinem Repository secrets-api. Ein Pull Request an wordpress-develop (#13759) geht auf die Einwände zu Hoster-Providern ein. Im Beitrag bleiben fünf Fragen offen, darunter ob zwei Versionsplätze genügen und welche WP-CLI-Befehle zuerst kommen.

Für Plugin-Autoren folgt daraus, dass wp_set_secret() auf einem Managed Host planmäßig fehlschlagen kann. Ein Einstellungsformular, das einen Schlüssel speichert, muss den zurückgegebenen Fehler anzeigen, statt von Erfolg auszugehen.

#Änderungen an Anwendungspasswörtern in WordPress 7.2

Der Sicherheitsteil der Roadmap nennt außerdem eine Härtung der Anwendungspasswörter: Verbesserungen der Bedienung, eine E-Mail-Benachrichtigung beim Hinzufügen eines neuen Anwendungspassworts, Korrekturen bei der Umgebungserkennung, einen sichereren Umgang mit default_role und Unterstützung für SameSite-Cookies. Die Arbeit läuft in den Trac-Tickets #66009, #63927, #57388, #46744 und #37000. Eine gehärtete HTML-Verarbeitung auf Basis der HTML API vervollständigt die Sicherheitsliste.

Anwendungspasswörter sind die Zugangsdaten, die die meisten REST-API-Integrationen nutzen. Die Benachrichtigung zeigt dem Website-Betreiber also an, wenn jemand ohne sein Wissen eines anlegt.

#Weitere Funktionen auf der WordPress 7.2 Roadmap

Ipsum, das neue Standard-Theme, ist ein minimalistisches Blog-Theme, das als leere Leinwand angelegt ist, mit gepunkteten Unterstreichungen, einigen Schrift-Sets und Stilvarianten, die die ganze Seite einschließlich der Bilder umfärben. Jede Kombination aus Farbe und Stil erfüllt den Kontrast nach WCAG AA, wie Henrique Iamarino in seinem Vorstellungsbeitrag schreibt. Mit Ipsum enden auch die Jahreszahlen in den Namen der Standard-Themes. Der Code liegt zum Testen auf GitHub, und das Team bezeichnet den Zeitplan als knapp.

Die Arbeit an KI geht im AI-Plugin weiter, ohne Garantie, dass sie im Core landet: weitere Abilities (experimenteller Lesezugriff auf Medien, Taxonomien und Kommentare), ein MCP Adapter, der auf die aktuelle MCP-Spezifikation gebracht und über das Plugin-Verzeichnis verteilt wird, Agenten-Identitäten mit nachvollziehbaren Berechtigungen und Streaming-Antworten im PHP AI Client.

Bei Blöcken und APIs nennt die Roadmap einen Beschreibungslisten-Block für <dl>, <dt> und <dd>, eine Stichwortsuche im Icon-Block, eine Direktive data-wp-html und einen Router in der Interactivity API sowie serverseitiges Rendering für den Inhaltsverzeichnis-Block, damit er stabil werden kann. Das Upgrade auf React 19 ist in Gutenberg weitgehend angekommen, wird in 7.2 aber wahrscheinlich nicht vollständig ausgeliefert.

Im Admin-Bereich erhalten DataViews und DataForms serverseitig registrierte Ansichten, Felder und Aktionen, und der Beitrags-Inspektor wird durch ein DataForm ersetzt. Fehlermeldungen werden leichter zu diagnostizieren und bekommen eine Schaltfläche zum Kopieren, und eine neu aufgebaute Grundlage des Website-Editors erlaubt Plugins, eigene Ansichten zu registrieren. Bei der Performance wird das Zusammenfügen von Skripten und Styles durch Prefetching ersetzt (Trac #57548), ergänzt durch Arbeit aus dem Plugin Enhanced Responsive Images.

#Zeitplan für WordPress 7.2

David Baumwald hat den Zeitplan für WordPress 7.2 am 6. Oktober 2026 auf make.wordpress.org veröffentlicht. Jeder Meilenstein beginnt um 15:00 UTC.

Mit Beta 1 wechseln die Core-Mitwirkenden zu Tests und Fehlerbehebung, und die ersten Dev Notes erscheinen. RC1 bringt den Field Guide, einen harten String Freeze und den Release-Branch. Nach dem Feature Freeze werden nur noch Fehlerbehebungen committet, Regressionen zuerst.

Installieren Sie Beta 1 am 20. Oktober auf einer Staging-Kopie und wiederholen Sie die Tests von Plugins und Theme mit RC1 am 17. November, damit Konflikte vor dem 8. Dezember auf Staging auffallen.

#WordPress 7.2 Beta testen

Es gibt zwei dokumentierte Wege. Das Plugin WordPress Beta Tester unter Werkzeuge, Beta Testing (bei Multisite unter Einstellungen) stellt den eingebauten Updater vom Standardkanal Point release auf Bleeding edge (Trunk) oder auf Beta- und RC-Pakete um. Auf der Kommandozeile akzeptiert wp core update die Option --version=nightly oder den Pfad zu einer heruntergeladenen ZIP-Datei. Erstellen Sie vorher ein Backup und halten Sie Betas von der Produktion fern.

Was getestet werden sollte, ergibt sich aus der Roadmap: Plugins, die API-Schlüssel in Optionen speichern, eigene Admin-Abläufe, die Benutzer oder Dateien ändern, redaktionelle Workflows, die auf den Notizen aufbauen, und Child-Themes, falls Sie eine Website auf Ipsum umstellen wollen.

#Website auf WordPress 7.2 vorbereiten

WordPress 7.2 ist eines der strukturell bedeutendsten Updates des Jahres 2026. Die Kombination aus kollaborativen Editor-Workflows und gehärteten Backend-Sicherheitsprimitiven bedeutet, dass Agenturen und Entwickler jetzt mit der Vorbereitung beginnen müssen.

Bei WPPoland bereiten wir bereits unsere headless Astro-Setups und serverlosen MCP-Integrationen darauf vor, die neue Secrets API zu nutzen und uns an die Sudo-Modus-Authentifizierung anzupassen.

Möchten Sie Ihre Enterprise-WordPress-Installation sichern oder Ihre benutzerdefinierten Plugins auf die neuen Core-Standards von 2026 migrieren? Kontaktieren Sie noch heute unser Core-Entwicklungsteam für einen maßgeschneiderten Migrationsplan.