Context Navigation

Changes between Initial Version and Version 1 of Ticket #5733, comment 14

initial	v1
10	10	An approach like above makes more sense than our approach with `bp_activity_sitewide_front` for example. That custom front-page cache approach is a fine work-around for not having any caching, but does make the assumption that the front-page of the activity directory is the same for everyone. Once any parameters change, we stop caching queries, which leaves us room for improvement.
11	11
12		Conversely for the `posts` group, it's non-global, and persistent, which seems more accurate for our components and their objects and queries. There are helper functions for building cache keys (similar to my proposal above) and objects are expected to be cached and deleted rather frequently, up to and including functions like `wp_insert_post()` that delete the new post`s cache and then immediately prime the cache with a call to `get_post()`.
	12	Conversely for the `posts` group, it's non-global, and persistent, which seems more accurate for our components and their objects and queries. There are helper functions for building cache keys (similar to my proposal above) and objects are expected to be cached and deleted rather frequently, up to and including functions like `wp_insert_post()` that delete the new post's cache and then immediately prime the cache with a call to `get_post()`.
13	13
14	14	Still sifting through WordPress's innards, but we've always known there would be pretty enormous performance gains once we get our cache usages correct, and it's nice to reconfirm that.