WordPress plant 2026 wieder drei Major-Releases – und die frühen Leitplanken für 7.0 zeichnen sich ab

WordPress soll 2026 wieder zu einem Rhythmus mit drei Major-Releases zurückkehren. Das ist das zentrale Ergebnis des jüngsten „Core Committers Check-in“ (Quartalsformat), bei dem Core-Committer gemeinsam mit der Projektleitung über Release-Kadenz, Timing, mögliche Features für WordPress 7.0, den Status des Admin-Redesigns und die Rolle von AI in der zukünftigen Entwicklung gesprochen haben.

Wichtig für die Einordnung: Anfang des Jahres war noch kommuniziert worden, dass 2026 nur ein Major-Release erscheinen solle. Begründet wurde das mit „ongoing legal matters“ – im Kontext der Berichterstattung ist damit der Rechtsstreit rund um WP Engine gemeint – sowie mit dem Umstand, dass Automattic die WordPress-Beiträge reduziert/pausiert hat (ebenfalls im Zusammenhang mit dieser Auseinandersetzung). Dass nun wieder drei Releases „beabsichtigt“ sind, ist damit eine klare Kurskorrektur.

Das Treffen fand unter der Chatham House Rule statt. Praktisch heißt das: Inhalte dürfen im Sinne der Sache weitergegeben werden, aber ohne Personen konkret zuzuordnen.

Zurück zu drei Major-Versionen: Was aktuell für 2026 geplant ist

Die Release-Intention stammt aus den veröffentlichten Meeting-Notizen von Core-Committer Jonathan Desrosiers im Make WordPress Core Blog. Dort wird als Ziel formuliert, 2026 wieder eine Dreier-Kadenz zu fahren – und WordPress 7.0 wird dabei grob auf März oder April anvisiert.

Ein Release im Februar wurde explizit verworfen. Der Grund ist vor allem organisatorisch und realistisch: Dafür würde Beta 1 in Anfang Januar fallen – eine Phase, in der viele Contributor noch im Urlaub sind. Zusätzlich seien mehrere Features, die parallel laufen, in diesem engen Zeitfenster nicht rechtzeitig „release-ready“.

Major-Releases rund um Flagship-Events? Idee ja – Plan noch nicht

Diskutiert wurde außerdem, ob man künftige Major-Releases stärker an große Community- und Projekttermine koppeln sollte – als Referenz wurde der WordPress-6.9-Launch rund um die State of the Word genannt.

Gleichzeitig wurde auch klar benannt, warum das nicht trivial ist: Wenn man Releases an Events „festzurrt“, kommen zusätzliche Abhängigkeiten rein – Reisen, Zeitzonen, die Verfügbarkeit der Release Squad und die generelle Contributor-Verfügbarkeit. Das erhöht die Komplexität deutlich. Ergebnis der Runde: Das Ganze bleibt eine Möglichkeit, aber noch kein belastbarer Plan und wurde als Thema für weitere Diskussionen markiert.

Was könnte in WordPress 7.0 landen? Kandidaten aus dem 6.9-Umfeld

In den Notizen tauchen mehrere Features auf, die ursprünglich im Scope für WordPress 6.9 waren und nun als Kandidaten für 7.0 diskutiert wurden. Genannt werden:

• Template Activation (Aktivierung/Handling von Templates als Feature-Thema)
• der Tabs Block (ein Block-Konzept für Tab-UI)
• Client-side abilities für die Abilities API (also Fähigkeiten/Capabilities, die nicht nur serverseitig verfügbar sind)
• Client-side media editing (Medienbearbeitung im Browser/Client)

Der inhaltlich größte Block der Diskussion drehte sich aber um ein anderes Thema: den WordPress AI Client.

WordPress AI Client: Warum das Thema plötzlich core-relevant wirkt

Der WordPress AI Client ist eines der vier „Building Blocks“ aus der Roadmap des WordPress AI Teams und steht nun grundsätzlich zur Debatte, ob er in WordPress Core einziehen sollte.

Laut den Notizen wurde Version 0.1.0 des WordPress AI Client „letzte Woche“ veröffentlicht. Die Idee dahinter: Plugins und Themes bekommen einen nativen, provider-agnostischen Zugang zu AI-Services. „Provider-agnostisch“ bedeutet hier: Der Client soll nicht auf einen bestimmten Anbieter festgenagelt sein, sondern eine abstrahierte Schnittstelle liefern.

Technisch ordnet sich das als Anpassung des PHP AI Client an WordPress-Konventionen ein. Konkret werden dabei mehrere Prinzipien genannt, die WordPress-Entwickler sofort wiedererkennen:

• Er nutzt die WordPress HTTP API für Requests.
• API-Keys werden zentral an einer Stelle verwaltet – über einen Screen namens „AI Credentials“.
• Die Modell-Auswahl soll über den Client laufen, ohne dass Plugins einzelne Anbieter hart verdrahten müssen (kein „Provider hard-coding“ in jedem Plugin/Theme).

Außerdem ist bereits skizziert, was in späteren Versionen dazukommen soll:

• Support für die Abilities API
• zusätzliche REST endpoints
• ein client-seitiger Prompt Builder (UI/Tooling für Prompts im Browser/Client)

Genau diese Rolle als „Fundament“ war laut Meeting-Notizen ein Kernargument pro Core: Der AI Client könnte das Ökosystem dazu bringen, auf stabilen, gemeinsamen Grundlagen aufzubauen (explizit genannt wird hier auch die Abilities API). In den Notes wird das sinngemäß so begründet: Wenn die relevanten APIs kombiniert werden, entstehen viele neue Möglichkeiten – sowohl für Entwickler als auch für Site Owner.

Die Kehrseite: Core muss agnostisch bleiben – und konkrete Use Cases brauchen

Gleichzeitig wurden die Grenzen sehr deutlich gemacht. WordPress soll laut Notizen immer agnostisch bleiben. Eine Core-Integration, die faktisch ein bestimmtes AI-Modell bevorzugt oder nur mit ausgewählten Drittanbietern gut funktioniert, wäre langfristig nicht tragfähig.

Als mögliche Perspektive wurde außerdem erwähnt, dass sich längerfristig auch neue Optionen ergeben könnten – etwa durch machine-based oder browser-level models (also Modelle, die stärker lokal bzw. im Browser-Umfeld laufen). Eine konkrete Richtung oder Festlegung wurde dafür aber nicht beschlossen.

Bevor überhaupt eine Entscheidung fällt, wollen die Beteiligten außerdem klare Use Cases für „default WordPress“ sehen. Als Beispiele für solche Standard-Use-Cases wurden genannt:

• die Mediathek nach bestimmten Motiven/Inhalten durchsuchen (z.B. Bilder nach „subject matter“ finden)
• Newsletter generieren auf Basis kürzlich veröffentlichter Inhalte

Admin-Redesign: eher „frischer Anstrich“ als kompletter Umbau

Auch das Admin-Redesign war Thema. Der Tenor laut Notizen: Es geht nicht um eine komplette Neuentwicklung oder radikale Umgestaltung, sondern eher um einen „fresh coat of paint“ – also einen neuen Anstrich und das Auffrischen dessen, was bereits da ist.

Das ist eine wichtige Klarstellung, weil es im Sommer bei einem früheren Quartalsmeeting auch um die Frage ging, wie man so ein Redesign testbar macht: als Experiment im Gutenberg-Plugin oder als separates Plugin in der Art von „MP7“. „MP7“ ist dabei bewusst als Anspielung auf MP6 gesetzt – das war 2013 ein „feature as a plugin“-Ansatz, der später maßgeblich das Admin-Redesign von WordPress 3.8 geprägt hat.

In der Roadmap ist das Admin-Redesign demnach Teil von Phase 3: Collaboration im Gutenberg-Kontext. An der Vision wird seit 2023 gearbeitet: Gutenberg Lead Architect Matías Ventura hatte damals seine Vorstellung einer modernisierten Admin-Experience geteilt und später auch neue Layouts im Rahmen der State of the Word 2023 demonstriert.

Ein konkreter Zwischenstand ist ebenfalls relevant: Eine frühe Preview des Admin-Redesigns, die ursprünglich zusammen mit WordPress 6.9 kommen sollte, wurde im September zurückgestellt. In der aktualisierten Roadmap wurde das mit „no longer planned based on the current state of work“ begründet.

Eine belastbare Timeline, wann das Redesign in Core landen könnte, gibt es weiterhin nicht. Der Kontext dazu: Der letzte wirklich große Admin-Refresh liegt mehr als zehn Jahre zurück (WordPress 3.8).

PHP-Minimum: Warum 7.4 diskutiert wird (und warum das nicht nur Symbolik ist)

Ein weiterer Punkt der Runde: Es gebe „compelling reasons“, das minimale unterstützte PHP auf PHP 7.4 anzuheben. Es wurde aber keine Entscheidung getroffen.

Die Argumentation drehte sich um sehr praktische Grenzen, die viele von uns aus Plugin- und Theme-Entwicklung kennen:

• Sehr alte PHP-Versionen zwingen WordPress zu zusätzlicher Abwärtskompatibilität, was Bloat erzeugt und Entwicklung verlangsamt.
• PHP 7.4 würde die Codebase in Richtung konsistenteres Typing bewegen. Das erleichtert Verständnis – sowohl für Entwickler als auch für AI-Systeme, die Code analysieren/unterstützen sollen.
• Viele Third-Party AI SDKs setzen ohnehin bereits neuere PHP-Versionen voraus. Ein zu niedriges Minimum blockiert, solche SDKs überhaupt sinnvoll einzusetzen.

Gleichzeitig wurde das Thema als Abwägung formuliert: Fortschritt ermöglichen, aber Nutzer nicht „zurücklassen“. Genau diese Balance ist in WordPress traditionell ein Kernpunkt – und entsprechend wurde auch hier kein Schnellschuss beschlossen.

Was als Nächstes ansteht: Follow-ups aus dem Check-in

In den Meeting-Notizen wurden mehrere konkrete Follow-up-Punkte festgehalten, die nach dem Termin weiterverfolgt werden sollen:

• mehr offene und semi-offene Meeting-Formate vorschlagen
• den Release-Plan für 2026 veröffentlichen
• Ziel-Features für 7.0 und ggf. auch 7.1 bestätigen bzw. schärfen
• bewerten, ob eine Koordination von Releases mit In-Person-Events praktisch umsetzbar ist

Einordnung für Entwicklerteams: Was du aus den Signalen jetzt mitnehmen kannst

Auch wenn viele Details (noch) Absichtserklärungen sind, lassen sich ein paar sehr konkrete Signale herauslesen: 2026 soll wieder mehr Release-Tempo bringen, WordPress 7.0 wird früh adressiert, und AI wird nicht als einzelnes Feature, sondern als Infrastruktur-Thema diskutiert (AI Client + Abilities API + REST + Prompt Builder). Parallel bleibt das Admin-Redesign bewusst evolutionär, und beim PHP-Minimum steht ein Schritt an, der mittel- bis langfristig enorme Auswirkungen auf Codequalität, Tooling und Abhängigkeiten haben kann.