WordPress 7.0 Release am 20. Mai 2026 – Features, Anforderungen, Vorbereitung

Release-Termin und der Weg dorthin

Der 20. Mai 2026 ist der finale Stichtag für WordPress 7.0. Ursprünglich war das Update für den 9. April geplant, parallel zum Contributor Day der WordCamp Asia. Das Core-Team hat den Release dann verschoben, um die Datenbank-Architektur hinter der Echtzeit-Kollaboration grundlegend zu überarbeiten. Eine späte Beta-Phase nach dem Release-Candidate-Stadium gilt in der Geschichte des Projekts als außergewöhnlich – die Verantwortlichen haben Stabilität klar über das Datum gestellt.

Für Dich heißt das in der Praxis, dass Du eine Version bekommst, die das Core-Team länger geprüft hat. Bei einem Major-Release mit so vielen architektonischen Änderungen ist das die richtige Reihenfolge.

Echtzeit-Kollaboration – wenn zwei Redakteure denselben Beitrag bearbeiten

Die größte Neuerung in WordPress 7.0 betrifft den Editor selbst. Zwei oder mehr angemeldete Nutzer können denselben Beitrag oder dieselbe Seite gleichzeitig bearbeiten und sehen die Cursor der anderen, ihre Markierungen und ihre Änderungen live. WordPress nutzt dafür standardmäßig HTTP-Polling als Sync-Mechanismus, öffnet aber einen Hook für Hoster und Plugins, um WebSocket-Verbindungen einzubinden.

Im Alltag wird der Unterschied schnell sichtbar. Eine Redakteurin formuliert einen Absatz um, während der Lektor weiter unten Korrekturen einträgt. Beide Seiten sehen die Änderungen sofort, alle bleiben im selben Beitrag, und der Stand der Arbeit ist immer aktuell. Die Notes-Funktion aus 6.9 wird mitgezogen – Anmerkungen syncen jetzt ebenfalls in Echtzeit, neue Tastenkürzel beschleunigen das Setzen von Inline-Kommentaren.

Eine Einschränkung gibt es zum Start. Maximal zwei gleichzeitige Editoren pro Beitrag sind erlaubt. Größere Redaktionsteams müssen sich also abstimmen, wer wann am Dokument arbeitet. Der Mechanismus deaktiviert sich automatisch, sobald ein Plugin klassische Meta-Boxen einbindet – ein wichtiger Punkt für Seiten, die mit älteren E-Commerce- oder Custom-Field-Plugins laufen.

Web Client AI API – die KI-Schnittstelle wird Teil des Core

WordPress 7.0 bringt eine eigene KI-Infrastruktur ins Core. Unter Settings → Connectors hinterlegst Du Zugangsdaten zu KI-Anbietern wie OpenAI, Anthropic oder eigenen Modellen. Plugins und Themes greifen dann über die standardisierte WP-AI-Client-Schnittstelle auf den von Dir gewählten Anbieter zu, statt jedes Plugin eine eigene Integration mitzuschleppen.

Praktisch übersetzt heißt das, dass Du heute drei verschiedene Plugins mit KI-Funktionen nutzt und dafür drei API-Schlüssel und drei Konfigurationen pflegen musst. Mit 7.0 hinterlegst Du Deine Credentials einmal zentral, alle kompatiblen Plugins ziehen sich daraus, was sie brauchen.

Sicherheitsseitig gibt es einen Punkt zu beachten. API-Keys, die über die Connectors-UI gespeichert werden, erscheinen im Klartext in der Optionen-Tabelle der Datenbank. Die Maskierung gilt nur für die Settings-Oberfläche und die REST-API. Für maximale Sicherheit hinterlegst Du Schlüssel als Umgebungsvariable oder PHP-Konstante – das System prüft beide Quellen vor der Datenbank.

Die Abilities API, die in 6.9 als Vorbereitung kam, wird in 7.0 deutlich erweitert. KI-Agenten sprechen Funktionen im WordPress-Backend strukturiert an, erstellen Inhalte, bearbeiten Beiträge und fragen Daten ab. Die Verschlüsselung der gespeicherten Schlüssel ist im Trac-Ticket #64789 geplant, aber noch nicht Teil von 7.0.

Modernisiertes Backend und neue Blöcke

Das wp-admin bekommt eine sichtbare Auffrischung. Die View-Transitions-API sorgt für Slide- und Zoom-Animationen zwischen den Admin-Screens, die neue Typografie und das überarbeitete Farbschema wirken aufgeräumter. Wenn Du viele Stunden im Backend verbringst, merkst Du den Unterschied schon nach wenigen Klicks.

Zwei neue Core-Blöcke landen im Editor:

• Breadcrumbs-Block – Brotkrumen-Navigation direkt aus dem Core, mit automatischer Übernahme der globalen Theme-Stile
• Icons-Block – kuratierte SVG-Sammlung über eine neue serverseitige Icon-Registration-API mit stabiler Funktionsweise auch nach Updates

Dazu kommen Verbesserungen, die im Alltag mehr verändern als ein neuer Block:

• Block-Sichtbarkeit nach Bildschirmgröße direkt im Editor steuerbar
• Pattern-Editing mit Spotlight-Modus und isoliertem Editor für synchronisierte Patterns, Template-Parts und Navigationsmenüs
• Visuelle Revisionen mit blockbasiertem, farblich markiertem Vergleich statt HTML-Diff
• Die Font Library funktioniert ab 7.0 auch mit klassischen Themes
• Befehlspalette per Cmd+K (Mac) oder Strg+K (Windows) aus jedem Admin-Screen heraus

Bild-Resizing und Komprimierung laufen ab 7.0 im Browser des Uploaders, nicht mehr auf dem Server. Das spart Speicher und CPU auf dem Webserver – gerade bei Multi-Author-Seiten mit vielen Medien-Uploads ein echtes Plus.

Hosting-Anforderungen für WordPress 7.0

Drei technische Punkte solltest Du vor dem Update klären.

PHP-Version. WordPress 7.0 empfiehlt PHP 8.3 oder höher. Die formale Mindestanforderung liegt zwar niedriger, aber bei einer Seite auf PHP 7.x oder 8.0 riskierst Du Sicherheitslücken und Inkompatibilitäten mit aktuellen Plugins. Bei fastpress.pro liegt PHP 8.3 ohnehin im Standard, prüfen lohnt sich überall – im Plesk- oder Hosting-Dashboard sind das ein paar Klicks.

WebSocket-Unterstützung. Die Echtzeit-Kollaboration läuft im Auslieferungszustand über HTTP-Polling. Das funktioniert auf jedem Standard-Hosting, kostet aber mehr Anfragen pro Minute. Arbeitest Du ernsthaft mit mehreren Editoren parallel, profitierst Du von WebSocket-Unterstützung. Die ist nur sinnvoll, wenn Dein Hoster einen entsprechenden Reverse-Proxy oder einen kompatiblen Sync-Provider eingerichtet hat. Frag im Zweifel beim Support nach.

Performance-Reserven. Der iframed Editor, die View Transitions, der KI-Connector – jede dieser Funktionen verschiebt Last vom Server in den Browser oder ins Netzwerk. Trotzdem wird das Backend voller. Auf einem knapp dimensionierten Shared-Hosting kann die Reaktionszeit darunter leiden. NVMe-Storage, LiteSpeed und ein vernünftiger Object-Cache machen den Unterschied im Editor und auf den Frontend-Seiten gleichzeitig.

So bereitest Du Deine Seite vor

Vom heutigen Stand bis zum 20. Mai bleiben Dir gut zwei Wochen. Genug Zeit, um in Ruhe vorzubereiten – aber zu wenig, um das Update am Release-Tag spontan auf der Live-Seite einzuspielen. Eine geordnete Reihenfolge:

1. Backup erstellen. Datenbank und Files vollständig sichern. Bei jedem Major-Release das absolute Minimum.
2. Staging-Klon einrichten. Ein 1:1-Klon der Live-Seite, auf dem Du den Release-Candidate testest.
3. PHP-Version prüfen und gegebenenfalls auf 8.3 anheben.
4. Plugins und Theme auf Kompatibilität prüfen. Die wichtigsten Plugins haben in den letzten Wochen ihre Tested up to-Angaben aktualisiert. Bei Custom-Themes oder eigenen Blöcken solltest Du gegen die RC-Builds testen.
5. Auf der Staging-Seite updaten. Danach einen kompletten Workflow durchspielen – Beitrag erstellen, bearbeiten, veröffentlichen, Bestellprozess durchlaufen, Kontaktformular absenden.
6. Erst dann die Live-Seite aktualisieren – idealerweise außerhalb der Hauptzeit Deiner Besucher.

Bei BuddyBoss, WooCommerce-Subscriptions, Custom-Field-Frameworks oder älteren Page-Buildern solltest Du zusätzliche Zeit für die Plugin-Hersteller einplanen. Manche Anbieter ziehen ihre Updates erst in den Tagen nach dem Release-Termin nach.

Für Agenturen und Entwickler – die Code-Ebene

Auf Code-Ebene bringt 7.0 mehr Veränderungen mit, als die Feature-Liste vermuten lässt.

Der Post-Editor läuft ab Version 7.0 in einem iframe, sobald der Inhalt ausschließlich Blöcke mit Block-API-Version 3 oder höher enthält. Eigene Blöcke, die noch auf API v1 oder v2 sitzen, verhindern das iframing und damit eine Reihe von Stiloptimierungen. Der Migrations-Guide steht in den Dev-Notes.

PHP-only Blocks sind ein praktischer Zugewinn für Backend-lastige Teams. Du registrierst einen Block samt Metadaten komplett serverseitig in PHP, mit automatisch generierten Inspector-Controls aus den Attributen. Für kleine, kundenspezifische Blöcke – Öffnungszeiten-Anzeige, Standort-Karte, ein einfacher Mitarbeiter-Block – ist das der Weg, der bisher meist über Shortcodes ging.

Pseudo-Klassen-Selektoren (:hover, :focus, :focus-visible, :active) gehen ab 7.0 direkt in die theme.json. Damit wandert Code, den Du bisher im Custom-CSS pflegen musstest, ins strukturierte Theme-System.

Für Patterns auf Kundenseiten zählt der neue Isolated-Editor-Mode. Synchronisierte Patterns lassen sich bearbeiten, während die umliegenden Seiten-Templates beim Speichern unberührt bleiben. Damit verschwindet eine Klasse von Bugs, die in der Vergangenheit für ärgerliche Rückfragen vom Kunden gesorgt hat.

Der nächste Termin nach 7.0 ist der 19. August 2026 zur WordCamp US – WordPress kehrt damit zum Drei-Releases-pro-Jahr-Rhythmus zurück. Aus dem Feature-Backlog von 7.0 sollen unter anderem der Tabs-Block und die Core-Abilities in 7.1 nachgereicht werden, dazu eine erweiterte Connectors-API mit zusätzlichen Authentifizierungsmethoden und einer JavaScript-Registrierungs-API für eigene Connector-Oberflächen.

Wann erscheint WordPress 7.0 endgültig?

Der finale Release-Termin ist der 20. Mai 2026. Ursprünglich war der 9. April geplant, das Core-Team hat den Termin aber wegen architektonischer Arbeiten an der Echtzeit-Kollaboration verschoben. RC 3 erscheint am 8. Mai 2026 und gibt Plugin-Entwicklern und Hostern ein letztes Test-Fenster.

Welche PHP-Version brauche ich für WordPress 7.0?

Empfohlen ist PHP 8.3 oder höher. Die offizielle Mindestversion liegt darunter, aber bei produktiven Seiten lohnt es sich kaum noch, mit PHP 7.x oder 8.0 zu arbeiten – Sicherheitsupdates sind dort längst ausgelaufen. Dein Hosting-Panel zeigt Dir die aktive Version unter PHP-Einstellungen oder PHP-Selector.

Wie unterscheidet sich Echtzeit-Kollaboration in WordPress 7.0 von Google Docs?

Beide erlauben das gleichzeitige Bearbeiten eines Dokuments mit Live-Cursor und Sofort-Sync. WordPress speichert die Änderungen direkt in Deiner Datenbank, eingebunden in das bestehende Rollen- und Rechte-System – die Arbeit bleibt durchgehend im selben Tool. Beim Start sind allerdings nur zwei gleichzeitige Editoren pro Beitrag erlaubt.

Soll ich am 20. Mai sofort updaten oder warten?

Am Release-Tag selbst gehört das Update auf eine Staging-Instanz, nicht auf die Live-Seite. Lass die ersten 7 bis 14 Tage vergehen, in denen Plugin- und Theme-Hersteller eventuelle Inkompatibilitäten korrigieren. Bei einer kleinen Bloggerseite kannst Du nach drei oder vier Tagen aktualisieren, bei einem aktiven WooCommerce-Shop mit vielen Plugins eher zwei Wochen warten.

Wie aufwendig ist die Vorbereitung auf WordPress 7.0?

Bei einer Standard-Seite mit gepflegten Plugins, einem aktuellen Theme und PHP 8.3 reichen ein bis zwei Stunden für Backup, Staging-Test und das eigentliche Update. Bei einer Seite mit eigenem Theme, älteren Plugins oder Custom-Code solltest Du einen halben Arbeitstag einplanen, im Zweifel auch mehr. Die Investition lohnt sich – ein Update gegen die Wand zu fahren kostet im Schadensfall ein Vielfaches.