Jamie Perrelet

Nearly a year old, bug persists.

Hi, we’re paying literally thousands of dollars a year for AC and your software is causing a fatal error.

We would appreciate hearing from you.

Thank you.

Hi @tillkruess,

Thank you for your swift input.

#1 Load Order

You’ll need to be very careful with using filters, because the object cache boots before even muplugins_loaded is called, so your filter registration might not have run by the time the cache starts.

Yes this makes sense, object-cache.php is loaded very early in the cycle. For this particular use case we have in mind, this wouldn’t be an issue. For background, we’ve written a framework that provides handling of core wp entities via an object orientated interface. e.g:

$post = new Post();
$post->set_title("Hello World");

When our new post’s setter methods are called, we need to run wp_cache_set(..) to ensure the underlying WP_Post object holds the new title. Unless $post->save() is called at some later point, this really shouldn’t be persistently stored however.

#2 Hook Performance

Calling redis_cache_skip_persistent_cache for each key can be a big performance hit. This would need to be a static check once to only apply the filter when something is registered.

Right, I wondered if this might be an objection. Perhaps you wouldn’t mind expanding a little further on this point? In particular, given that WP_Object_Cache already fires various hooks (such as redis_cache_expiration, redis_object_cache_get and redis_object_cache_get_value) on every call – how might adding this hook constitute a big performance hit comparative to the existing hooks?

Thanks again for your time on this Till.

Thanks @daveykj, I think you nailed it 👍

@acteamintegrations this is a show-stopper, please acknowledge & reply.

Finally, this bug likely relates to: https://ww.wp.xz.cn/support/topic/multiple-issues-pdfs-buddypress-messages

This appears to be a byproduct of wordpress using table-layout: fixed on its admin tables and limited screen size.

marking as resolved.