WordPress 7.0: was bekannt ist, was Spekulation ist, was jetzt zu tun ist

Vorab eine Anmerkung: Zum Zeitpunkt des Schreibens (April 2026) ist WordPress 7.0 zwar auf der öffentlichen Roadmap, aber noch nicht ausgeliefert. Konkrete Funktionslisten, Schemaänderungen und Migrationszeitpläne, die online kursieren, einschliesslich in Beiträgen, die sich als "vollständiger Leitfaden" präsentieren, sind teils Prognose, teils Wunschliste. Behandeln Sie alles, was definitiv über 7.0 klingt, als Spekulation, bis es in einem auf dem offiziellen Make WordPress Blog veröffentlichten Release Candidate landet und im core trac getaggt wird.

Was wir aus öffentlichen Make WordPress Posts wissen: Die Phase 3 Arbeit am kollaborativen Bearbeiten ist im Gange, eine tiefere Integration zwischen dem Block-Editor und AI-Anbietern wird in Core-Meetings diskutiert, und das Site Editor Templating-Modell wird verfeinert. Was wir noch nicht wissen: Welche AI-Funktionen (falls überhaupt) werden im Core landen versus als Plugins bleiben, das endgültige PHP-Minimum oder das genaue Auslieferungsdatum.

Wenn Sie Arbeit planen, die sich mit dem 7.0-Zyklus überschneidet, ist der ehrliche Schritt, make.wordpress.org/core und core trac Tickets direkt zu verfolgen, anstatt auf Drittanbieter-Vorhersagen zu vertrauen. Die deutsche WordPress-Community, einschliesslich der WordCamp DE Organisatoren und der DACH-Beitragenden, verfolgt dieselben Kanäle auf Make WordPress. Dieser Beitrag ist eine dieser Drittanbieter-Vorhersagen; lesen Sie ihn entsprechend.

Erfahren Sie mehr über professionelle WordPress-Entwicklung bei WPPoland.

#Was tatsächlich über 7.0 bekannt ist

Wenn man die Marketing-Verpackung herausnimmt, ist das Bild schmaler als die meisten “vollständiger Leitfaden”-Posts vermuten lassen.

Bestätigt in öffentlicher Make WordPress Diskussion:

• Phase 3 der Gutenberg-Roadmap ist das Arbeitsthema, mit Zusammenarbeit und redaktionellem Workflow als den beiden Bereichen, die die meisten öffentlichen Vorschläge und PRs gesehen haben.
• AI-Integration wird im Gutenberg-Plugin prototypisch entwickelt und in Core-Meetings diskutiert, aber die Grenze zwischen “wird im Core ausgeliefert” und “bleibt ein Plugin” ist nicht entschieden.
• Site Editor und Pattern-System werden weiter iteriert, mit Verfeinerungen der Template-Bearbeitung und der Block-Sperre, die zuerst in 6.x Punktversionen landen.

Nicht bestaetigt, trotz häufiger Behauptungen:

• Ein konkretes Auslieferungsdatum für 7.0. Release-Zeitplaene rutschen; behandeln Sie jedes einzelne Datum als Ziel, nicht als Verpflichtung.
• Eine endgültige AI-Funktionsliste im Core. Es gibt mehrere Vorschläge, einschliesslich anbieterunabhängiger Abilities und einer Connectors-UI, aber Vorschläge sind keine Releases.
• Die Anhebung der PHP-Mindestversion und die genauen Deprecations. Diese werden spät im Zyklus entschieden.

Für Agenturen und Produktteams, die in 2026 ausliefern, ist die praktische Erkenntnis einfacher als jede Funktionsliste: Bauen Sie auf WordPress 6.x mit zukunftskompatiblen Mustern (Block Themes, theme.json, REST API, Action Scheduler für Hintergrundarbeit), damit, was auch immer 7.0 letztlich liefert, die Migration inkrementell statt eine Neuentwicklung wird.

#AI in WordPress heute, und wohin 7.0 gehen koennte

Die ehrliche Version von “AI-Funktionen in WordPress 7.0” beginnt mit dem, was bereits in 6.x funktioniert, denn das ist es, was echte Sites laufen.

Heute verfuegbar, in produktivem WordPress:

• Yoast und Rank Math (mit deutschen Sprachversionen) liefern beide AI-unterstützte Schreibhelfer (Titel, Meta-Beschreibungen, interne Linkvorschlaege), die auf Modell-APIs von Drittanbietern basieren.
• Jetpack AI Assistant bietet In-Editor-Generierung, Zusammenfassung und Übersetzung. Die Qualitaet variiert nach Sprache und Prompt; deutsche Qualitaet ist akzeptabel, erfordert aber redaktionelle Pruefung.
• Eigenstaendige Content-Generierungs-Plugins existieren in einer breiten Qualitaetsspanne; nuetzlich für Entwuerfe, gefaehrlich, wenn direkt an die Veröffentlichung ohne menschliche Pruefung verdrahtet.
• Automattic und Beitragsteams fuehren Phase 3 Experimente durch, einschliesslich kollaborativer Bearbeitung und editorseitiger AI-Aufrufe, im Gutenberg-Plugin vor jedem Merge in den Core.

Eine pragmatische Architektur für das Hinzufuegen von AI zu einer WordPress-Site heute, die wahrscheinlich überleben wird, was auch immer 7.0 liefert:

• Stellen Sie einen kleinen REST API Endpoint pro Anbieter bereit (OpenAI, Anthropic, Google oder ein selbst gehostetes Modell). Halten Sie anbieterspezifischen Code hinter einer Schnittstelle, sodass das Wechseln von Modellen eine Konfigurationsaenderung und keine Neuentwicklung ist.
• Lassen Sie alles, was langsamer als ein paar Sekunden ist, durch Action Scheduler laufen, nicht durch eine synchrone Anfrage. Das ist dasselbe Muster, das WooCommerce verwendet; es skaliert.
• Speichern Sie API-Keys als wp-config.php Konstanten oder über einen verwalteten Secret Store, der beim Boot geladen wird. Setzen Sie niemals Live-Keys in Plugin-Optionen oder .env Dateien, die in ein Repo committet werden.
• Cachen Sie Antworten, gehasht über Prompt plus Modellversion. AI-Aufrufe sind teuer und werden haeufig wiederholt.

Fehlerszenarien, gegen die man von Tag eins an entwerfen sollte:

• API-Key Leakage durch Plugin-Auto-Updates oder Backups, die wp-content Dumps enthalten.
• Rate-Limit-Fehler waehrend Traffic-Spitzen, die das Editor-Erlebnis stillschweigend degradieren, wenn es keinen Fallback gibt.
• Halluzinierte Fakten, Zitate oder Produktspezifikationen, die ohne menschlichen Pruefschritt veröffentlicht werden. Die Kosten einer schlechten Seite in der Suche sind höher als die Kosten eines beliebigen Pruef-Workflows.

Wenn 7.0 eine Core-Abilities- oder Connectors-Schicht einfuehrt, gelten dieselben Grenzen: Die API-Oberflaeche aendert sich, die Fehlerszenarien nicht. Für Ethik und redaktionelle Rahmen siehe den AI-Content-Ethik-Leitfaden für Herausgeber.

#Wie man sich vorbereitet, ohne die Migration zu erraten

Einen Schritt-für-Schritt “Wie migriere ich zu 7.0” Leitfaden zu schreiben, bevor 7.0 ausgeliefert wurde, ist unredlich. Die versionsspezifischen Befehle, die Datenbank-Upgrade-Routine, die neuen Admin-Einstellungen: Nichts davon ist final. Wer heute exakte Migrationsschritte veröffentlicht, fuellt Lücken mit Annahmen.

Was Sie jetzt tun koennen, ist, die zukuenftigen Migrationskosten unabhaengig davon zu reduzieren, wie 7.0 aussieht. Die Arbeit ist undankbar und zahlt sich bei jedem Release aus, nicht nur bei diesem.

Auditieren Sie die Teile des Stacks, die bei einem grossen Upgrade am wahrscheinlichsten brechen:

• Themes, die noch functions.php Template Tags anstelle von Block Themes verwenden. Konvertieren Sie zu Block Themes oder planen Sie den Aufwand.
• Benutzerdefinierte Gutenberg-Blöcke, die gegen frueher @wordpress/scripts Versionen gebaut wurden. Pinnen und gegen die neueste stabile Version testen.
• Page Builder mit eigener Rendering-Schicht. Diese sind die haeufigste Ursache von “wir koennen nicht upgraden” Schulden.
• Benutzerdefinierte REST-Endpoints ohne Versionierung. Fuegen Sie jetzt /v1/ Namespacing hinzu, damit ein zukuenftiges Bump nicht-brechend ist.

Richten Sie die langweilige Infrastruktur ein, die Ihnen erlaubt, schnell zu upgraden, wenn 7.0 ausgeliefert wird:

• Eine Staging-Umgebung, die die produktive PHP-Version, Plugin-Set und Inhaltsvolumen widerspiegelt. Datenbank-Paritaet ist wichtiger, als die Leute erwarten.
• Automatisierte Backups mit getestetem Wiederherstellungspfad. Ein ungetestetes Backup ist Theater.
• Plugin- und Theme-Updates, die in regelmaessigem Rhythmus laufen, nicht aufgeschoben bis zur naechsten grossen. Sites, die auf 6.0 feststecken, stecken fest, weil niemand 6.1 bis 6.8 aktualisiert hat.
• Eine kurze Liste von Plugin-Autoren, denen Sie vertrauen, mit E-Mail-Kontakten. Wenn 7.0 ausgeliefert wird, werden Sie innerhalb einer Woche wissen wollen, welche Ihrer Plugins dagegen getestet sind.

Wenn 7.0 tatsächlich RC im offiziellen Release-Kalender erreicht, ist der Upgrade-Pfad derselbe, der für jedes grosse WordPress-Release funktioniert hat: Erst auf Staging laufen lassen, das Error-Log beobachten, zwei bis vier Wochen nach allgemeiner Verfügbarkeit warten, bevor man die Produktion für Kundensites anfasst, und den offiziellen Field Guide Post auf Make WordPress lesen, bevor man annimmt, dass irgendein Drittanbieter-Leitfaden (dieser eingeschlossen) das widerspiegelt, was tatsächlich ausgeliefert wurde.

#Was bis zur Auslieferung von 7.0 zu tun ist

Bis WordPress 7.0 ein getaggtes Release auf wordpress.org erreicht, ist das Nuetzlichste, was jedes Team tun kann, die Vorhersage-Posts (diesen eingeschlossen) zu ignorieren und die Primaerquellen zu beobachten: den Make WordPress Core Blog, Gutenberg Release Notes und den trac Milestone für 7.0.

Für ein bestehendes Projekt, das in 2026 ausgeliefert wird, bauen Sie auf einem aktuellen 6.x Release mit Block Themes, theme.json und der REST API. Behandeln Sie AI als Integrationsschicht hinter Ihren eigenen Endpoints, nicht als eine Funktion, auf die Sie warten, dass der Core sie liefert. Wenn 7.0 landet, wird die Migration zur Frage, welche Ihrer benutzerdefinierten Integrationen durch eine Core-API ersetzt werden koennen, nicht zu einer Neuentwicklung.

Wenn Sie Hilfe beim Auditieren eines Stacks auf Upgrade-Bereitschaft wuenschen, unser WordPress-Entwicklungsteam macht diese Arbeit für produktive Sites in jedem Release-Zyklus.