Skip to main content

Trigger a Feed Cache Clear from External Code

Free Beginner

Trigger a Benecaster feed cache clear from any plugin, mu-plugin, or WP-CLI cron job using the benecaster_clear_feed_cache action. Supports global, show-scoped, and tier-scoped clears. benecaster_feed_cache_cleared fires after any clear completes, giving you a hook to respond — log the event, warm the cache, notify a CDN, or anything else.

When to Use This

Use benecaster_clear_feed_cache when:

  • You’ve imported or bulk-updated episodes from an external source (a CSV importer, a REST API sync, a WP-CLI migration script) and want the feed to reflect the changes immediately rather than waiting for the next natural invalidation

  • A custom plugin modifies episode availability dates, tier assignments, or show metadata outside the Benecaster episode editor, bypassing the invalidation hooks that normally fire automatically

  • A scheduled cron job makes changes to content that Benecaster caches and you want a clean flush on a known schedule

  • You’re troubleshooting a stale feed and need to clear programmatically from a script rather than clicking through the admin UI

If Benecaster already knows about your change — because it happened through the episode editor, the Settings UI, or a Benecaster REST endpoint — you do not need this hook. Benecaster invalidates the cache automatically on all those paths.

Where to Put This Code

Code that triggers cache clears should run in a mu-plugin (wp-content/mu-plugins/) or in a site-specific plugin. Both load reliably on every request, including WP-CLI runs and REST API calls. Avoid placing cache-clear logic in theme files — it won’t run in CLI contexts, which is exactly where you often need it.

For WP-CLI scripts or cron jobs, a mu-plugin is the most reliable option since it loads before any plugin activation checks.

Scopes

How many arguments you pass determines the scope:

Arguments Scope Use when
None Every cached feed on the site You don’t know which show or tier was affected, or after a sitewide change like a batch import
Show ID All tiers for one show Your change affects one show’s content but not others
Show ID, tier slug One tier on one show You know exactly which tier’s episode list changed

The show ID is the WordPress post ID of the Benecaster show.

Responding to a Cache Clear

benecaster_feed_cache_cleared fires after any clear completes — whether triggered by your code, by Benecaster’s own invalidation logic, or by the admin “Clear Feed Cache” button. It passes the scope (global, show, or tier) plus a show ID and tier slug, each null when not applicable. Use it to log, audit, notify a CDN, or warm the cache.

The recipe also includes a worked WP-CLI example: a custom import command that pulls episodes from an external API and fires a show-scoped clear once the import reports work done.

Notes

Prefer scoped clears. A tier-scoped clear is faster than a show-scoped clear, which is faster than a global clear. Use the narrowest scope that covers your change. On a large site with many shows and active subscribers, a global clear triggers a wave of cache rebuilds on the next feed poll — fine for maintenance windows, potentially disruptive during peak listening hours.

The cache rebuilds on the next poll. Clearing the cache does not pre-generate new feeds — it marks the existing entries stale. The next subscriber to poll their feed triggers a fresh compile for that tier. On Redis or Memcached, compiles are fast. On database-only caching at large subscriber counts, back-to-back clears during peak hours can briefly spike database load.

benecaster_feed_cache_cleared fires for all clears. Your callback will fire when Benecaster clears the cache automatically (e.g. when you publish an episode) — not only when your code calls benecaster_clear_feed_cache. If you only want to respond to clears your code triggered, set a flag before calling the action and check it inside the callback.

This action is safe to call multiple times. Clearing an already-empty or already-stale cache entry is a no-op. Firing it in a loop or redundantly has no harmful effect beyond minor extra work.

Related

  • How Feed Caching Works — caching architecture, Redis/Memcached guidance, and hosting recommendations by subscriber count

  • Feeds Overview — how private RSS feeds are structured and delivered

Code

<?php
// From an mu-plugin — clear the cache after your custom bulk update.
add_action( 'admin_notices', function (): void {
    if ( ! current_user_can( 'manage_options' ) || empty( $_GET['my_flush_feeds'] ) ) {
        return;
    }
    // Option A: emit the standard action; FeedCache handles the rest.
    do_action( 'benecaster_clear_feed_cache' );

    // Option B: purge the object-cache group directly when you already
    // know the exact (show, tier) tuple you invalidated.
    $show_id   = 42;
    $tier_slug = 'gold';
    wp_cache_delete( "feed:{$show_id}:{$tier_slug}", 'benecaster_feed' );

    printf(
        '<div class="notice notice-success"><p>%s</p></div>',
        esc_html__( 'Feed cache cleared.', 'my-mu-plugin' )
    );
} );

View on GitHub →

Hooks Used

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

Powered by