Main plugin features #11
Conversation
| WP_Post::class => update_post_meta( $this->parent->ID, static::META_KEY, $keys ), | ||
| WP_Term::class => update_term_meta( $this->parent->term_id, static::META_KEY, $keys ), |
There was a problem hiding this comment.
The use of a single array of keys is still, I think, subject to the race condition that you and Boynes discussed in Slack. However, using the metadata API allows for a possible workaround: for each key, store a separate meta row. That way, concurrent requests would write to their own rows, not the same row? I haven't played that all the way out in my head, so maybe it's a dead end.
There was a problem hiding this comment.
I've thought this through and I think I grasp the idea here but I don't know (right now) how to implement it. I split out ticket #14 to investigate it further.
Co-authored-by: David Herrera <[email protected]>
|
@dlh01 thank you very much for taking a deep dive here. your feedback really helped push this to be a better plugin than it was. I really like the improvements made here |
Adds a cache collector that stores key/group pairs that can be purged altogether.
One use case is storing all the places where a post is used. When that post is updated, the cache collector can purge all the caches the post is used in instead of having to add a manual call to
clean_post_cache.Update 11/16
This was refactored after feedback from @mboynes to not be driven by options but rather store the cache collection's keys on the post/term itself. When a cache collection is registered for a term/post it will store the collection as meta on the post itself which can then be used for purging.