I’ve been doing a ton of work with RSS feeds lately, using them to sync data across nearly 2000 sites. I was running into an issue with WP caching of feeds. There’s a filter to change how long WP holds the RSS feed information in cache and is easy to use (link):
function lower_feed_cache_time() {
return 3600;
}
add_filter( 'wp_feed_cache_transient_lifetime', 'lower_feed_cache_time' );
This lowers the time it caches feeds for to 1 hour (3600 seconds), down from a default of 12 hours. This didn’t really work well for me though because I only wanted to have the cache dumped when I was manually syncing my RSS feeds. So instead I wrote a function that uses an SQL query to delete the feed transients in the options table. It looks like this:
function clear_feed_cache() {
global $wpdb;
$num = $wpdb->query($wpdb->prepare("DELETE FROM $wpdb->options WHERE option_name LIKE %s ", '_transient_feed_%'));
error_log($num.' feed transients deleted');
}
This function gets the global $wpdb variable, holding the database information for your site. This functions works in multisite because $wpdb->options holds the name of the options table for the current site you are on. It’s looking for options that have the name like _transient_feed_% – the % being a wildcard. The error_log line comes in handy because it lets me know how many rows were deleted (or if something went wrong and no rows got deleted). Using the error log and running tail -f on it from the command line can be a great help during development. ‘tail -f error_log’ will track the error_log as errors happen, you can see them scroll by. I keep it open a lot.
I hope this helps solve your RSS feed cache problems!