In WordPress 7.1, comment approval status is incorporated into the default before notify_post_author runs, so the filter can intentionally return true for pending, spam, or trash comments. Plugins that attach __return_true or return loose truthy values can therefore send post-author notifications they did not send before.
Use this for moderation plugins, editorial workflows, membership sites, help desks, spam tools, and custom comment-email integrations.
Quick answer
Find every notify_post_author callback, especially __return_true. Create approved, pending, spam, trash, and invalid-ID fixtures. Return a strict boolean based on explicit status and business rules, then verify one expected message or no message with a mail-capture tool. Do not test by emailing real authors.
What to check first
- Search plugins, must-use plugins, theme code, and snippets for notify_post_author and __return_true.
- Document which comment statuses are allowed to email each author role.
- Create approved, pending, spam, trash, and invalid comment-ID fixtures.
- Capture callback input, return type, status, recipient, subject, and message count.
- Verify duplicate prevention when moderation status changes after the initial comment event.
Why this usually happens
- A callback written to override an older default can become the final decision under the new order.
- __return_true does not inspect approval status, recipient context, or message duplication.
- Loose truthy return values hide whether the plugin intended a boolean decision.
Useful command or data shape
Adapt paths, IDs, and privacy handling to the site before running commands or storing data on production.
add_filter( 'notify_post_author', function ( $notify, $comment_id ) {
$comment = get_comment( $comment_id );
if ( ! $comment ) {
return false;
}
return '1' === (string) $comment->comment_approved && (bool) $notify;
}, 10, 2 );
Diagnostic table
Use this table to connect the observed behavior to evidence and a verification step.
| Action | Evidence to collect | How to verify |
|---|
| Inventory callbacks | Search plugins, must-use plugins, theme code, and snippets for notify_post_author and __return_true. | Every callback returns true or false intentionally. |
| Define allowed statuses | Document which comment statuses are allowed to email each author role. | Approved comments send exactly the expected number of messages. |
| Replace unconditional returns | Create approved, pending, spam, trash, and invalid comment-ID fixtures. | Pending, spam, and trash behavior matches the written rule. |
| Run mail-capture fixtures | Capture callback input, return type, status, recipient, subject, and message count. | Invalid IDs return false and no real recipient receives test mail. |
Decision rule
Hold the upgrade when spam, trash, or pending fixtures produce unexpected author mail, a callback returns a non-boolean value, an invalid ID reaches custom logic, or moderation transitions create duplicates.
Test scenarios to run
Run the same controlled fixture across these branches. Write down the expected result before testing so a surprising response is easy to identify.
| Scenario | Fixture | Expected result |
|---|
| Approved | Normal approved comment on a published post | Author receives one expected notification |
| Pending | Comment awaiting moderation | Notification follows the explicit business rule |
| Spam or trash | Comment marked spam or trash before decision | No email unless a narrow callback intentionally permits it |
| Invalid ID | Call the decision path with a missing comment ID | Returns false without invoking the filter |
Safe fix order
Use a sequence that makes each result easy to prove. Stop when new evidence changes the scope or owner of the problem.
- Inventory callbacks
- Define allowed statuses
- Replace unconditional returns
- Run mail-capture fixtures
- Monitor production message counts
Production verification checklist
- Every callback returns true or false intentionally.
- Approved comments send exactly the expected number of messages.
- Pending, spam, and trash behavior matches the written rule.
- Invalid IDs return false and no real recipient receives test mail.
What to tell the client or owner
Share the comment status, post author role, callback name, priority, input default, return value and type, recipient, message count, moderation transition, and WordPress build.
Mistakes to avoid
- Do not leave __return_true attached without reviewing the new behavior.
- Do not test against a production author's mailbox.
- Do not ignore duplicate mail after moderation transitions.
- Do not infer delivery from a successful wp_mail return alone.
Questions teams ask during testing
Does WordPress 7.1 email authors about spam by default?
No. The key change is that a filter returning true can now override the default status decision.
Why use strict booleans?
The updated contract expects a clear true or false decision and avoids accidental truthy values.
What happens with an invalid comment ID?
The Core dev note says the function returns false without applying the filter.
When HandL WP should help
HandL WP can trace comment notification callbacks, build safe moderation fixtures, capture outbound messages, correct status logic, and verify deliverability without contacting real authors.
If this is active on a production site, audit WordPress comment emails.
Related HandL WP guides
Use these related guides when the same issue touches tracking, security, checkout, or crawler visibility.
Helpful references