You could try calling wp_cache_add_non_persistent_groups() and mentioning the name of the group to refrain from caching. https://developer.wordpress.org/reference/functions/wp_cache_add_non_persistent_groups/
This is probably a bug in that other plugin.
Thank you for taking the time to provide a solution. I don’t think this solution is working for me. I tried:
function add_non_persistent_groups() {
wp_cache_add_non_persistent_groups(array('wpum_field_meta', 'user_meta'));
}
add_action('init', 'add_non_persistent_groups');
(Added the two groups I could see that involve user fields and that SQLite Object Cache is caching.)
You may be right. It could be a plugin bug. It’s WP User Manager. I can ask that plugin author what they think.
This might defeat the purpose of using this plugin, but, could I add a function that completely clears the SQLite Object Cache every so many hours? I know this is likely possible, I’m just wondering if you instantly know how to do this to save me some time, to be honest.
Because in the end, bug or not, flushing the SQLite Object Cache fixes it. Until the next profile edit. Hmm 🤔 … I just thought that it would be interesting if the user meta group cache was cleared on profile save.
I’ll take a look at that plugin when I get a chance.
wp_cache_flush() wipes the cache. You could try …
- Set up a shutdown action handler in an admin_init action handler.
- From the shutdown handler call wp_cache_flush(). This will cause the cache to be cleared at the end of any admin function.
But, i gotta say, that sounds like a kludge on top of a hack. This is weird.
I wonder if the same problem occurs with the redis persistent object cache plugin?
Weird. Thanks for letting me know about this.
For now, even though it’s hacky, I’m going with this so I can still use your plugin and all profile fields update. Maybe only profile_update is needed. But, what’s a couple other flushes at this point. 🤷♂️
function flush_cache_on_user_change( $user_id ) {
wp_cache_flush();
}
// Flush on user profile update.
add_action( 'profile_update', 'flush_cache_on_user_change', 10, 1 );
// Flush on new user registration.
add_action( 'user_register', 'flush_cache_on_user_change', 10, 1 );
// Flush on user deletion.
add_action( 'delete_user', 'flush_cache_on_user_change', 10, 1 );
Looks good to me.
Double-check that the actions you hook happen at the END of the update operations. I guess the plugin is writing usermeta data directly to the data base with SQL, bypassing the usermeta cache. You Can’t Do That.(tm)
So other things that DO use it get stale data …. but only if the cache persists. I think that is consistent f with the failure you saw. Right?
We’ll soon know if my guess is correct.
That’s a complex plugin! and full of direct use of the wp_cache subsystem. It’s going to take some debugging.
It would be helpful if you could give me some steps to reproduce the problem you have. Thanks!
Take your time. I could be the only person with the problem. And, at least I have a solution for now (the cache purge on profile update code). This plugin speeds up my site so much that it’s still worth it even if I have to have a permanent hack.
To reproduce, ensure you have a frontend profile. Edit the bio/description in the profile. Save. Go and view the frontend profile. Try with your plugin and without.
