Hi, Remember also modules like organic groups which has no relation to roles. Maybe a caching flag on theme('page'), so the modules can determine tell the system to cache this page for this user, or groups of users. I know that we just return something, so we would need to make the return method to allow the returning of an array which is past to theme('page'); Gordon. John Handelaar wrote:
Dries Buytaert wrote:
Cache by role doesn't work because there are many per-user settings (eg. language preference, the username in the navigation-block, etc).
To be fair, I did *explicitly* mention that would be some elements which could not be cached by role.
There are, however, a whole bunch which can - I'm confident in my original assertion of 'vast majority', in fact.
That there are some places it can't work doesn't sound like a good reason to not consider the places where it can - unless we're going to keep thinking of caches as a full-page- only thing.
i18n/l10n, as you say, would probably have to be another "vary" switch. This implies that we should maybe be thinking about a new core hook, which modules can use to introduce/manage switching cases.
How about stepping back and thinking about what variables can affect caching on any given theme() function, and in which order they do so?
eg
1. (core) Role, and if not role then 2. (core) User, and if not user then 3. (i18n module) $some_i18n_variable, else 4. ...what else?
Actually, that list might be upside down in practice, but hopefully I've managed to get my point across.
Cached values would be returned for any function which returns theme output... like...
[pseudo-code]
function node_page_default() { global $user; if (node_page_default_cache($user->uid)) { return node_page_default_cache($user-uid); } else {
// original function here
} }
...where node_page_default_cache() would be an implementation of hook_cache(), which in turn contains that order-of-preference logic mentioned above. $user->uid gives us the ability to check roles, uids, and anything else we might need.
This would involve changing *lots* of functions, I realise, but consider how many DB queries we'd be culling.
On the other hand, a well-written hook allows modules to start using it incrementally - modules which haven't implemented it yet don't fail.