wp_count_posts() cache is not destroyed after post inserts and deletions

[mark8barnes]

wp_count_posts() caches its results, but that cache is not destroyed when posts are inserted, deleted, or transitioned. This can lead to incorrect counts.

The attached patch fixes that (although it doesn't destroy the cache set when $perm='readable' in wp_count_posts(), which would be more complex as we wouldn't know the name of the key(s), though it could be done with preg_match).

[nacin]

We don't bother with clearing the caches here because the counts group is a non-persistent group. I wouldn't be surprised if we don't clean caches for anything using the counts group.

[mark8barnes]

Replying to nacin:

We don't bother with clearing the caches here because the counts group is a non-persistent group. I wouldn't be surprised if we don't clean caches for anything using the counts group.

I understand that, but you'll sometimes want to perform a bulk operation and check post counts during the operation (in my case, I was trying to prevent the last of a custom post type from being deleted). In that scenario wp_count_posts() returns incorrect data.

(Another option would be to add a parameter to wp_count_posts() to optionally ignore the cache.)

[wonderboymusic]

This only needs to happen on 'transition_post_status'. 21879.diff​ does this in_transition_post_status().

[wonderboymusic]

After writing some unit tests, turns out this way scarier than I thought. 21879.2.diff​ is the required fix. Gonna let this sit here for a little bit for feedback.

[wonderboymusic]

In 27081:

Properly invalidate the cache for wp_count_posts() on insert, trash, or when transitioning post_status inside of _transition_post_status(). Introduces _count_posts_cache_key(). Adds unit tests.

Props mark8barnes, for bringing this to our attention in an initial patch.
Fixes #21879.