
Anatoliy Dovgunadd_filter( 'send_email_change_email', '__return_false' ) Enter fullscreen mode ...
add_filter( 'send_email_change_email', '__return_false' )
Why Returning False Changes the Core Email Flow in WordPress
Filters in WordPress are often described as tools for modifying data.
In real-world systems — they control behavior.
And in complex architectures, they prevent infrastructure-level failures.
This article walks through a real B2B marketplace migration case and explains why returning false in specific filters is not a hack — but an architectural control decision.
The Scenario: B2B Marketplace + CRM Migration
Imagine:
At first glance, this looks like a standard import task.
It isn’t.
What WordPress Does by Default
When wp_update_user() runs and detects an email change, WordPress:
Additionally, depending on context, WordPress may also trigger:
For interactive user behavior — this is correct.
For CRM-driven migration — this is dangerous.
The Infrastructure Risk
Uncontrolled email triggers during migration can cause:
This is not a minor technical detail.
This is product-level and infrastructure-level risk.
The First Layer of Control (And Why It Wasn’t Enough)
During initial system design, we anticipated user creation issues.
So we disabled new user notifications:
add_filter( 'wp_send_new_user_notification_to_user', '__return_false' );
That solved welcome emails during migration.
But real-world testing exposed a gap.
Because:
Even with new user notifications disabled, WordPress still triggered:
send_email_change_email
Because from core perspective — email change is a separate lifecycle event.
Lesson:
Disabling one filter does not mean you control the lifecycle.
The Critical Decision Point
To prevent email change notifications:
add_filter( 'send_email_change_email', '__return_false' );
By default → true.
We explicitly return false.
Important:
This does not:
It changes a boolean decision flag.
That’s a behavioral override.
And that’s an architectural choice.
Why This Is Architecturally Significant
There is a difference between:
Boolean filters like:
are not data transformers.
They are behavioral switches.
They sit at decision points inside core.
Changing them alters system flow — not data integrity.
That distinction matters.
Scoped Implementation (Best Practice)
This should never be applied blindly in production.
Recommended approach:
if ( defined( 'CRM_MIGRATION_PROCESS' ) && CRM_MIGRATION_PROCESS ) {
add_filter( 'send_email_change_email', '__return_false' );
}
Better yet:
Control the scope.
Never globally suppress lifecycle behavior without context.
A Practical Classification of WordPress Filters
Understanding filter types helps avoid architectural mistakes.
1. Data Filters
Modify values.
Examples:
2. Boolean Control Filters
Control system decisions.
Examples:
These are control switches.
3. Pre-Persistence Filters
Run before saving data.
Example:
pre_insert_user_data
4. Capability & Security Filters
Control permissions.
Example:
In our migration case, we were dealing with Boolean Control Filters.
These require architectural awareness.
Why This Was Required in B2B Context
From UX perspective — notifications would create noise.
From infrastructure perspective — risk.
From architecture perspective — mandatory control.
Engineering Lessons
Study full lifecycle, not just creation.
Inspect internal trigger points in wp_update_user().
Map all related filters before mass operations.
Use scoped boolean filters.
Document every override.
WordPress core works correctly.
But it works correctly for interactive user flows.
CRM-driven synchronization is not interactive.
If you do not control trigger points —
core will execute its default behavior.
Final Thought
add_filter( 'send_email_change_email', '__return_false' );
This is not about “turning something off.”
It is about taking control over system behavior.
In complex B2B systems, filters are not customization tools.
They are infrastructure control mechanisms.
And every time you override default WordPress behavior,
you are making an architectural decision — not just writing code.