I noticed an issue with this plugin when activating/deactivation a plugin on my site. It says the plugin has been activated at the top of the admin page, but it still shows as inactive. Have you come across this issue?
I haven’t before. If I were to guess, I think you’re getting a stale cache value from Redis, a cache value where WP Redis isn’t activated. If this is the case, then as soon as WP Redis is activated, then the stale cache value is used and WordPress thinks WP Redis isn’t activated.
However, WP Redis doesn’t currently configure itself on plugin activation. There’s a required configuration step of creating a symlink before the WP Redis can connect to the object cache. As such, I’m confused as to why you’d see this issue just in the action of activating the plugin, and not elsewhere.
Could you describe your WordPress and Redis configurations in greater detail? On the WordPress end, have you or are you running other caching plugins? On the Redis end, can you verify WordPress is permitted to write to Redis? Are there other WordPress installs sharing the same Redis instance?
Hi Daniel,
I probably didn’t describe my issue as clear as I wanted. This is my scenario:
1. WP Redis is active and I just cleared the cache
2. I try to activate a plugin, let’s say Akismet
3. I see a message saying the plugin has been activated, but it is still not active. This is the case no matter how many times I try to activate it.
4. I clear redis cache from command line
5. Plugin is suddenly active
The cache clearing/update should happen automatically, right? The same happens with various site settings. I hope it’s clearer now.
Thanks for the more detailed explanation, Martin.
The cache clearing/update should happen automatically, right?
Yes, it should. I’m not sure why it’s not 🙁
The active_plugins option is a part of the alloptions cache bucket, so that’s the bucket you’d be looking at to try and figure out why it’s not working.
Is this Redis instance being used for multiple installs of WordPress by chance? If so, you’ll need to set a unique WP_CACHE_KEY_SALT in your wp-config.php to make sure the alloptions bucket for site A isn’t colliding with the alloptions bucket for site B.
Hi Daniel, I definitely have a unique WP_CACHE_KEY_SALT on each site using my Redis instance and it is still not working properly. Another one of the side effects is that published posts are missing their schedule. Any idea what else could be wrong? I checked everything I could think of already.
Hi Daniel, I definitely have a unique WP_CACHE_KEY_SALT on each site using my Redis instance and it is still not working properly.
Odd.
Another one of the side effects is that published posts are missing their schedule.
I’m not sure this is related, actually. Published posts missing their schedule is typically a problem with WP Cron.
Any idea what else could be wrong? I checked everything I could think of already.
No ideas, unfortunately :/ If you’re hosted on Pantheon, you could open a ticket with support to see if they can diagnose further.
I have no idea why, but the problem is most likely a conflict with plugin W3 Total Cache. I don’t have object caching enabled in this plugin, but when I deactivate the whole thing, the issues go away.
I already raised a ticket with them:
https://wordpress.org/support/topic/w3tc-conflicting-with-wp-redis?replies=1
Thanks for looking into this, Daniel.
Hi
I am not sure if I should open a new topic? the only difference is I do not use w3tc.
I have updated to Version 0.6.1 and I don’t use any page cache plugins. and WP_CACHE_KEY_SALT is unique.
Still customizer settings and widget setting changes are not getting reflected even though it says that settings have been saved.
Thanks
@pulser1983 Could you share what debugging you’ve done, and any steps to reproduce?
If you think you’ve found a bug in the plugin, feel free to open a GitHub issue with the steps to reproduce. You’ll first need to isolate whether this is a problem with the plugin, or a problem somewhere in the theme / other plugins you’re using.
