The latest WordPress Dev Chat had two things in it worth your time. The WordPress 6.9 release retrospective is open, so go leave feedback there. The more interesting thread was a technical argument about server requirements and the PHP filter extension. If you have ever had a site break because a host trimmed down their PHP build, you already know why that argument matters.
The meeting, facilitated by Benjamin Zekavica, worked its way around to whether the filter extension counts as a “default” requirement for WordPress Core. That is not a question only the hosting team cares about. It decides how email validation and input sanitization get written in custom themes and plugins too.
The PHPMailer gotcha
Core leans on the filter extension in a handful of places, and the one that matters is the bundled PHPMailer library. Dmsnell raised the concern about calls like FILTER_VALIDATE_EMAIL: convenient, but they turn an extension that is not enabled on every server into a hard dependency.
I have hit this myself. You ship a site to a client’s legacy VPS and wp_mail() starts failing without saying a word, because the PHP binary was compiled without --with-filter. Debugging it is miserable, since the error rarely surfaces anywhere you happen to be looking.
For how these core cycles usually play out, I wrote up why WordPress 6.9 is a major win for real developers earlier.
Refactoring for portability
The suggestion from contributors like Realloc is the simple one: rather than pushing every host to enable the extension, drop the dependency. WordPress already ships validation and sanitization functions such as is_email() and sanitize_text_field(), and none of them go through filter_var().
Whatever the Core team settles on for WordPress 7.0, validation in your own code can stay portable with very little effort:
<?php
/**
* Example of a portable email validation check.
* Prefixing with bbioon_ to avoid collisions.
*/
function bbioon_validate_user_email( $email ) {
// Avoid filter_var() if we can't guarantee the extension exists
if ( ! function_exists( 'filter_var' ) ) {
return is_email( $email );
}
// If it exists, we can use it, but is_email() is often more "WordPress-aware"
return filter_var( $email, FILTER_VALIDATE_EMAIL ) && is_email( $email );
}What this means for 6.9 and after
The 6.9 retrospective is the right place to complain about hidden dependencies like this one. The release squad can only act on what people actually report, and the case for a Core that assumes less about the server gets stronger with every host-specific bug somebody writes down.
The direction of travel is a leaner Core. Every edge-case extension requirement that gets removed is one less class of bug that only reproduces on somebody else’s host. I expect this one to come back around in next week’s chat.
If chasing Core changes like this is eating hours you would rather spend shipping, that is work I can take on. I have been doing this since the 4.x days.
The developer takeaway
Do not assume your local environment matches the production server. If your logic calls filter_var(), wrap it in a function_exists() check, or skip it and use the WordPress API instead. The same code then runs on a tuned AWS stack and on a cheap shared host without special cases.
