9 april is geweest en WordPress 7.0 is er niet. Op 31 maart plaatste release lead Matias Ventura de post "Extending the 7.0 Cycle" op het core-team blog, waarin hij bevestigde dat de release "a few weeks" zou uitlopen om "key architectural details" af te ronden. Een exacte nieuwe datum is er nog niet. Een nieuw schema wordt uiterlijk 22 april aangekondigd.
Had je je stagingtest al ingepland, je team gebrieft, of klanten al aan het voorbereiden op 9 april? Dan is dit wat er aan de hand is en hoe ik mijn plan nu zou bijstellen. Voor de volledige feature-set van 7.0 blijft mijn eerdere WordPress 7.0-preview gewoon overeind. Alleen het tijdpad is verschoven.
TL;DR:
- WordPress 7.0 is uitgesteld van 9 april naar eind mei 2026. De exacte datum volgt uiterlijk 22 april
- De oorzaak: real-time collaboration sloeg zijn synchronisatiedata op in
postmeta, waardoor de persistent post-cache bij elke actieve bewerking werd leeggegooid. Er wordt nu een aparte database-tabelwp_collaborationontworpen - Pre-releases zijn gepauzeerd tot 17 april. De huidige stabiele productieversie is WordPress 6.9.4
- Dit is goed nieuws. Een uitgestelde WordPress-release is vrijwel altijd een betere release. 5.9 en 6.5 liepen om vergelijkbare redenen uit en werden er sterker van
- Wat je kunt doen: blijf op 6.9.4, check je PHP-versie, verplaats je stagingtest en laat je Beta Tester-nightlies gewoon doorlopen
Wat er is misgegaan
Het uitstel is geen mysterie. Ventura en Matt Mullenweg hebben er openlijk over geschreven.
Real-time collaboration, de belangrijkste nieuwe feature van 7.0, heeft ergens plek nodig om zijn synchronisatiedata op te slaan: cursors, aanwezigheid, en kleine tussentijdse wijzigingen. De oorspronkelijke implementatie gebruikte daarvoor postmeta en transients. Elke keer dat twee mensen samen typten, werd er meerdere keren per seconde naar postmeta geschreven.
WordPress triggert bij elke wijziging in postmeta zijn cache-invalidatiehooks. Dat betekent dat elke post met actieve medebewerkers zijn persistent object cache elke seconde opnieuw kwijtraakte. Een pagina waar iemand aan werkt, zou zijn Redis- of Memcached-cache dus volledig verliezen. Voor een CMS dat zo leunt op persistent caching is dat een showstopper.
De voorgestelde oplossing in Trac #64696 is een aparte wp_collaboration-tabel, met velden voor room, client ID, gebruiker, een data-payload en een tijdstempel voor opschonen. Mullenweg zei er in de ticketdiscussie het volgende over:
"I'm generally against new tables, but this is a useful primitive for all our future real-time collab and sync work."
Hij wilde tijd om het ontwerp goed te doen. Dat is eigenlijk het hele verhaal: een nieuwe tabel die zorgvuldig wordt ontworpen in plaats van er snel doorheen geduwd. Ventura's post eindigt op dezelfde manier. Het team pauzeerde pre-releases, sloot trunk voor alles wat geen 7.0-stabiliteitsfix is, en komt uiterlijk 22 april met een nieuw schema.
Het nieuwe schema (of het ontbreken ervan)
Op het moment van schrijven zijn dit de enige harde data:
- Pre-releases gepauzeerd tot en met 17 april 2026
- Nieuw schema aangekondigd uiterlijk 22 april 2026
- Doeldatum voor de release: eind mei 2026
De follow-up van Jonathan Desrosiers, "The Path Forward for WordPress 7.0", noemt nog een technische kanttekening: RC3 en RC4 houden hun "release candidate"-label, terwijl ze in de praktijk meer beta-builds zijn. Dat is een workaround voor PHP's version_compare(), geen verborgen alarm. Als je de komende weken dus RC3 voorbij ziet komen in de downloadmap, betekent dat niet dat de finale release om de hoek ligt.
Waarom een uitgestelde release goed nieuws is
Ik snap het wel: uitstel is irritant als je er je weekplanning op had afgestemd. Maar het patroon is inmiddels duidelijk. Uitstel bij WordPress is bijna altijd de juiste keuze.
WordPress 5.9 liep ruim een maand uit, van december 2021 naar 25 januari 2022, omdat Full Site Editing gewoon nog niet klaar was. Een core contributor schreef destijds dat het team "dingen op een gevaarlijke manier doorduwde" en dat het "beter is om de beoogde datum te missen dan beslissingen te haasten waar je spijt van krijgt." FSE was anders in een gebroken staat gelanceerd.
WordPress 6.5 liep in 2024 één week uit omdat de Font Library op het punt stond bestanden naar /wp-content/fonts te schrijven, wat op veel servers stilletjes werd geblokkeerd. Release lead Aaron Jorbin verdedigde de keuze met: "This isn't a rash decision, it's about making the best decision for the users of WordPress with the information that is available at this point in time." Het pad werd aangepast naar /wp-content/uploads/fonts en de feature werkte.
Het 7.0-uitstel past in dat patroon. Een concrete, aanwijsbare regressie (dode object caches op elke pagina waar iemand aan werkt) is op tijd gevangen. Ik lees liever dit artikel nu dan dat ik in juni het artikel "WordPress 7.0 sloopt je Redis-cache" moet schrijven.
Wat je doet met je stagingtest
Had je je stagingtest al voor begin april gepland? Verplaats hem naar de eerste week van juni. Reserveer er een ochtend voor in je agenda en laat hem staan. De update komt wanneer hij komt.
Een paar praktische dingen om tussen nu en dan te doen:
- Blijf op WordPress 6.9.4. De 6.9.x-lijn had in maart een rommelige patchcyclus. 6.9.2 bracht tien securityfixes, 6.9.3 repareerde een template-loading-regressie die door 6.9.2 was geïntroduceerd, en 6.9.4 maakte drie CVE-patches af die in de vorige twee releases niet volledig waren doorgevoerd. Als je nog op 6.9.3 of lager zit: update nu.
- Check je PHP-versie. WordPress 7.0 dropt PHP 7.2 en 7.3. Sites op die versies kunnen niet updaten. Gereedschappen > Website gezondheid > Info > Server laat je huidige versie zien. Ik schreef eerder over waarom PHP 8.1 end of life belangrijk is, ook als WordPress core die versie nog ondersteunt.
- Laat nightlies doorlopen op staging. Heb je de WordPress Beta Tester-plugin op een stagingkopie staan? Laat hem op het Bleeding Edge / Nightlies-kanaal. Trunk is nu bevroren voor uitsluitend 7.0-stabiliteitsfixes, waardoor nightly builds op dit moment ongebruikelijk bruikbaar zijn voor regressietests. Mijn bredere kijk op staging bij WordPress-updates blijft overeind.
- Test specifiek je classic meta box-plugins opnieuw. Real-time collaboration schakelt zichzelf uit op posts die classic meta boxes gebruiken. Dat is een bewuste keuze, geen bug, maar ook geen ding waar de meeste pluginauteurs op letten. Als een klant leunt op een ACF-zwaar editscherm, krijgt dat scherm geen RTC. Beter om dat nu te ontdekken dan op de dag van de release.
- Haast je niet om 7.0 op dag 1 te installeren. Dit is altijd mijn advies geweest bij grote WordPress-releases en het uitstel verandert daar niks aan. Wacht een week of twee op de eerste point release. 7.0.1 verschijnt doorgaans 10 tot 14 dagen na een major en fixt wat iedereen over het hoofd had gezien.
Belangrijkste punten
- WordPress 7.0 is uitgesteld van 9 april naar eind mei 2026. De exacte datum volgt uiterlijk 22 april
- De oorzaak is een opslagontwerp voor real-time collaboration dat de persistent post-cache sloopte. Er komt een nieuwe database-tabel om het op te lossen
- De huidige stabiele productieversie is WordPress 6.9.4. Zorg dat je daarop zit
- Een uitgestelde WordPress-release is vrijwel altijd een betere release. 5.9 en 6.5 volgden hetzelfde patroon en werden er sterker van
- Verplaats je stagingtest naar begin juni, laat nightlies doorlopen op staging en check ondertussen je PHP-versie