benecaster_subscribe_send_password_email
Controls whether core sends the guest_password_set email when [benecaster_subscribe] creates a WordPress account on the fly for a logged-out visitor. Default: true. Consulted by SubscribeGuestPasswordListener::maybe_send() before the template is rendered.
Return false to suppress it — the case this exists for is a site whose own onboarding flow already sends a welcome-and-set-password message, where core’s email would be a duplicate.
⚠ This gates the email only. benecaster_subscribe_user_created still fires either way, so listeners doing non-email work — CRM enrolment, tagging, analytics — are unaffected.
Parameters
| Name | Type | Default | Description |
|---|---|---|---|
$should_send |
bool |
— | Whether to send. `true` unless already filtered. |
$user_id |
int |
— | WordPress user ID of the newly created account. |
$show_id |
int |
— | ID of the show being subscribed to, so the decision can vary per show. |
Returns:
bool
Examples
Suppress core's email because our own onboarding covers it
add_filter( 'benecaster_subscribe_send_password_email', function ( bool $should_send, int $user_id, int $show_id ): bool {
// Our welcome sequence already includes a set-password link.
return false;
}, 10, 3 );Notes
⚠ If you suppress this, you must provide a password path yourself. An account created by wp_create_user() has no password, so a visitor with no reset link cannot log in at all — they can still receive their feed, but they cannot reach the account page to get it, reset a token, or manage anything. Suppressing without a replacement strands the subscriber, and the symptom arrives later as a support request that looks unrelated.
Do not suppress in order to send your own alongside core's. Two set-password emails means two single-use reset links, and the later one invalidates the earlier — a subscriber who opens the first email gets an expired-link error. Suppress core's, then send yours.
[benecaster_recipe name="suppress-guest-password-email-per-role"]