Posted by Tim Cullen on October 30, 2008 at 2:23pm
Jump to:
| Project: | Boost |
| Version: | 5.x-1.x-dev |
| Component: | Caching logic |
| Category: | feature request |
| Priority: | normal |
| Assigned: | Tim Cullen |
| Status: | closed (fixed) |
Issue Summary
The Nodequeue module allows users to manually create and displays queues of nodes. These queues can be shown on both pages and blocks.
These queues can change when users re-order them, alter the number of nodes in them, and add or remove nodes from them.
Much like the approach to making Boost Views-aware (http://drupal.org/node/328126), the addition of a submit hook to of the queue form via hook_form_alter will probably be the simplest path to expiring the cached versions of affected paged.
Comments
#1
Hmmm. Seems like boost should actually ship with a cache.inc implementation so we can listen to all cache_clear_all() and do expire as needed. But thats a lot of code that has nothing to do with boost (e.g. filter cache, block cache, etc). It would be nice to listen for clears of cache_page in particular. Something for D7, I guess.
Until then, this is needed. I would think though that Arto will want to keep this out of boost proper. Maybe if this logic is in own .inc file (same for your Views issue).
#2
Agreed about the idea for a more intelligent interworking with the various caches being in the roadmap.
Agreed also that this (and the views work) shouldn't live in boost proper--and am coding as such.
I hope to have a first pass at this and the views patch by 11/06/08.
One thing I am seeing as I code this: dealing with blocks could be quite costly where visibility is set to "visible on all pages except." Essentially I'm having to recreate boost_cache_expire_all() but checking each static cache file against the paths on which the block is not displayed. This won't scale. For now, I'm considering making this a setting, something along the lines of "Aggressive nodequeue block freshness" or something. Either way, this block-driven cache expiration logic will be the same for both views-driven blocks and nodequeue-driven blocks. Any thoughts on where that code ought to live (in the 5x branch at least)?
#3
Closing all 5.x issues; will only reevaluate if someone steps up #454652: Looking for a co-maintainer - 5.x
Reason is 6.x has 10x as many users as 5.x; also last 5.x dev was over a year ago. The 5.x issue queue needs to go.