WordPress 7.0 development has started, and the first real decision is one I have been waiting years for: the core team is dropping PHP 7.2 and 7.3 support. If you have spent those years keeping legacy code alive in the name of “maximum compatibility,” this one is a relief.
Technical debt is part of it, but performance and security are the bigger reasons. Every hour spent rewriting a modern PHP feature because some ancient server might trip over it is an hour gone. Keeping up with these version shifts is ordinary core development hygiene.
Why WordPress 7.0 development is dropping PHP 7.2
Both versions reached end-of-life years ago, so this was overdue rather than sudden. Raising the floor to PHP 7.4, and nudging users toward 8.2 and up, lets the core team use typed properties, arrow functions, and better error handling without worrying about breaking half the internet.
I went through the technical implications of dropping PHP 7.2 support in version 7.0 recently. Plugin authors, take this as your cue to stop testing against those versions and start using the modern engine. And if your host is still serving 7.2, it is holding your business back, not just running late.
The filter extension debate
One of the more technical items on the latest Dev Chat agenda is whether the PHP filter extension should become a default requirement. I hope it does. Leaning on filter_var() for sanitization and validation beats maintaining custom regex monsters or another heavy wrapper in core.
The sticking point is always the minimum environment. If you build custom solutions, you should already be checking for these extensions. Here is how I keep a missing one from turning into a fatal error in production:
<?php
/**
* Check if the PHP filter extension is available.
* A simple safeguard for WordPress 7.0 development prep.
*/
function bbioon_ensure_filter_extension() {
if ( ! extension_loaded( 'filter' ) ) {
// Log the error or show a notice in the admin
error_log( 'Critical: The PHP filter extension is missing.' );
return false;
}
// Now you can safely use filter_var
$email = 'user@example.com';
if ( filter_var( $email, FILTER_VALIDATE_EMAIL ) ) {
return true;
}
return false;
}With the native PHP filter documentation in hand, hundreds of lines of legacy validation logic can go away. That is the sort of refactoring WordPress 7.0 development should be doing.
Core reps and the 6.9 retrospective
Away from the code, the community is looking for 2026 Core Team Representatives. If you have been complaining about how things are run, submit your nomination. The 6.9 retrospective is also open until January 15 if you want to give feedback on the last release cycle. That feedback is how the same mistakes stop repeating.
If this WordPress 7.0 development work is eating your dev hours, I can take it on. I have been wrestling with WordPress since the 4.x days.
Refactor now, don’t wait
The January 14 Dev Chat agenda puts modernization first. Dropping dead PHP versions, standardizing on extensions: the mood is moving from “ship it” to “ship it right.” Ignore that and you will spend 2026 debugging transients and race conditions on broken sites.
