Title: Enabling Cache support breaks filter API
Last modified: August 30, 2016

---

# Enabling Cache support breaks filter API

 *  Resolved [TR.Martin](https://wordpress.org/support/users/trmartin-1/)
 * (@trmartin-1)
 * [10 years, 6 months ago](https://wordpress.org/support/topic/enabling-cache-support-breaks-filter-api/)
 * Before I get into this I do want to say Thank You for a great plugin very well
   written easy to read. So thank you very much..
 * On my website I have a need to dynamically bar certain post ID’s from showing
   up in the results. To accomplish this I’m using the filter API ‘get_crp_posts_id’.(
   oh sorry I’m using: crp ver 2.2.3)
 * At first my filter was not getting executed and I couldn’t figure it out. What
   I found was, when the cache was enabled many of the APIs are never applied.
 * I isolated it down to line 128 in contextual-related-posts.php in the get_crp()
   routine. If the $output is valid there’s a ‘return $output;’ and it exits the
   get_crp() routine. This makes all the following apply_filter()’s unreachable 
   hence not hookable by themes when caching is enabled.
 * I don’t know if this is the spec’d behavior or just an oversight, in the case
   it’s the later I thought I’d bring it to your attention. If it’s as spec’d a 
   you might want to add a FAQ blurb..
 * Cheers & Thanks!!
    Todd Martin
 * [https://wordpress.org/plugins/contextual-related-posts/](https://wordpress.org/plugins/contextual-related-posts/)

Viewing 10 replies - 1 through 10 (of 10 total)

 *  Plugin Author [WebberZone](https://wordpress.org/support/users/webberzone/)
 * (@webberzone)
 * [10 years, 6 months ago](https://wordpress.org/support/topic/enabling-cache-support-breaks-filter-api/#post-6844395)
 * Todd, thank you for reporting this. Line 128 exits the routine when the cache
   is enabled as you might have figured out.
 * It’s quite aggressive so I’m not sure you’d be able to tap `get_crp_posts_id`
   always. However, it’s worth changing the line to:
 *     ```
       return apply_filters( 'get_crp', $output, $args );
       ```
   
 *  Thread Starter [TR.Martin](https://wordpress.org/support/users/trmartin-1/)
 * (@trmartin-1)
 * [10 years, 5 months ago](https://wordpress.org/support/topic/enabling-cache-support-breaks-filter-api/#post-6844417)
 * Thanks for the quick reply,
 * For right now it’s easier for me to disable the caching and hook the get_cpr_posts_id.
   I’ll look into hooking the Get_crp my site is pretty small so I’m not overly 
   concerned with the performance hit.
 * Meanwhile I’ll go ahead and close out this question as resolved..
 * Cheers & Thanks
    Todd Martin
 *  Plugin Author [WebberZone](https://wordpress.org/support/users/webberzone/)
 * (@webberzone)
 * [10 years, 5 months ago](https://wordpress.org/support/topic/enabling-cache-support-breaks-filter-api/#post-6844478)
 * Thanks Todd.
 * The more I think about it, what exactly are you trying to do with the get_crp_posts_id
 * In theory, it should work even with the cache because it kicks in the first time.
   Of course, for subsequent loads that won’t work because of the cache.
 *  Thread Starter [TR.Martin](https://wordpress.org/support/users/trmartin-1/)
 * (@trmartin-1)
 * [10 years, 5 months ago](https://wordpress.org/support/topic/enabling-cache-support-breaks-filter-api/#post-6844481)
 * I will be the first to admit my use case model is definitely out there in the
   corner , but here’s the situation. My website is a traveling/sailing website 
   and I’m catering to two very different users: ‘public’ (aka anyone on the internet)
   and ‘private’ (friends and family).
 * As a security precaution (and management efficiency) I created a quarantine period
   for all my posts once they are published. This allows the ‘private’ users to 
   see things in real-time but the ‘public’ visitors get the information delayed
   by the predetermined quarantine period (currently a week). If there are any internet
   bad guys out there thinking they can track me in real time and possibly try to
   rob me or the boat they’ll always be a few steps behind.
 * To accomplish this I’m hooking all the publication points (eg. WordPress core,
   yoast sitemap, Social media auto-poster, etc) and verify the post is either out
   of the quarantine period or the user is logged in and trusted.
 * On your plugin you’re hooking the publish event where the post would definitely
   be in quarantine but the published results can be displayed either during the
   quarantine period or after it has elapsed or a trusted visitor is viewing the
   page and that’s where I run afoul with the caching scheme.
 * So you can see my particular setup is time dependent and not the normal use case
   model everyone is use too. I hope this helps..
 * Cheers & Thanks
    Todd
 *  Plugin Author [WebberZone](https://wordpress.org/support/users/webberzone/)
 * (@webberzone)
 * [10 years, 5 months ago](https://wordpress.org/support/topic/enabling-cache-support-breaks-filter-api/#post-6844514)
 * That is indeed a complicated, but interesting setup.
 * And, does this work with the CRP cache disabled because the posts are always 
   displayed on the fly?
 * You could in theory set up a cron job / event that would trigger a cache clearing
   at the time of the post coming out of quarantine. Is there an event trigger like
   this?
 *  Thread Starter [TR.Martin](https://wordpress.org/support/users/trmartin-1/)
 * (@trmartin-1)
 * [10 years, 5 months ago](https://wordpress.org/support/topic/enabling-cache-support-breaks-filter-api/#post-6844526)
 * With cache disabled and hooking ‘get_crp_posts_id’ it works well enough. if I
   find an ID match for a post in quarantine I just remove it from the list. So 
   my list of related posts can be decreased, which is good enough since it’s some
   what ephemeral, (I know I’m operating outside the norm) I also didn’t want to
   interfere with the actual relation ship mathematics schema, I felt it was a lighter
   touch to just hold back a post at rendering time. its a small price to pay.
 * I hadn’t thought of the cron job solution, that’s interesting. I’ll need to tinker
   with that to see how well it works.
 * thanks for the help
    Todd Martin
 *  Plugin Author [WebberZone](https://wordpress.org/support/users/webberzone/)
 * (@webberzone)
 * [10 years, 5 months ago](https://wordpress.org/support/topic/enabling-cache-support-breaks-filter-api/#post-6844534)
 * You’re welcome. I’d be interested in knowing exactly what you do to fix this.
 * It is always a learning lesson for me in this.
 *  Thread Starter [TR.Martin](https://wordpress.org/support/users/trmartin-1/)
 * (@trmartin-1)
 * [10 years, 5 months ago](https://wordpress.org/support/topic/enabling-cache-support-breaks-filter-api/#post-6844536)
 * My fix/hack was nothing elaborate.. I disabled the CRP cache so the intermittent
   apply_filters() would be executed.
    then added this simple routine to my functions.
   php file.
 *     ```
       /* Make sure the results provided by the Contextual related Posts(CRP) plug-in are honoring the quarantine time.
        * if a post is choosen by CRP check it's ID and if it's still in quarantine, remove it from display */
       if ( function_exists( 'get_crp' ) ) :
       function contextual_related_ID_filter($data){
       	$x=0;						// index for array received from CRP.
       	$roles = array('editor','author','administrator','realtimesubscriber');
   
       	/* first check user role if they have rights no need to filter the CRP results */
       	if(is_user_logged_in()){											// if user is logged in ?
       		if(check_user_role($roles))										// then check their granted roles.
       			return $data;												// if user allowed show show next link
       	}
   
       	/*public user we need to filter the results*/
       	foreach($data as $i){
       		if(is_quarantine($i->ID)){
       			unset($data[$x]);
       		}
       		$x++;
       	}
       	return $data;
       }
       add_filter('get_crp_posts_id','contextual_related_ID_filter');
       endif;
       ```
   
 *  Plugin Author [WebberZone](https://wordpress.org/support/users/webberzone/)
 * (@webberzone)
 * [10 years, 5 months ago](https://wordpress.org/support/topic/enabling-cache-support-breaks-filter-api/#post-6844537)
 * Thanks. This is useful. Do you mind editing and wrapping your post above with
   the code button so the forum displays this better.
 *  Thread Starter [TR.Martin](https://wordpress.org/support/users/trmartin-1/)
 * (@trmartin-1)
 * [10 years, 5 months ago](https://wordpress.org/support/topic/enabling-cache-support-breaks-filter-api/#post-6844538)
 * There that looks much better..

Viewing 10 replies - 1 through 10 (of 10 total)

The topic ‘Enabling Cache support breaks filter API’ is closed to new replies.

 * ![](https://ps.w.org/contextual-related-posts/assets/icon-256x256.png?rev=2985705)
 * [Contextual Related Posts](https://wordpress.org/plugins/contextual-related-posts/)
 * [Frequently Asked Questions](https://wordpress.org/plugins/contextual-related-posts/#faq)
 * [Support Threads](https://wordpress.org/support/plugin/contextual-related-posts/)
 * [Active Topics](https://wordpress.org/support/plugin/contextual-related-posts/active/)
 * [Unresolved Topics](https://wordpress.org/support/plugin/contextual-related-posts/unresolved/)
 * [Reviews](https://wordpress.org/support/plugin/contextual-related-posts/reviews/)

## Tags

 * [api](https://wordpress.org/support/topic-tag/api/)
 * [cache](https://wordpress.org/support/topic-tag/cache/)
 * [filter](https://wordpress.org/support/topic-tag/filter/)

 * 10 replies
 * 2 participants
 * Last reply from: [TR.Martin](https://wordpress.org/support/users/trmartin-1/)
 * Last activity: [10 years, 5 months ago](https://wordpress.org/support/topic/enabling-cache-support-breaks-filter-api/#post-6844538)
 * Status: resolved