Skip to:
Content

BuddyPress.org

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


Ignore:
Timestamp:
11/02/2014 04:44:18 PM (6 years ago)
Author:
johnjamesjacoby
Comment:

Legend:

Unmodified
Added
Removed
Modified
  • Ticket #5733, comment 14

    initial v1  
    1010An 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.
    1111
    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()`.
     12Conversely 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()`.
    1313
    1414Still 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.