WordPress 7.0 development is officially kicking into gear, and the first big move is one that has been a long time coming. Specifically, we are finally seeing the core team pull the plug on PHP 7.2 and 7.3 support. For those of us who have spent years maintaining legacy code for “maximum compatibility,” this is a massive sigh of relief.
It’s not just about cleaning up the technical debt; it is about performance and security. Every time we have to refactor a modern PHP feature because we’re worried about a race condition on an ancient server, we lose time. Furthermore, navigating these version shifts is simply part of core development hygiene.
Why WordPress 7.0 Development is Dropping PHP 7.2
The decision to drop support for PHP 7.2 and 7.3 in WordPress 7.0 isn’t arbitrary. These versions reached end-of-life years ago. By raising the floor to PHP 7.4 (and ideally pushing users toward 8.2+), the core team can finally utilize typed properties, arrow functions, and better error handling without fear of breaking half the internet.
We recently discussed the technical implications of dropping PHP 7.2 support in version 7.0. If you are a plugin author, this is your signal to stop testing against these versions. Start leveraging the modern engine. Therefore, if your hosting provider is still stuck on 7.2, they aren’t just behind; they are a bottleneck for your business.
The “Filter” Extension Debate
One of the more technical items on the latest Dev Chat agenda is whether to make the PHP filter extension a default requirement. This is a pragmatist’s dream. Relying on filter_var() for sanitization and validation is far more efficient than building custom regex monsters or heavy wrappers in the core.
However, the challenge is always the “minimum environment.” If you’re building custom solutions, you should already be checking for these extensions. Here is how I usually handle this to avoid a fatal error in a production environment:
<?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;
}Using the native PHP filter documentation as a guide, we can replace hundreds of lines of legacy validation logic. This is exactly the kind of refactoring that WordPress 7.0 development needs to stay relevant in 2026.
Get Involved: Core Reps and 6.9 Retrospectives
Beyond the technical shifts, the community is looking for 2026 Core Team Representatives. If you have been complaining about how things are run, now is the time to submit your nomination. In contrast, the 6.9 retrospective is open until January 15 for anyone who wants to provide feedback on the last release cycle. Feedback loops are the only way we stop repeating the same mistakes.
Look, if this WordPress 7.0 development stuff is eating up your dev hours, let me handle it. I’ve been wrestling with WordPress since the 4.x days.
Refactor Now, Don’t Wait
The agenda for the January 14 Dev Chat is clear: modernization is the priority. Whether it is dropping dead PHP versions or standardizing on extensions, the “ship it” mentality is shifting toward a “ship it right” mentality. Consequently, those who ignore these updates will find themselves debugging transients and race conditions on broken sites come 2026.
