Skip to main content

Fire add-on side effects when a show is archived or restored

Free Beginner

Archiving a show retires it without destroying anything. Benecaster stops serving its feed — podcast apps get an HTTP 410, which tells them the show is gone for good rather than temporarily broken — but the episodes, subscribers, and tokens all stay put, and restoring the show brings it back exactly as it was.

Why this matters for an add-on. Benecaster cleans up after itself, but it knows nothing about the data your add-on keeps alongside a show: cached artwork, scheduled jobs, rows in your own tables, a mirror of the show in some external service. If you do not react to archival, that material carries on as though the show were still live — jobs keep running, caches keep serving, and a restore leaves you out of step with Benecaster. Listening to benecaster_show_archived and benecaster_show_unarchived lets you pause and resume in step with the podcaster’s own action.

Archival is not deletion. Neither action fires when a show is permanently deleted, because archiving is a soft delete and the two deserve different handling — pause on archive, tear down on delete. For permanent removal, hook WordPress’s own deleted_post and check that the post type is benecaster_show.

Code

<?php
add_action( 'benecaster_show_archived', function ( int $show_id ): void {
    // Farewell email to subscribers whose access is about to break.
    $recipients = get_show_subscriber_emails( $show_id );
    benecaster_mail( $show_id, $recipients, __( 'Feed archived', 'my-addon' ), '…' );

    // Clear any add-on caches keyed on the show.
    wp_cache_delete( "my_addon_show_{$show_id}", 'my_addon' );
} );

add_action( 'benecaster_show_unarchived', function ( int $show_id ): void {
    // Re-warm caches so the first subscriber poll after restore is fast.
    prime_my_addon_show_cache( $show_id );
} );

View on GitHub →

Hooks Used

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

Powered by