Skip to main content

benecaster_token_reactivation_blocked

Action Premium Since v1.0.0

Fires from TokenManager::generate_or_reactivate() when a subscription activation event arrives for a subscriber whose token was revoked, and that revocation is not recoverable — meaning a podcaster revoked it deliberately rather than it lapsing through an automated pathway.

This is the guard that stops a bridge event undoing a podcaster’s decision. Without it, a subscriber whose access was revoked by hand could restore it simply by resubscribing in the membership plugin, and the podcaster would never know.

Mutually exclusive with benecaster_token_reactivated — exactly one of the two fires on any given activation dispatch.

What determines “recoverable” is the sentinel stored in benecaster_tokens.revocation_reason, checked through RevocationReasons::is_recoverable(). Automated pathways (BRIDGE_CANCELLATION, GRACE_TIMEOUT, PROMOTE_GRACE_EXPIRED, MANUAL_GRANT_EXPIRED) reactivate normally; ADMIN_REVOKED does not. A NULL or empty reason is treated as recoverable, so tokens revoked before 1.42.0 are not stranded.

The intended use is telling the podcaster. Core ships RevocationBlockedNoticePublisher, which turns this into a Warning-tier admin notice prompting them to either Reset Token or deliberately reinstate access — the subscriber is paying and receiving nothing, so silence is the wrong outcome for everybody.

Parameters

Name Type Default Description
$token_id int ID of the revoked token record that was not reactivated
$user_id int WordPress user ID
$show_id int ID of the show
$tier_slug string Tier slug the activation event was requesting
$reason string The `revocation_reason` sentinel that blocked reactivation — in practice `ADMIN_REVOKED`, or a custom sentinel an add-on registered and deliberately left out of the recoverable list.

Examples

Notify the podcaster that a paying subscriber is being refused

add_action( 'benecaster_token_reactivation_blocked', function ( int $token_id, int $user_id, int $show_id, string $tier_slug, string $reason ): void {
    $user = get_userdata( $user_id );
    if ( ! $user ) {
        return;
    }

    wp_mail(
        get_option( 'admin_email' ),
        sprintf( 'Subscription refused for %s', $user->user_email ),
        sprintf(
            "%s resubscribed to %s at tier %s, but their access was revoked (%s) and was not restored.\n\n"
            . "They are being billed and receiving nothing. Reinstate or refund.",
            $user->user_email,
            get_the_title( $show_id ),
            $tier_slug,
            $reason
        )
    );
}, 10, 5 );

Notes

This is a Premium hook — it is only registered when a valid license is active.

Treat this as a billing problem, not a logging event. The subscriber has an active, paying subscription in the membership plugin and is receiving no feed. Every dispatch of this hook is somebody paying for nothing, and the longer it goes unnoticed the more likely it ends in a chargeback rather than a support ticket.

To actually restore access, use Reset Token — that mints a new token and clears the revoked state. Simply re-running the activation will hit this hook again.

[benecaster_recipe name="notify-admin-on-blocked-token-reactivation"]