Open webd-uk opened 5 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();
}
}
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.
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-enablingobject-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-enableobject-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