When block caching is turned on, the author_pane block is cached.
Since no caching is defined in the block definition, it falls back to the default block caching (BLOCK_CACHE_PER_ROLE). This should be BLOCK_CACHE_PER_PAGE
In code:
/**
* Implementation of hook_block().
*/
function author_pane_block($op = 'list', $delta = 0, $edit = array()) {
switch ($op) {
case 'list':
$blocks[0]['info'] = t('Author Pane');
$blocks[0]['cache'] =t(BLOCK_CACHE_PER_PAGE); // Cache this block per page
return $blocks;
| Comment | File | Size | Author |
|---|---|---|---|
| #1 | author_pane_445192.patch | 603 bytes | Jo Wouters |
Comments
Comment #1
Jo Wouters commentedAnd now with a patch.
This issue might be related to #435274: Showing wrong author
Comment #2
michelleOh, interesting. I never thought about how caching might affect it and I've never even heard of block caching before. To be honest, the whole "use as a block" thing was an afterthought for another possible use and I haven't put much time into it. The main point of this module is to be used in forums/profiles where this wouldn't be an issue.
Still, though, the feature is there so I should make sure it works right. I need to make a 1.1 at some point for Panels 3, anyway, so will make sure I get it into there.
Thanks,
Michelle
Comment #3
michelleI took your word for it and committed your patch without testing. If it comes up again, will look at it in more detail.
Thanks,
Michelle
Comment #4
abaddon commentedhow would this impact information that should only be visible for certain roles, for eg. the ip address listing, which i would only want admins to see?
shouldnt it be BLOCK_CACHE_PER_ROLE instead of BLOCK_CACHE_PER_PAGE in this case? (or PER_USER or not cached at all) just a thought, i may be wrong
Comment #5
michelleOh, good point. Yeah, this shouldn't be cached at all. Will look into what I need to do to exclude it from caching.
Thanks,
Michelle
Comment #6
Jo Wouters commentedVery good remark abaddonsun !
Solution: Since block cache settings are bitmask-based, they can be combined:
btw. my code contained a stupid error: in my first patch I have put the cache setting in a t()-function !?? stupid me
Comment #7
michelle@Jo Wouters: Thanks. I haven't had a chance to figure this out yet. And block caching doesn't work on my site for some reason so I can't even test. Is there a way to cache per user? That would be better than caching per role because AP can change depending on the user looking at it. Honestly, I'd like to just totally turn the caching of it off but if you can cache per user, per page, I guess that's good enough.
Michelle
Comment #8
Jo Wouters commented@Michelle Yes,caching per user (and per page) is no problem:
but if caching is needed on a per user and per page basis, it might indeed be better not to cache at all. Every cached block requires one row in the {cache_block} table
If you want no caching at all, we could use
(See http://api.drupal.org/api/function/hook_block/6 voor more info)
Comment #9
michelleNo cache sounds best, since what's displayed changes based on the user viewing as well as the user being viewed. Also things like adding a friend would mean the icon needs changing.
Thanks for the info. I have a meeting tonight so won't get my usual computer time after the kids are asleep. I'll try to get this in tomorrow, though. I really need to make a 1.1 for the Panels 3 changes.
Michelle
Comment #10
michelleOk, committed. I tested as far as making sure there were no syntax errors but can't test if this actually is effective in keeping the block from caching since block caching doesn't work on my dev site. I would appreciate if someone could try it out and let me know if there's still a problem.
Thanks,
Michelle