I figured out it was a problem with Redis Cache on my server. I’m wondering why it’s not updated when a settings is updated (I saw stale settings) or purchase is made. Might not be related to this plugin though. But worth checking what http request method is made on saving the changes – if it’s GET instead of POST then cache won’t be updated.
I got some feedback from my hosting provider as well.
Problem Description: When a user purchases a product, their access permissions do not update immediately. Even after a successful transaction, the user is still being redirected to the “no access” page. Conversely, sometimes users who should be restricted can still see the content. The issue only resolves after a manual flush of the Redis cache.
Technical Details: My hosting provider investigated the issue and confirmed that Nginx FastCGI cache is bypassed for logged-in users, so the problem lies within the Object Cache (Redis). It seems the plugin does not trigger a cache invalidation for specific meta keys or option groups when:
- A purchase status changes in WooCommerce.
- Plugin settings are saved in the admin panel.
Question: Does the plugin support wp_cache_delete or wp_cache_flush for its permission checks? If not, could you provide a hook or a snippet that I can use to manually clear the plugin’s cached data when a WooCommerce order is completed?
Looking forward to your help.
The only thing I cache in my plugin is within a page load. So while loading if something is loaded before during that load the cached version will be used but only while loading. It doesnt affect saving to db only reading which isnt stale since its only during page load. The way I handle permissions is by checking with woocommerce if user bought and the order is completed and per page what products are needed. If yes it shows the page if not it doesn’t. I dont cache anything for longer periods exactly for this reason. Cant really help you if your setup caches what shouldn’t be. Also regarding get/post my plugin should be using mostly post for data, wp should be doing that as well since I did most of it through wp functions.
thanks for responding. Yeah based on what you are saying this is exactly the issue in the plugin. I’m getting cached data even those database was updated. I presume you don’t clear cache on POST requests thus the issue. Do you explicitly clear cache when update requests are made? If not that’s the culprit – I also saw other people mentioned the same problem. Please confirm. Thank you.
Not sure why thats what you got from what I said. However it does seem wp_cache can be persistent if a plugin for that is installed in the doc: https://developer.wordpress.org/reference/classes/wp_object_cache. I wasn’t aware of it. Could you try adding
add_action( 'wp_loaded', function(){
wp_cache_flush();
} );
somewhere to test?
yes, I already tested this before. When I cleared the cache everything with PageRestrict got back to normal. For the time being I disabled the cache completely.
Yes but I want to be sure which cache. Is it the redis one you mentioned?
Hi, yes, I am using a caching system provided by my host. Specifically:
Nginx FastCGI Cache – however, this is completely bypassed for logged-in users, so it shouldn’t be the issue here.
Redis Object Cache – this is where the problem seems to lie.
My hosting support performed a deep dive and confirmed that your plugin’s checks are being “frozen” in the Object Cache. When a user buys a product, the database is updated, but the query results stored in Redis still return the “old” restricted status for that user.
The issue is resolved only when I manually flush the Object Cache (Redis).
Could you check if the plugin uses get_user_meta or other functions that might be cached by Redis without being invalidated when a WooCommerce order is completed? Or perhaps you could suggest a hook I could use to trigger a cache refresh for the specific user after a successful purchase?
Thanks for checking. I updated caching in my plugin. Should be working now. Please update to 1.7.3. Hopefully this’ll solve it, this seems to be the most likely issue.
