Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

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

Open
webd-uk opened this issue Apr 5, 2024 · 2 comments
Open

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

webd-uk opened this issue Apr 5, 2024 · 2 comments

Comments

@webd-uk
Copy link

webd-uk commented Apr 5, 2024

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
Copy link
Author

webd-uk commented Apr 29, 2024

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
Copy link
Member

dd32 commented Jun 20, 2024

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.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

2 participants