benecaster_addon_activation_changed
Fires after a podcaster switches an add-on on or off for one show, from Settings → Add-ons.
⚠⚠ This is an ACTIVATION change, not an entitlement change, and the whole page depends on the difference. The customer still owns the add-on — they have chosen not to run it on this show, and are expected to switch it back. An add-on that treats this as a revocation and tears down purchased data destroys something the customer still pays for, and the next $enabled = true cannot undo a delete.
What a listener may safely do: drop per-show caches and transients, unschedule per-show cron events, clear a rendered fragment, tell your own service the show’s state moved. What it must not do: delete anything the customer authored or paid for.
React when a podcaster switches your add-on off for one show
benecaster_addon_activation_changed fires after a podcaster switches an add-on on or off for one show, from Settings → Add-ons.
The constraint is the recipe, not the hook. This is an activation change and never an entitlement change. The customer still owns the add-on — they have chosen not to run it on this show, and they are expected to switch it back.
So a listener may drop caches, transients and scheduled tasks, and must not destroy anything the customer authored or paid for. The next $enabled = true cannot undo a delete. An add-on that treats a switch-off as a revocation and clears the show’s accumulated data loses something the customer is still paying for, and the loss surfaces only when they switch it back on and find it empty.
The test to apply to any teardown you are considering: can this be rebuilt from data I still hold? A rendered cache, a derived index, a scheduled job — yes, drop them. Their authored settings, their history, anything they typed — no.
It fires only for a show whose licence already grants the add-on. The controller refuses a write for an ungranted slug, so a callback never sees a switch for something the customer does not own.
⚠ Entitlement changes arrive from the licence server through LicenseValidationCron and do not pass through this hook at all. If you need to react to an add-on being genuinely lost, this is the wrong signal.
<?php
add_action( 'benecaster_addon_activation_changed', function ( string $addon_slug, int $show_id, bool $enabled ): void {
if ( 'benecaster-addon-my-addon' !== $addon_slug ) {
return;
}
if ( $enabled ) {
// Switched ON. Rebuild whatever was dropped last time.
my_addon_warm_cache( $show_id );
return;
}
// Switched OFF. Everything below is DERIVED state -- it can be
// rebuilt from data we still hold, which is the test for whether
// it is safe to drop here.
delete_transient( 'my_addon_cache_' . $show_id );
wp_clear_scheduled_hook( 'my_addon_nightly', [ $show_id ] );
// NOT here, ever:
// - deleting the podcaster's settings for this show
// - deleting content they authored through the add-on
// - revoking anything they purchased
// They still own the add-on and are expected to switch it back on.
// The next `true` cannot undo a delete.
}, 10, 3 );Parameters
| Name | Type | Default | Description |
|---|---|---|---|
$addon_slug |
string |
— | The add-on that was switched. |
$show_id |
int |
— | The show it was switched for. Activation is always per show. |
$enabled |
bool |
— | `true` when switched on, `false` when switched off. |
Examples
Tear down per-show cached state on switch-off
add_action( 'benecaster_addon_activation_changed', function ( string $slug, int $show_id, bool $enabled ): void {
if ( 'my-addon' !== $slug || $enabled ) {
return;
}
delete_transient( 'my_addon_cache_' . $show_id );
wp_clear_scheduled_hook( 'my_addon_nightly', [ $show_id ] );
}, 10, 3 );Notes
Fired by REST\AddonActivationController::update() after the activation layer is written. It never fires for an entitlement change — grants arrive from the licence server through LicenseValidationCron and do not pass through here.
⚠ A slug the show's licence does not grant is refused with 400 addon_not_granted before any write, so this action never fires for one.