#64217 closed defect (bug) (fixed)
Comment approval/type check runs after `notify_post_author` filter
| Reported by: | adamsilverstein | Owned by: | adamsilverstein |
|---|---|---|---|
| Priority: | normal | Milestone: | 7.1 |
| Component: | Comments | Version: | |
| Severity: | normal | Keywords: | has-patch commit has-unit-tests has-dev-note |
| Cc: | Focuses: |
Description (last modified by )
The notify_post_author filter "Filters whether to send the post author new comment notification emails, overriding the site setting.". However the current code performs two logic checks after the filter - before actually sending the notification. Notifications are only sent if the comment type is a note, or the comment is approved. notifications are not sent for unapproved comments, even when notify_post_author returns true.
Therefore, it makes sense to move these logic checks _before_ the filter which would give developers core complete control over notifications.
Change History (16)
This ticket was mentioned in PR #10489 on WordPress/wordpress-develop by @adamsilverstein.
11 months ago
#1
- Keywords has-patch added
This ticket was mentioned in Slack in #core by audrasjb. View the logs.
8 months ago
#5
@
8 months ago
- Keywords needs-refresh changes-requested added
As per today's 7.0 bug scrub:
This ticket has a PR which only needs to be refreshed against trunk and some adjustments (like since tags and a small wpcs fix). Pinging @adamsilverstein if you have the time to close this one.
This ticket was mentioned in Slack in #core by audrasjb. View the logs.
7 months ago
#7
@
7 months ago
The PR is ready, however we should probably just punt to 7.1 given the lateness in the cycle, this is more of an edge case bug anyway. What do you think @westonruter ?
This ticket was mentioned in Slack in #core by audrasjb. View the logs.
7 months ago
@adamsilverstein commented on PR #10489:
4 months ago
#10
@westonruter whenever you have a moment, this is ready for review again.
@adamsilverstein commented on PR #10489:
3 months ago
#11
## Draft dev note for the 7.1 field guide
### The notify_post_author filter now has the final say on post author notifications
WordPress 7.1 changes when the comment approval status is checked in wp_new_comment_notify_postauthor(). See #64217.
Previously, the notify_post_author filter received a default value derived only from the comments_notify (or wp_notes_notify) option. The comment's approval status was checked *after* the filter ran, which had two consequences:
- The filter received a misleading default of
truefor unapproved comments, even though no notification would be sent. - Returning
truefrom the filter could not force a notification for an unapproved comment - the return value was silently discarded.
As of 7.1, the approval status is incorporated into the default value passed to the filter, and the filter's return value is final:
- The default is
falsefor unapproved comments (including spam and trash). - The default for notes continues to follow the
wp_notes_notifyoption regardless of approval status, and the default for approved comments continues to follow thecomments_notifyoption. - Returning
truefrom the filter now sends the notification, even for an unapproved comment.
In addition, the filter no longer fires when the passed comment ID does not resolve to a valid comment; the function returns false immediately.
Who is affected: Sites or plugins using a callback such as __return_true on notify_post_author to force notifications will now also receive emails for comments held in moderation, marked as spam, or trashed. If that is not desired, the callback should check the comment's approval status:
add_filter( 'notify_post_author', function ( $maybe_notify, $comment_id ) { $comment = get_comment( $comment_id ); // Only force notifications for approved comments. if ( $comment && '1' === $comment->comment_approved ) { return true; } return $maybe_notify; }, 10, 2 );
Callbacks that only *suppress* notifications (returning false) are unaffected.
@adamsilverstein commented on PR #10489:
3 months ago
#13
Thanks @westonruter - I'll get this committed.
![(please configure the [header_logo] section in trac.ini)](/chrome/site/your_project_logo.png)
Trac ticket: https://core.trac.wordpress.org/ticket/64217