Promote to Bridge — Grace Period
Promote to Bridge moves subscribers out of Benecaster’s built-in membership system and into an external membership plugin. It runs in that direction only — there is no reverse wizard that moves subscribers from an external plugin into built-in membership, and no way to promote between two external plugins. See Promote to Bridge — Overview for the full picture.
When you run the Promote to Bridge wizard, each promoted subscriber is given a grace period — a window during which their existing Benecaster feed token continues to work even though they are no longer being managed by the built-in membership system. Subscribers keep the same feed token and URL throughout — nothing about their feed changes when they promote successfully. Only which system Benecaster checks to confirm they’re still an active member changes. The grace period gives subscribers time to complete setup in the destination membership plugin before their old feed token is revoked. On default settings that URL does not stop working — it falls back to your public feed, because the per-show Serve the public feed on an invalid token setting is on by default and governs subscriber-level failures like this one. Turn it off for the show and the URL returns an error instead.
How the Grace Period Works
At the moment the wizard runs, Benecaster writes a promote_grace_period_ends_at date to each promoted subscriber’s record. The daily cron (GracePeriodExpiryCheck) evaluates all rows with a non-null value on this column:
Reminder pass — when a subscriber’s grace period ends within the next 9 days and hasn’t been reminded yet, the cron sends a promote_grace_reminder email. A normal grace period is reminded about 9 days out, and a date first set closer than that is reminded at the next daily check. It is sent once per grace end date. Before emailing, the cron records the send on the subscriber’s row, so the several daily checks a row spends inside that window send one email between them, and two checks running at once cannot both send. The window also absorbs a missed tick, which matters because WP-Cron needs web traffic to fire and a quiet site can skip a calendar day.
Extending a grace period resets the reminder. After Extend, the subscriber gets one new reminder giving the new end date, at the next daily check, however close that date is. Extend doesn’t send it at once. Mark re-authorized sends none.
Expiry pass — when promote_grace_period_ends_at is in the past, the cron first checks, automatically and by default, whether the subscriber is confirmed active in the destination plugin. If they are, their token is kept and none of the rest of this pass runs — no revoke, no benecaster_promote_grace_expired action, no promote_grace_expired email. If they are not (or automatic detection can’t tell, for instance because the destination plugin is deactivated), the cron revokes the subscriber’s feed token, fires the benecaster_promote_grace_expired action, and sends a promote_grace_expired email, exactly as before this check existed.
A listener you removed gets neither email. Someone you revoked on Benecaster → Subscribers gets no promote_grace_reminder and no promote_grace_expired. Their subscription row still moves to expired and benecaster_promote_grace_expired still fires. If you bring them back while the grace period is running, the reminder can still go out.
A subscriber who bought episodes outright is not revoked. Their token is converted instead: same feed URL, still active, serving your public episodes plus what they bought. The promote_grace_expired email is still sent, because the grace period did end, and the promotion is marked expired so it does not fire again. A subscriber who bought nothing is revoked as described above.
A kept token does not resolve the row. The check re-runs from scratch on every daily tick, so a subscriber kept today reverts to a normal revoke on the next tick if they later cancel in the destination plugin. The row’s grace-deadline badge in Promotion History still shows as past-due while the subscriber is being kept this way — nothing here marks anyone re-authorized. See Promote to Bridge — Overview → Re-authorization for what does.
After expiry, the subscriber’s record retains the promoted_to_bridge field (the target bridge slug) so their history is visible in the Promotion History panel.
Subscriber Experience
On the subscriber account page, subscribers who are in an active grace period see an amber banner. The date and the plugin name are filled in automatically, and the date follows your site’s date format. A subscriber moving to WooCommerce Subscriptions sees:
Your subscription is being transferred
Re-enter your payment details in WooCommerce Subscriptions before 14 September 2026 to keep podcast access.
Re-enter payment details
The plugin name comes from the destination bridge you selected in the wizard, so it matches whatever your subscribers will actually see when they get there.
Re-enter payment details links to the destination plugin’s signup page for the subscriber’s level — the same page the reminder email’s button opens (see Where Subscribers Go to Pay). When no signup page can be found for that level, the banner shows no link. The rest of the banner reads the same either way.
The banner disappears after the grace period ends.
Where Subscribers Go to Pay
Promote creates each subscriber’s membership in the destination plugin without a payment method attached, so the only place they can add one is that plugin’s own signup page. The account-page banner and both grace emails send them there, to the page for the level their tier was mapped to in the wizard:
- The page you confirmed for that level under Show Settings → Subscription → Signup pages, if you entered one.
- Otherwise, the page Benecaster suggests from the plugin’s own settings:
- MemberPress — the membership’s own page
- WooCommerce Subscriptions — the subscription product’s page
- Paid Memberships Pro — the checkout page, with the level added to the address (
?level=) - Restrict Content Pro — the registration page, with the level added to the address (
?level=)
Only pages on your own site are used. When neither gives a page, the banner shows no link and both emails’ buttons open the show page instead, labelled Visit the show page.
Check your Signup pages as soon as the wizard finishes. The Signup pages section appears on the Subscription tab once the show’s payments run through the destination plugin, which is the last thing the wizard does. Open each suggested page to make sure it is the right signup form, and enter your own where it is not or where a level has none. The reminder email goes out up to 9 days before the grace period ends, and the banner and both emails always use the page as it is saved at the time.
Grace Period Emails
Two managed email types fire during the grace period lifecycle:
| Email type | When it sends | Template file |
|---|---|---|
promote_grace_reminder |
Once per end date, up to 9 days before expiry (again at the next daily check after an Extend), unless you have removed the listener | promote-grace-reminder.php |
promote_grace_expired |
On expiry, unless you had removed the listener | promote-grace-expired.php |
The reminder’s button is Re-enter payment details; the expiry email’s is Resubscribe. Both open the destination plugin’s signup page for the subscriber’s level, chosen as described in Where Subscribers Go to Pay. When there is no signup page for the level, both buttons open the show page instead and read Visit the show page.
Both emails are transactional (they cannot be opted out of individually). Both support the merge tags:
| Merge tag | Description |
|---|---|
{{tier_name}} |
The subscriber’s original native tier name |
{{grace_period_end_date}} |
The formatted expiry date |
{{target_plugin_name}} |
The name of the destination membership plugin |
{{signup_url}} |
The destination plugin’s signup page for the subscriber’s level; empty when none can be found |
To customize these email templates, see Customizing Emails.
Managing Grace Periods
Settings → Subscription → Promotion History lists each promoted subscriber as Subscriber name — Tier name, with their email beneath, a grace badge (Grace until , in your site’s timezone and Settings → General date and time formats; Grace expired; or Re-authorized) and the plugin they moved to, by name (→ MemberPress). A subscriber whose account has since been deleted shows as User #N — Tier name.
Rows still in their grace period carry two buttons:
Extend — adds days to the current expiry date. Useful if a subscriber needs extra time to complete setup. The number you type is used exactly as typed: the benecaster_promote_grace_length_days filter described below deliberately does not apply here, so a site varying grace lengths in code cannot make this panel report a change it did not make.
Mark re-authorized — clears the grace end date, so the subscriber’s token is never revoked for this promotion and the row shows Re-authorized. Use it once a subscriber has finished setting up in the destination plugin. It is not offered once a row shows Grace expired: by then the token has been revoked.
There is no bulk grace-period management in V1.
Status: expired_grace
Subscribers whose grace period has ended have their subscription status set to expired_grace. This status is distinct from cancelled — it indicates the subscription ended because of a bridge promotion, not a cancellation event.
For Developers
benecaster_promote_grace_expiry_should_revoke— filter; veto an expiry before anything happens. This is the same filter automatic re-authorization detection uses internally, so its default return value can now arrive asfalse— where it was alwaystruebefore automatic detection existed — whenever the destination plugin confirms the subscriber active. Your own code can add further conditions on top for a subscriber your code can see has finished setting up in the destination plugin.benecaster_promote_grace_length_days— filter; vary the grace length per tier or per subscriber instead of using one number for the whole run. Applies to the wizard only, not to Extendbenecaster_promote_grace_cleared— action; fires after a grace period is cleared from Promotion Historybenecaster_promote_grace_extended— action; fires after a grace period is extended from Promotion Historybenecaster_promote_grace_expired— action fired on expiry; args:(int $user_id, int $show_id, string $tier_slug). Does not fire when an expiry is vetoed- REST API for extending and clearing grace periods: Promote to Bridge REST API
See Also
Need this built rather than just documented? See our services →