Early Bird Registration for DrupalCon Portland 2024 is open! Register by 23:59 PST on 31 March 2024, to get $100 off your ticket.
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:
- Only trigger expiration on insert/delete if anonymous user has view permission for the node
- Only trigger expiration on update if anonymous user now has view permission, or view permissions for anonymous have changed
- 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).
Comment | File | Size | Author |
---|---|---|---|
#1 | expire-node-access-2428893-1.patch | 1.62 KB | christophersmith262 |
Comments
Comment #1
christophersmith262 CreditAttribution: christophersmith262 commentedComment #2
SpleshkaThanks 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.
Comment #3
christophersmith262 CreditAttribution: christophersmith262 commentedThat 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:
Again, I think it makes sense to maintain broad support for different caching strategies, just wanted to clarify what the issue was.
Comment #4
SpleshkaFrom 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.
Comment #5
christophersmith262 CreditAttribution: christophersmith262 commentedWell, that was obvious.
Thanks for looking into that.
Comment #6
SpleshkaWelcome. I am closing this issue, because this FR will not be commited into the module.