WordPress mikt in 2026 weer op drie major releases: wat we nu al weten over 7.0, AI en PHP 7.4

Tijdens de meest recente Core Committers Check-in (november 2025) hebben core committers samen met projectleiding vooruitgekeken naar 2026. De kernboodschap: WordPress wil terug naar drie major releases in één jaar, en de eerste contouren van WordPress 7.0 worden al zichtbaar. Naast releasecadans ging het ook over het admin redesign, de mogelijke plek van AI in core, en een (opnieuw) gevoelig onderwerp: het verhogen van de minimaal ondersteunde PHP-versie.

Belangrijk detail: de sessie vond plaats onder de Chatham House Rule (een afspraak waarbij inhoud gedeeld mag worden, maar niet wie wat zei). Daardoor zijn de meeting notes leidend voor wat er nu concreet bekend is.

Terug naar drie major versions in 2026 (en 7.0 mikpunt: maart/april)

Volgens de gepubliceerde meeting notes is de intentie om in 2026 weer een cadans van drie major releases te hanteren. Daarbij wordt WordPress 7.0 voorlopig gemikt op maart of april.

Een release in februari is expliciet van tafel gehaald. De reden is vooral praktisch: dan zou beta 1 al begin januari moeten vallen, precies in een periode waarin veel contributors nog met vakantie of minder beschikbaar zijn. Daarnaast zouden meerdere features die nu nog in ontwikkeling zijn simpelweg niet op tijd “release-ready” zijn.

Waarom dit een koerswijziging is t.o.v. eerdere signalen

Eerder in 2025 was juist aangekondigd dat er in 2026 slechts één major release zou komen. Executive Director Mary Hubbard verwees daarbij naar “ongoing legal matters”, met als context onder meer de WP Engine lawsuit en de bredere impact op capaciteit en bijdragen, inclusief Automattic’s pauze in WordPress contributions.

De check-in van november 2025 maakt duidelijk dat de planning inmiddels weer opschuift richting “business as usual” qua releasefrequentie – al blijft de formulering nadrukkelijk een intentie, geen hard schema.

Major releases koppelen aan flagship events: nog geen plan, wel een optie

Een interessant idee dat op tafel lag: major releases (vaker) laten samenvallen met grote, zichtbare momenten zoals flagship events. Daarbij werd verwezen naar de manier waarop WordPress 6.9 dit jaar rond State of the Word gelanceerd werd (zie ook: State of the Word 2025 set for San Francisco coinciding with WordPress 6.9 release).

Tegelijk werd er een flinke kanttekening bij gezet: releases plannen rondom reizen, tijdzones én de beschikbaarheid van de release squad en contributors voegt complexiteit toe. De conclusie is dus geen roadmap-beslissing, maar: mogelijk, en gemarkeerd voor verdere discussie.

Wat kan er in WordPress 7.0 komen? Kandidaten uit 6.9 en een flinke AI-discussie

In de meeting kwam ook een rij features langs die eerder (deels) voor WordPress 6.9 waren ingeschat, en nu als kandidaat voor 7.0 worden genoemd. Het ging onder andere om:

• Template activation
• De Tabs block
• Client-side mogelijkheden voor de Abilities API (Abilities API = een API-laag die capabilities/“abilities” op een consistenter niveau definieert en beschikbaar maakt)
• Client-side media editing (als besproken onderwerp)

Maar de meest uitgebreide discussie draaide om één onderwerp: de WordPress AI Client.

WordPress AI Client: provider-agnostic AI als fundament (en mogelijk naar core)

De WordPress AI Client is één van de vier “Building Blocks” uit de roadmap van het WordPress AI Team (zie: WordPress AI team publishes first roadmap focused on developer tools and infrastructure) en wordt nu serieus bekeken als kandidaat voor opname in core.

Vorige week is versie 0.1.0 van de WordPress AI Client uitgebracht (aangekondigd via: Introducing the WordPress AI Client SDK). Het idee is dat plugins en thema’s op een native manier met AI-services kunnen praten, zonder dat iedere plugin zijn eigen integratie- of key-management bouwt.

Concreet: de client is provider-agnostic (dus niet vastgepind op één AI-provider) en past de PHP AI Client aan naar WordPress-conventies. Onder de motorkap leunt het op bestaande WordPress-componenten zoals de WordPress HTTP API (de standaard manier om HTTP-requests te doen binnen WordPress).

De meeting notes noemen een paar concrete bouwstenen die al aanwezig zijn of expliciet op de planning staan:

• Gebruik van de WordPress HTTP API voor requests naar AI-providers
• Centralisatie van API keys in een apart “AI Credentials”-scherm
• Model selection zonder dat plugins providers hard-coden
• Toekomstige releases met: Abilities API support, REST endpoints en een client-side Prompt Builder

Because the AI client is a great way to encourage the ecosystem to build around solid foundations (such as the Abilities API), the ideal home for this is Core itself. The combining of these related APIs will unlock so many possibilities for developers and site owners.

Meeting notes (Make WordPress Core)

De redenering daarachter is helder: als je wilt dat het ecosysteem bouwt op gedeelde fundamenten (zoals de Abilities API), dan is “in core” vaak de plek waar zo’n basislaag het meeste effect heeft.

De randvoorwaarden: WordPress wil agnostic blijven (en geen ‘AI vendor lock-in’)

Tegelijk werd er stevig stilgestaan bij de beperkingen van AI in core. De meeting notes benadrukken dat WordPress altijd agnostic wil blijven. Een core-integratie die bijvoorbeeld één specifiek model kiest, of slechts een paar externe diensten integreert, wordt als niet duurzaam gezien.

Er werd ook kort vooruitgekeken naar langere-termijn mogelijkheden, zoals opkomende machine-based of browser-level models. Maar: er is geen richting gekozen, geen beslissing genomen, en er is duidelijk behoefte aan heldere criteria.

Eerst use cases voor ‘default WordPress’ scherp krijgen

Voordat er überhaupt een keuze gemaakt kan worden over core-opname, willen contributors duidelijke use cases zien in “default WordPress”. Voorbeelden die in de bespreking genoemd werden:

• De mediabibliotheek doorzoeken op specifieke onderwerpen/inhoud (subject matter)
• Nieuwsbrieven genereren op basis van recente content

Admin redesign: geen complete ombouw, maar een ‘fresh coat of paint’

Ook het admin redesign kwam langs. De belangrijkste nuancering: dit traject mikt niet op een totale herbouw van wp-admin, maar op een opfrisbeurt: een “new coat of paint” en het moderniseren van wat er al is.

Die verduidelijking is relevant, omdat in eerdere gesprekken (o.a. rond de kwartaalmeeting in juli) nog werd gesproken over het testen van het redesign als experiment via de Gutenberg plugin of zelfs als losse “MP7” plugin. Dat is een knipoog naar MP6, de bekende “feature as a plugin”-aanpak die uiteindelijk leidde tot het admin redesign in WordPress 3.8 (2013).

Het admin redesign valt onder Phase 3: Collaboration in de Gutenberg-roadmap. Het traject loopt al even: het werk startte in 2023, toen Gutenberg Lead Architect Matías Ventura zijn visie deelde op het moderniseren van de admin experience (zie: Admin design). Later werden tijdens State of the Word 2023 nieuwe layouts gedemonstreerd.

Een vroege preview van het redesign stond ooit gepland om samen met WordPress 6.9 te verschijnen, maar is in september geschrapt toen de roadmap werd aangepast naar: “no longer planned based on the current state of work.”

Er is nog altijd geen tijdlijn voor wanneer het vernieuwde admin daadwerkelijk in core zou landen. De laatste grote opfrissing is inmiddels meer dan tien jaar oud: WordPress 3.8.

Minimum PHP verhogen naar 7.4: ‘compelling reasons’, maar nog geen besluit

Een klassieker in WordPress-land: de minimaal ondersteunde PHP-versie. In de check-in zijn volgens de meeting notes “compelling reasons” besproken om de minimum PHP-versie te verhogen naar PHP 7.4.

De discussie ging vooral over praktische grenzen:

• Oudere PHP-versies dwingen WordPress om compatibiliteit te behouden die bloat veroorzaakt en ontwikkeling vertraagt.
• Met PHP 7.4 kan de codebase richting consistenter typing bewegen, wat het voor developers (en ook voor AI-systemen) makkelijker maakt om code te begrijpen.
• Veel third-party AI SDK’s vereisen nu al nieuwere PHP-versies; een te lage minimumversie blokkeert hergebruik van zulke libraries.

Tegelijk werd het als een balans neergezet: vooruitgang boeken zonder users “achter te laten”. Tijdens deze meeting is geen beslissing genomen.

Wat volgt er na deze check-in?

Jonathan Desrosiers noemde in de meeting notes een aantal concrete follow-ups die uit de sessie kwamen:

• Een voorstel uitwerken voor meer open en semi-open meeting formats
• Het publiceren van het 2026 release schedule
• Het bevestigen van target-features voor 7.0 en mogelijk ook 7.1
• Beoordelen of het praktisch is om releases te coördineren met in-person events

Samenvatting voor developers

• De intentie is om in 2026 terug te gaan naar drie major WordPress-releases.
• WordPress 7.0 wordt voorlopig gemikt op maart of april; februari is afgevallen vanwege timing en readiness van features.
• De WordPress AI Client (v0.1.0) is een serieuze kandidaat voor core, juist omdat het een provider-agnostic basis biedt en aansluit op o.a. de Abilities API.
• Het admin redesign wordt neergezet als een evolutie: een opfrisbeurt, geen complete rebuild, en er is nog geen tijdlijn.
• Het verhogen van de minimum PHP-versie naar 7.4 is besproken met duidelijke technische argumenten, maar zonder besluit.