WP Redis should be clearing the cache for you automatically, when you use update_option().
Any ideas why it might not be? Could you describe your environment and the code you’re running in greater detail? And, just to confirm, you’re using WP-Redis v0.3.0?
Hi,
yes, i am using v0.3.0. It’s pretty simple… it’s a code than run post-creation of a new multisite, register a new DNS zone and bind it to WordPress. It works pretty well, besides the options I am trying to set.
Here’s the code : http://pastebin.com/q51Twp9Q
It’s called as a “semi-cron” using lynx -dump http://pathtofile.php
My setup is nginx+hhvm+mariadb+w3totalcache+redis.
I don’t know if there’s a way to clear the cache for a particular multisite with WP-Redis.
Or just a set of tables like wp_999999_*
But it would definitely work and at a very minimal cost performance wise since it’s a brand new site anyway. I just don’t want to clear the whole cache.
I don’t know if there’s a way to clear the cache for a particular multisite with WP-Redis.
Because you’re running multisite and calling switch_to_blog(), I think what’s going on is that $wp_object_cache isn’t being properly set for the blog you’re working on. Your update_option() call manages to write to the correct blog table, but doesn’t update the object cache value for the blog.
Or, another hypothesis is that, because of the way you’re loading WordPress on cron, the WP Redis object cache drop-in isn’t properly loaded when the script runs. This would mean it would load an incorrect value from the persistent object cache on subsequent web views (until that cache is updated)
I don’t know if there’s a way to clear the cache for a particular multisite with WP-Redis.
The bug is that the cache isn’t updated automatically when it should be. You could find a workaround but, unless you fix the bug, you can’t be certain the bug doesn’t cause other problems too.
Just to make sure, you have define( 'MULTISITE', true ); in your wp-config.php, right?
It’s called as a “semi-cron” using lynx -dump http://pathtofile.php
As an aside, instead of calling require_once 'wp-config.php', you might instead consider using WP-CLI. It’s a much more robust framework for working with WordPress on the command line.
Sorry I couldn’t be more conclusive. I can’t reproduce the issue in my testing, and would need access to the issue at hand to properly debug. Hopefully these pointers help take you in the right direction.
Hi Daniel,
while I am on MULTISITE, I didn’t have the define set. I created my Multisite before WP-MU merged with standard WordPress so I guess I had some legacy settings that hold everything together regardless.
I decided this morning to set it up the new way and it’s been a mess (a total $#!$ mess) but now (4 hours later) everything is working fine. It also does seem a little faster so maybe your plugin is liking it.
Thanks a lot.
Ah! That was the problem then too 🙂 Glad we’ve sorted it out.
