Open mreishus opened 1 year ago
There is a 48 hour WPCOM specific cache for get_adjacent_post() causing this issue; it's not invalidated for adjacent posts while trashing.
Searching around, it seems this function has performance issues, hence the heavy caching.
As far as I can tell, there is no cache invalidation for the get_adjacent_post() function.
The cache was initially added in : p4IuY0-30-p2 and p1YhhO-rV-p2 . Some discussion about invalidation is in there: mostly that it's difficult to solve because of the core design we are wrapping, but setting it to 3 hours was a compromise between performance and correctness, even if invalidation was not solved. Later, this was bumped from 3 hours to 48 hours to solve some performance issues, but invalidation was not addressed.
Patch idea here, but I'm not certain about it: D93982-code
Support References
This comment is automatically generated. Please do not edit it.
Another user reported this in 6061696-zen
I can replicate the same behavior on my test site as well using the following themes:
Quick summary
After trashing or restoring blog posts, the
post-navigation-link
block can still render with outdated cached information when making "<- Previous" or "Next ->" links, as if the trash or restore never happened.This is on WPCOM Simple and could be related to a caching optimization on the platform. I haven't tried on a standalone .org site.
5754652-zd-woothemes
Steps to reproduce
What you expected to happen
n/a
What actually happened
n/a
Browser
No response
Context
No response
Platform (Simple, Atomic, or both?)
Simple
Other notes
No response
Reproducibility
Consistent
Severity
No response
Available workarounds?
Yes, difficult to implement
Workaround details
A workaround can only be used by A11Ns: Use the special query parameter to clear cache, but this may only fix for one datacenter.