Boost ability to invalidate/clear cache for single items based on event handler hooks like hook_node_update()

Subscribe. I've noticed similar problems from time to time on a couple sites I'm running.

Same issue

I'm currently playing around with cache actions (http://drupal.org/project/cache_actions), the preliminary results are promising! Comments showing up immediately without clearing the entire site cache ...

Subscribe

subscribe

With "cache actions" one can successfully work around the caching logic. Just create a rule that is triggered by comment save, then add the following actions:
"Clear a specific cache cid" - Parameter: Cache bin: cache_page, Cache key: [comment:cid], Use wildcard: true
"Clear the cache for specific views" - Parameter: Views: comments_recent
"Clear the cache for views displays" - Parameter: Displays: block
"Clear cache bins" - Parameter: Cache Bins: cache_page

This clears just the necessary caches and comments show up immediately. One can do the same thing for pretty much any other type of content. But, of course, it would still be nice to see this kind of behaviour as a standard option within boost! :-)

Further question: Using Logintoboggan (but, alas, this also applies to standard login), I experience two weird kinds of behaviour related to boost caching:

1. When not logging in from the frontpage but from any other page of the site, quite often (especially the page cache is fresh) the user is not logged in immediatley but only after one further click. It looks like the login_linger-issue that was reported and solved for the D6 version: http://drupal.org/node/677722

2. Same goes for new user registration. When a user registers, his/her registration is bein processed, but due to caching the confirmation message turns not up immediately on the next screen but after one further click. Sometimes, this message is written into the boost cache, resulting in being shown to all anonymous users. Any ideas?

Thanks in advance! Help would be much appreciated!

Thorsten: Great idea, but I don't find it working as described.

The following action has no effect:
"Clear a specific cache cid" - Parameter: Cache bin: cache_page, Cache key: [comment:cid], Use wildcard: true

While this action works. However, it clears the cache of ALL pages, not just the one the comment was on.
"Clear cache bins" - Parameter: Cache Bins: cache_page

Hey Olof, thanks for the input, I've been playing around with a couple of options where each seemed to help alleviate this or the other side effect of publishing / login problems. Being frank, sometimes I'm not even sure why one option or the other seemed to make a difference - some might have been dependent on my setup. But I wanted to share my preliminary results anyway, as it seemed I wasn't the only person to struggle a bit there ...

Especially the invalidation that's concerning login is hard to get right at the moment ... so I decided to give boost a little more time to mature for D7/8, there's really good things coming ahead - I'm really excited about the idea of seeing Boost as a core module in D8 with advanced "extra logic" in core to make correct invalidation happen: http://groups.drupal.org/node/75823#comment-236403

In the meantime, I'm using a combination of HeadJS, Entity Cache and Block Cache Alter for a change.

I ran into this problem myself. I have used Boost with D6 a fair bit and am finding that the current D7 version is fairly stripped down in comparison.

The current D7 Boost version does not appear to do flushing based on saved or updated items like the D6 version did. The only flushing that occurs is in boost_flush_caches() and based on the invalidation time set in the config via boost_cron(). If we want flushing for comment saves, etc, it looks like it needs to be done manually right now.

Also, as Boost must remove the cached files on any flush, I don't see how cache_actions suggested above is going to help unless it will call hook_flush_caches() and flush everything.

To solve the problem for me, I will probably implement hook_comment_insert(), etc, and just call boost_flush_caches() directly. Not a good solution as everything goes, but it looks like this is as good as it gets for now.

Here is an approach that delete's the cached file on node and comment changes. If this is a desireable patch, I can clean it up and build it against 7.x-1.x-dev.

/**
 * Implements hook_node_update().
 */
function boost_node_update($node) {
  boost_invalidate_node_cache($node);
}

/**
 * Implements hook_node_delete().
 */
function boost_node_delete($node) {
  boost_invalidate_node_cache($node);
}

/**
 * Implements hook_comment_delete().
 */
function boost_comment_delete($comment) {
  boost_invalidate_node_cache($comment->nid);
}

/**
 * Implements hook_comment_insert().
 */
function boost_comment_insert($comment) {
  boost_invalidate_node_cache($comment->nid);
}

/**
 * Implements hook_comment_update().
 */
function boost_comment_update($comment) {
  boost_invalidate_node_cache($comment->nid);
}


function boost_invalidate_node_cache($node) {
  if (!is_object($node)) {
    $node = node_load($node);
  }
  $path = isset($node->path['alias']) ?  $node->path['alias'] : $node->path['source'];
  boost_invalidate_cache($path);
}

/**
 * remove cached file
 *
 * @param string path to item such as about/us or node/16
 */
function boost_invalidate_cache($path) {

  global $base_root;
  $full_url = $base_root . '/' .  $path;
  $url = boost_transform_url($full_url);
  $delete_path = $url['filename'] . '.' . variable_get('boost_extension_text/html', 'html');
  unlink($delete_path);

}

I think this is a feature request since its not implemented.

@johnbarclay - There's a module for that (forgot to mention it earlier in this thread...):

Boost Expire

See: #1069438: How to Flush Boost Cache in Drupal 7.x
and module expire

I looked at 2 modules:

boost_expire: flushes entire cache so isn't useful for large content, relatively low traffic sites.
expire: doesn't integrate with boost. #1592774: Compatibility with Boost

I have a large site with thousands of nodes. The ideal scenario is to have a long cache length (24 hours or so) and cache invalidation based on node edit/update/delete per node. Short of that the boost module wouldn't have any value except for the top 20 or so pages.

Looks like integrating expire with boost is the way to go. Any thoughts on if and how I should pursue that?

Thanks. Handy module.

Here's an implementation of the hook_expire_cache() to make boost work with the expire module.

Please test/review.

You can get more verbose info by enabling the boost debug mode (for the lazy: "drush vset boost_message_debug 1").

I tested this patch. My use case is when a page is updated by a editor it should be flushed/purged/expired from cache so not only the logged in editor but also the anonymous users directly can see the changes on the site. This site is on a shared webhost where I use Boost to speed it up and also have all caching activated under Performance.

I got this working by applying the patch from http://drupal.org/node/1126122#comment-6219588 to the Boost module. Installed Cache Expiration (http://drupal.org/project/expire) and Rules (http://drupal.org/project/rules) and the by Rules required Entity API and Entity Tokens. Activated Rules UI and created a rule with Event: "After updating existing content", Action: "Clear URL(s) from the page cache." with Value: [node:url].

Now when updating a page it's removed from Boost cache and when I look in the database the full table "cache_page" in the database is cleared. In the Recent log messages (/admin/reports/dblog) Expire reports, for example when the setting for Expire menus is set to No: "Node 16 was flushed resulting in 2 pages being expired from the cache", witch I see in the array is the url-alias and the node/id.

One thing is a bit strange, when I activate "Send debug info for each request to watchdog." this patch seems to break the Recent log messages (/admin/reports/dblog) with a Unexpected Error. Checking with drush watchdog-show I see

Recoverable fatal error: Argument 2 passed to t() must be an array, integer given, called in                      
               /Users/x/Sites/dev/modules/dblog/dblog.admin.inc on line 265 and defined in t() (line 1478 of 
               /Users/x/Sites/dev/includes/bootstrap.inc).

@ acke: is it really necessary to configure Rules to flush the cache, when using Expire?

About the watchdog (recent log messages), there was indeed a bug in the patch. Thanks for spotting it. It has been fixed in the latest dev: http://drupalcode.org/project/boost.git/commitdiff/e626738?hp=5f67308278...

You will need to flush your watchdog in order to be able to view the dblog (echo "truncate watchdog" | drush sqlc).

after reading this and all the other threads dealing with expiration on update, i'm confused.
i saw that the code in the patch above has been added to the boost.module in the version i'm using (7.x-1.x-dev Aug 17) but i'm not seeing any pages get deleted from the cache when updated.

do i still need the expire module? is the rules module required? does this have to do with the Minimum cache lifetime i have set on the performance page? what is the difference in the boost settings between the minimum and maximum cache lifetime compared to that same setting on the drupal core performance page?

any help on how to properly set up boost so that pages are flushed from cache when they are updated (and only those pages, not the entire cache) would be appreciated.
Thanks!

@chadd: you need to install the 'expire' module. The expiration code from 6.x-1.x was forked out of Boost in order to make a more re-usable module (expiry) that could work with different types of caches (ex: varnish).

The patch from #15 was committed to 7.x-1.x.

@bgm: thanks. so is the rules module required as well? i can't seem to find any documentation on how to correctly set up expire...

@chadd: I don't think you need rules, just enabling the "expire" module should work. Please test and provide feedback :)

i've installed and enabled http://drupal.org/project/expire , but no matter what combination of [Boost maximum cache lifetime], [Drupal Minimum cache lifetime], or [Ignore a cache flush command] checkbox settings i try, i either get no pages flushed from the cache or all pages get flushed, and only after cron runs.

what i'm shooting for is the functionality in boost 6.x that flushed just that one node from the boost cache when the node was updated. any ideas or help on how to set up the config settings to get it to work like that? #16 above seems to have got it close to working like that, but they are using rules, which bgm has said in #21 shouldn't be needed...

also whenever i save a page, i get a large amount of these notices:

Notice: Undefined variable: structure in expire_get_menu_structure() (line 374 of /Web/dev2/WWWRoot/sites/all/modules/expire/expire.module).
Notice: Undefined variable: sub in expire_get_menu_structure() (line 347 of /Web/dev2/WWWRoot/sites/all/modules/expire/expire.module).

setting the menu expire to 'none' in the expire settings gets rid of that error.

using (and slightly modifying) the code from #10, i've managed to hack the boost.module file to remove the individual cached .html file on page update or page delete. no other module is needed.

That module clears the entire Boost cache when updating a single file. Direct integration with http://drupal.org/project/expire would be more welcome :)

Boost Expire was not created to be a full-fledged solution for Boost page cache expiration—only a temporary stopgap. This issue should remain open until Expire module integration is added (I haven't heard anything about whether that's coming soon or not, though).

I'm going to still try to improve Boost Expire here and there when I can, but currently, it just flushes the entire boost cache after certain actions.

I'm confused by this thread, please correct me if I'm wrong:

* boost integrates with expire directly, you do not need boost_expire.
* "expire" detects common use-cases where specific pages should be invalidated (node edit, new comment posted, etc), so that boost only expires those pages. The boost integration hooks into that and deletes the appropriate pages from the cache.

Philip_Clarke mentioned in #26 possible UI improvements. They have been committed to 7.x-1.x since.

I'll close this issue, since the code that was for review has since been committed (expire integration). If you have any issues with it, please open a separate support request.

I wasn't aware the integration was completed; shall I mark Boost Expire as deprecated, then? I'll post one last update that recommends switching to Expire module in hook_requirements.

After reading this thread I'm still wondering how to effectively expire the boost cache ... can someone direct me to a well supported approach using boost? The expire module does not seem to support boost.

Phillip I think you captured it perfectly. There is a lot of ambiguity in terms of what is supported and what is needed. I think you laid out all of the major use cases. I'm interested in a few pages and rest automatically on node changes.