Skip to main content

benecaster_subscriber_account_provisioned

Action Free

Fires when a WordPress account is provisioned for a subscriber, by a flow with nobody at a keyboard to choose a password. Four flows reach it: an admin bulk enrollment (bulk_enroll), a subscriber added by hand from the dashboard (manual_add), the donation-completion webhook (donation_signup), and a Migration Wizard import (migration), once for each migrated person who does not already have an account.

With the migration email sequence switched on, a migration account receives no guest_password_set email — the Migration Wizard suppresses it and offers its own way in: a free member gets a set-password link in their migration welcome, and a paying member is signed in by the link they finish with. With the sequence off, the email is sent as usual.

Those subscribers can always reach their feed — the token in the feed URL is the credential — but not the account page or the billing portal, because the account was created with a generated password nobody has seen. Benecaster sends the guest_password_set email on this hook so they have a way in; suppress it with benecaster_subscribe_send_password_email if your own onboarding covers it.

Creation only. It deliberately does not fire for an email address that already had a WordPress account, so adding an existing subscriber to a second show never mails a password-reset link to somebody who already has a login. If you need to react to every enrollment rather than every new account, this is the wrong hook.

It does not fire for self-service signups. [benecaster_subscribe] and [benecaster_follower_signup] both ask the visitor to choose a password on the form, so there is nobody to email. Use benecaster_subscribe_user_created or benecaster_follower_signed_up for those.

Fires before the feed token is generated, so do not look up tokens or feed URLs from here. Use benecaster_token_generated for post-token work.

Parameters

Name Type Default Description
$user_id int — WordPress user ID of the newly created account
$show_id int — ID of the show the account was provisioned against
$source string — Which flow created the account: `bulk_enroll`, `manual_add`, `donation_signup` or `migration`. Branch on it when a hand-added comp warrants different treatment from a 400-address import.

Examples

Tag the new account in a CRM, with the flow that created it

add_action( 'benecaster_subscriber_account_provisioned', function ( int $user_id, int $show_id, string $source ): void {
    $user = get_userdata( $user_id );
    if ( ! $user ) {
        return;
    }

    my_crm()->tag( $user->user_email, [
        'show'   => get_the_title( $show_id ),
        'origin' => $source, // bulk_enroll | manual_add | donation_signup | migration
    ] );
}, 10, 3 );

Notes

Volume. A bulk import of 400 addresses fires this 400 times in one job, and Benecaster sends a set-password email on each — on top of the welcome email, so 800 messages. Keep listeners cheap, and use benecaster_subscribe_send_password_email with $source === 'bulk_enroll' if the second wave is unwanted.

The $source argument is the same string the email filter receives, so a suppression rule and a listener can agree on which flows they care about without inspecting anything else.

Related Recipes

Need this built rather than just documented? See our services →