CUNY Academic Commons

The Litespeed Cache plugin aggressively caches pages across the network. It has lots of "purge" (invalidation) events built in. But it's missing many others. It has no built-in support for BuddyPress, and there also appear to be some core WordPress events that don't trigger purges in the way that you might expect.

I've started to make some notes about this, but before going too far down the road of listing a million purge events, I think we need to think more broadly about the structure of such a tool. A good place to start is the "thirdparty" tools that are built into litespeed-cache itself. The nextgen-gallery one is a pretty good example: https://github.com/cuny-academic-commons/cac/blob/f60272caad81b7a328e100d7f936672b9af57ddc/wp-content/plugins/litespeed-cache/thirdparty/nextgengallery.cls.php

The basic idea here is that they define a bunch of purge events (represented by WP hooks), which then trigger invalidation of certain types of elements. Updating an image, for example, calls the 'update_image' method; that method does the following:
- Purges the associated gallery cache
- Purges the cache of galleries associated with the "task list" (don't know what that is, but you get the idea)
- Purges the cache of the specific image

It looks like the method used by litespeed-cache to associated WP objects with cache entries is "tags". The nextgen-gallery extension uses a couple of tag "namespaces" (for albums, galleries, tags), and then appends specific item IDs to make unique cache keys. They then use the 'litespeed_tag_add' action (see the add_container() method) to report the tags to litespeed at the time of render (ie, when it's built and sent to the cache). Then, for purging, the 'litespeed_purge' hook is fired, passing along the same tags.

BP objects will probably be organized similarly. 'groups' and 'users' is likely granular enough. Then, for each, we need to identify:
- The specific render points where we need to report the tag to litespeed. I guess this might be anytime we load a page where bp_is_user() or bp_is_group(), but it may be that we need to be broader than that. This is pretty hard.
- The specific purge events. This is pretty easy.

We also need to be concerned with a few types of "global" purge. The home page and top-level directories need to be purged when certain aspects of individual items are updated. New members/groups, and changes to certain directory info (display names, maybe associated campus etc), should probably trigger immediate purges of these global items. last_activity should probably purge too, so that the various "recently active" areas make sense, though this could probably be throttled.

Then, aside from the BP stuff, we'll need a number of one-offs for areas where litespeed-cache doesn't work right with general WP. So far we've found the following:
- Changes to Settings > Reading, like page_for_posts #21826
- Changes to menus, perhaps also widgets. #21832

We'll probably run into others, especially related to unsupported plugins, but we'll have to either handle these individually, or just have a mechanism for site owners to press their own "clear cache" button.

Ray and Jeremy, I hope you'll chime in with thoughts on this outline. Suggestions, corrections, or prior art would be especially welcome. In the next week or two, one of us can start working on a framework for all this. Once it's in place, we can all contribute to the long-tail of specific invalidation events.