Caching

Fetching from remote APIs on every page load would be slow and rate-limited, so WP Social Ninja caches platform responses in the wpsr_caches table and refreshes them on a schedule.

The cache table

Each cache row (see Schema) holds:

• platform + name — the cache key
• value — the cached payload
• expiration — when it goes stale
• failed_count — consecutive fetch failures (used for back-off)

The base platform classes expose saveCache() / deleteCache() so a platform service rarely touches the table directly.

Refresh via cron

app/Hooks/Handlers/SchedulerHandler.php schedules per-platform refresh jobs. When a cache expires, the relevant cron action fires and the platform re-fetches:

• wpsr_{platform}_feed_update
• wpsr_{platform}_reviews_update
• wpsr_{platform}_send_email_report

See Action Hooks → Cache, Scheduler & Cron.

Purging

When caches are cleared (manually or programmatically), core fires:

do_action('wpsocialreviews/purge_cache');

Feeds/CacheHandler.php also integrates with common third-party page caches (LiteSpeed, Nginx Helper, Breeze) so their caches are busted when WP Social Ninja's are.

// Also clear your own cache layer when WPSN purges
add_action('wpsocialreviews/purge_cache', function () {
    my_cdn_purge_tag('wpsn');
});

Per-platform cache clearing

The admin can clear a single platform's cache, which routes through the dynamic hook:

do_action('wpsocialreviews/clear_cache_{platform}', $cacheType);

Implement wpsocialreviews/clear_cache_myplatform in your platform service to respond.

Don't over-cache during development

While building a platform, temporarily lower the cache expiration (or call deleteCache()) so you see fresh API responses without waiting for the cron schedule.