No update required loop

Try flushing you Redis database.

I tried to fix this a couple of times but the WordPress architecture makes it hard.

How? I can’t access any option on the plugin…

Try using the redis-cli or a desktop client like Medis.

Could this be the problem? Every problem with object cache I had (with memcached) disappeared after this modification.

WPEngine actually forces memcached object cache so it must be possible to stop these loops and other random issues with a redis object cache class. I do not get them with the modified memcached plugin (where i changed the functions from private to public).

The only private property is $redis right now and unless you can show me where WordPress is accessing that property directly changing it from private to public won’t do anything.

In v1.3.4 I tried to fix this weird caching issue for over a day but I couldn’t get the plugin to flush the Redis database when activating, deactivating and uninstalling the plugin, because the WordPress architecture is from the middle ages.

It is just my hunch since all of my past problems with object cache were fixed when modifying memcached.

Perhaps the object-cache class needs to be updated or a PR for WordPress core to be friendlier to external object cache daemons?

Out of curiosity were you doing cache flush and deleting transients in your tests?

@hmseb: I’ve added a couple of notes on how to flush your Redis server directly: https://www.ads-software.com/support/topic/read-this-before-you-post-24/

@tillkruess suggestion about that thread, move 2 ‘2. If you’re experiencing a compatibility issue with another 3rd-party plugin, please contact the author of the other plugin regarding the issue. This plugin is **very unlikely** to be the cause of the issue.’

after 5. ‘5. Most issues can be solved by flushing the Redis database. You can do that through a desktop client like Medis or Redis Desktop Manager, or alternatively by calling redis-cli flushall.’

It makes more troubleshooting sense as the user will read the items in order. With this order the user will then have read that if they have issues to flush the cache first, then if that fails to contact the developer. Having the ‘contact developer of the other plugin’ so early on will likely generate unnecessary support requests.

Hey @tillkruess can you tell me what you tried to work around this error. I just saw it happen with memcached as well and will be hiring someone to try and fix it. If I can have them skip what you already tried it will save some time and if I get a solution I will pass it on to you.

I’d try flushing the cache immediately after activating, before deactivating/uninstalling. You can’t rely on the WP_Object_Cache object, because that won’t be available until the next request, so I’d write a small standalone “connect & flush” method.

@blindpet did you solve this?

@tillkruess I did not but my ideas were these, happy to help test if you like

use symlinks and unlink when update occurs
delete transients
wp cache flush (I believe you already tried this)

Two different sites and in both cases “redis-cli flushall” saved the day.