CUNY Academic Commons

A cache flush seems to have fixed the issue. Can you please confirm?

Ray, I seem to have a recollection of something similar (broken sitewide setting that was fixed by flushing the cache - it was the value of "1" that made me suspect it was a non-integer being cast to a number) but my Redmine searches are turning up nothing. Do you remember something like that?

Yes, it is working for me now. Thanks.

I have confirmation this is fine now.

Ray, if you have any thoughts about this, please follow up.

I missed the initial reply to this, Boone. Apologies!

Ray, I seem to have a recollection of something similar (broken sitewide setting that was fixed by flushing the cache - it was the value of "1" that made me suspect it was a non-integer being cast to a number) but my Redmine searches are turning up nothing. Do you remember something like that?

I just did some searching on Redmine and #9974 is the ticket that comes close to what you were mentioning. Hopefully, it isn't a reoccurrence of that issue!

I was re-reading #9974 and it linked to this WordPress core ticket:
https://core.trac.wordpress.org/ticket/31245

In WP 5.3.1, a change was made to the alloptions cache so it is purged more often:
https://core.trac.wordpress.org/ticket/31245#comment:92

This might have had an effect on the alloptions cache, but it sounds like that should have improved the invalidation of the cache though...

I also looked at the latest version of our memcached-hm object-cache plugin and a few changes have been made since our last update:

================================================================================
Lines modified at 175
================================================================================
-     global $wp_object_cache;
+     return true;
================================================================================
Lines deleted at 176
================================================================================
-     if ( method_exists( $wp_object_cache, 'quit' ) ) {
-         $wp_object_cache->quit();
-     }
================================================================================
Lines modified at 287
================================================================================
-     $caller = array_shift( debug_backtrace( DEBUG_BACKTRACE_IGNORE_ARGS, 1 ) );
+     $backtrace = debug_backtrace( DEBUG_BACKTRACE_IGNORE_ARGS, 1 );
-     if ( ! defined( 'WP_CLI' ) || ! WP_CLI ) {
+     $caller    = array_shift( $backtrace );
-         //trigger_error( sprintf( 'wp_cache_flush() is only allowed via WP CLI. Called in %s line %d', $caller['file'], $caller['line'] ), E_USER_WARNING );
+     if ( 'cli' !== php_sapi_name() ) {
-         //return false;
+         trigger_error( sprintf( 'wp_cache_flush() is only allowed via WP CLI. Called in %s line %d', $caller['file'], $caller['line'] ), E_USER_WARNING );
================================================================================
Lines added at 291
================================================================================
+         return false;
================================================================================
Lines modified at 746
================================================================================
-     $wp_object_cache = new WP_Object_Cache( getmypid() );
+     $wp_object_cache = new WP_Object_Cache();
================================================================================
Lines modified at 1319
================================================================================
-             if ( isset( $this->cache[$derived_key] ) ) {
+             if ( isset( $this->cache[$derived_key] ) && ! $force ) {

I think the main change is the last one at line 1319:
https://github.com/humanmade/wordpress-pecl-memcached-object-cache/pull/10

We also customized how wp_cache_flush() works from Human Made's version by continuing to allow its usage outside of WP-CLI:
https://redmine.gc.cuny.edu/issues/9974#note-19

So we'll want to comment out their additions to wp_cache_flush() as well.

Also about our addition on line 746 - getmypid() - I'm not sure if we need this anymore.

Thanks for the pointer to #9974, Ray. That is the one I was thinking of, and yes, this unfortunately feels like a similar issue.

The upstream changes don't seem significant enough to port over at the moment - as you note, the main functional change is related to force. In any case, it doesn't seem like the handling of alloptions has changed.

I guess I'm OK adopting a wait-and-see position here. If this or a similar problem arises in the near future, we'll have to go back to the debugging techniques used in #9974 to verify that this is indeed a case of cache pollution. And if it is, we'll have to see whether it is related specifically to alloptions. In the meantime, I feel like there's not much more we can do.