Automattic / wp-memcached

Memcached Object Cache for WordPress.
https://wordpress.org/plugins/memcached/
GNU General Public License v2.0
157 stars 55 forks source link

Automatically Disable object-cache.php on Core Update #158

Open webd-uk opened 5 months ago

webd-uk commented 5 months ago

We found with the latest WordPress v6.5 update that when updating core, it is not just necessary to rename or delete object-cache.php but also to then flush the cache before re-enabling object-cache.php.

If this doesn't happen, when you try to access the dashboard, the site tries to update the WordPress database but displays a notice to say it's already been updated and directs the user to the home page rather than the dashboard preventing access to the dashboard until object-cache.php has been disabled or the cache has been flushed.

Is there a way to automatically disable object-cache.php when a core update is in progress then flush the cache and re-enable object-cache.php when the update is successful?

I feel like this may also be required when performing plugin updates or even theme updates?

This issue probably presented on previous core updates but we're new to Memcached.

Oliver

webd-uk commented 4 months ago

We have successfully resolved this issue with the following ...

add_action('upgrader_post_install', 'memcached_upgrader_post_install', 10, 3);

function memcached_upgrader_post_install($response, $hook_extra, $result) {

         if (wp_using_ext_object_cache() && method_exists('Memcache','addServer')) {

                  $memcache_obj = new Memcache;
                  $memcache_obj->addServer('127.0.0.1', '11211');
                  $memcache_obj->flush();

        }

}
dd32 commented 2 months ago

This isn't a change that should be needed - WordPress should gracefully handle the object cache being enabled during upgrades. Infact, not only should it not be needed, but the action suggested above reads like it would cause this exact problem.

What's likely happening is that the object cache is caching old alloptions data, likely from DB replication lag (if you have multiple DB servers) or different versions of code setting the same cache key.

This sounds typically like one of:

I realise this isn't helpful to provide a solution for you, but the report is of something that I know has plagued object caches in the past, and has mostly been resolved, and is not something that I'm aware of many still encountering.