I use Boost on my site, and I have seen a strange issue. I have a view with a pager which consists of a listing of nodes. When I update the status of one of the nodes to unpublished, all cached pages of the view are removed, which is the expected behaviour. This is also to be seen from the watchdog:

Debug: boost_expire_node() <br />Node 67 was flushed resulting in 3 pages being expired from the cache

Then I access each of the pages in the pager and the cache is recreated for each of them. After that I change the status of the node in question to published again and, the cached pages unfortunately do not get removed from the cache directory. 

Debug: boost_expire_node() <br />Node 67 was flushed resulting in 0 pages being expired from the cache
CommentFileSizeAuthor
#12 boost-743992.patch2.81 KBmikeytown2
#11 boost.issue_publish_on_update.patch1.21 KBkoenvi
#5 boost-743992.patch2.97 KBmikeytown2

Comments

egd’s picture

egd commented

I guess the problem comes from the fact that boost_cache_get_node_relationships() searches for the node in the boost_* tables, where the node is _not_ to be found in the second case. Shouldn't we look for it in the original views datasets?

mikeytown2’s picture

mikeytown2 commented
Title: Inconsistent handling when updating the status of a node » Inconsistent handling when updating the status of a node. Cached view - published/not published node

Shouldn't we look for it in the original views datasets?

Boost only does this when a node is inserted; for most use cases, this is ok since the node gets published when it gets submitted. Looks like I need to detect if the node went from not published to published & if that happens search all views for that node. If I search every view every time the node gets updated, that could be quite slow, so I should only do it when the published state switches.

Hopefully this can be done in the presave or validate operation of hook_nodeapi()... looking at it validate seems like the winner.

egd’s picture

egd commented

mikeytown2 I am willing to attempt to make the fix. Even though I am not new to programming I am new to Drupal and php. I would appreciate if you give me some more detail about an eventual fix.

I got stuck where I had to find out in which views a particular nid is contained. Any help will be appreciated.

mikeytown2’s picture

mikeytown2 commented

in boost_nodeapi

run this to test if the node is in a view

  if (module_exists('views')) {
    $GLOBALS['_boost_nid'] = $node->nid;
    register_shutdown_function('_boost_view_insert');
  }

You can see an example with case 'insert':.
EDIT: grabbed the wrong example code; now calls the correct function.

I should probably make $GLOBALS['_boost_nid'] be an array since I could see more then 1 node being inserted at a time (feeds).

mikeytown2’s picture

mikeytown2 commented
Status: Active » Needs review
StatusFileSize
new boost-743992.patch2.97 KB

Looking for the difference between whats in the database and the new values could become a nightmare. Taking the easy route on this one. Node saves with this enabled are not as fast as they could be, but it's still pretty quick.

mikeytown2’s picture

mikeytown2 commented
Status: Needs review » Fixed

committed

egd’s picture

egd commented
Status: Fixed » Active

Unfortunately, it still does not work. I reopened the issue.

When the node is published and you un-publish it, all cached pages of the view are deleted. This is OK.

When the node is not published and you publish it the cached pages are not deleted. This is not OK.

I still think that the statement in #1 holds true, and the way you attempted to fix the issue is not right.

mikeytown2’s picture

mikeytown2 commented

Just to be certain did you enable a new setting "Clear all cached views pages associated with a node on update"?

egd’s picture

egd commented

Yes.

mikeytown2’s picture

mikeytown2 commented

are you using feeds for the node?
http://drupal.org/node/779184

koenvi’s picture

koenvi commented
StatusFileSize
new boost.issue_publish_on_update.patch1.21 KB

Hi all,
I had noticed the same issue so I created a small patch to fix this. The patch is pretty simple and only includes 2 changes the boost_nodeapi:

- case 'load': save the old status to the request
- case 'update': check if the status changed from unpublished (0) to published (1). If yes, then execute the same code as for the insert operator

I tested it and it works fine for me.

mikeytown2’s picture

mikeytown2 commented
Status: Active » Needs review
StatusFileSize
new boost-743992.patch2.81 KB

I've come up with some experimental code that detects what parts of the node object has changed. Works ok from what I can tell. Could use this for very smart cache invalidation. Works with CCK & base level node objects; doesn't work with things that are buried deep like nodewords (meta tags) settings. Could use this as a framework where different changes to the node object result in different cache expiration logic.

Code is copy paste hackish; proof of concept at this point. Figuring out what has changed in the node object is not an easy task.

mikeytown2’s picture

mikeytown2 commented
Status: Needs review » Needs work