Many sites employ a content staging workflow where nodes are initially saved as unpublished then reviewed or frequently updated until they are released. For some sites there could be 10-20 users working in parallel on unpublished content (we see this a lot in company blogs).

Expire currently triggers an expiration for any node creation, update, or deletion, even though for some sites, the nodes that are most frequently being updated are not accessible to anonymous users.

This patch makes the following changes:

  1. Only trigger expiration on insert/delete if anonymous user has view permission for the node
  2. Only trigger expiration on update if anonymous user now has view permission, or view permissions for anonymous have changed
  3. If the node_access table is being used, we have no choice but to expire regardless (since node_access is built after the hooks are invoked).
Support from Acquia helps fund testing for Drupal Acquia logo

Comments

christophersmith262’s picture

Spleshka’s picture

Status: Needs review » Postponed

Thanks for you patch, but actually I don't think we should commit it. Let me try to explan the reason.

Cache Expiration module is designed to flush caches for all possible cases. And the fact that anonymous users can't see a node shouldn't stop us from expiring a node, because other modules (like Authcache, Cache Expiration for Panels, etc.) implement expiration API which depends on execution of expiration callback. So your idea is good, but not acceptable to due complex dependencies by other modules.

Prorably, we could make a step forward and only stop expiration of cached pages for anonymous. Nevertheless I believe that we will have more performance issues with access check rather than with expiring URLs which don't exist in a cache storage.

christophersmith262’s picture

That makes sense, especially the part about 'authcache'. I didn't think of that, but it is a very valid point.

To clarify though, I am not trying to solve the issue of purging things that aren't in the cache, which for most caching back ends seems like it should have low overhead. The (simplified) scenario I am trying to avoid is:

  1. On my <front> page there is a listing of published blogs
  2. When a user creates or edits a blog I use the Cache Expiration module to clear <front>
  3. A user with content creation permission creates or edits an unpublished blog.
  4. This results in the <front> page cache being cleared, even though there will be no content change

Again, I think it makes sense to maintain broad support for different caching strategies, just wanted to clarify what the issue was.

Spleshka’s picture

From my point it looks like you just want a simple workaround. It can be easily done if you implement hook_expire_cache_alter() in your custom module: it provides a node that is being saved and a list of urls to expire. What you need to do, is just to unset that list with urls - and no expirations with be triggered.

christophersmith262’s picture

Well, that was obvious.

Thanks for looking into that.

Spleshka’s picture

Status: Postponed » Closed (works as designed)

Welcome. I am closing this issue, because this FR will not be commited into the module.