I have several sites (4.7 and 5.1) that have blocks on the front page displaying "upcoming events." Cache is turned on and most site visitors are anonymous.
I need a way to ensure that the "upcoming events" list is periodically updated so that old events are not listed after they have taken place.
I think (?) that normally this kind of updating would occur when a user logs in and/or when new content is added. (Those events trigger a clearing of the cache?)
The problem is that several of the admins for these sites do not add content or log in to the stie very often. Therefore events that are a week out of date often appear in the "upcoming events" section. (As soon as I log in and then back out, everything is updated, even for anonymous users.)
Any suggestions? Do I need to somehow force cron.php to invoke cache_clear_all? If so, how?
THANKS for your help...
Comments
In 5.1 use the 'minimum
In 5.1 use the 'minimum cache lifetime', in 4.7 meh, disable the cache ;o)
Pobster
don't think that will do it...
Thanks for your advice--appreciate you taking the time to post.
Unfortunately I think i saw another post discount this as a solution...
As far as i know, the 'minimum cache lifetime' forces cached pages to persist for _at least_ as long as the setting. They force drupal to ignore "empty cache" commands until the 'min cache lifetime' has elapsed. But i don't believe that this setting forces the cache to renew once the "min lifeftime" has expired.
Am i wrong? If not, is there another solution?
There isn't a setting for
There isn't a setting for 'off', so 'none' *never* flushes the cache - here's the instructions;
Pobster
solution...
Thanks for the clarification. In most cases I think your suggestion would be right. But in this case, that's exactly my problem: the cached data is persisting for too LONG, not too short an amount of time.
Here's what I ended up doing, in case it's helpful to others. I created an extremely simple module called cache_refresh. It takes a list of specified pages, and deletes their page cache entries each time that cron is run. I just hard coded the pages into the module; you could modify to allow an admin to enter them under a "settings" page instead...
The following is working for Drupal 5.1 (along with the necessary .info file). Seems like it should work in 4.7 as well (without .info), though I haven't tried it yet...
(Disclaimer: I'm not an expert programmer, and make no guarantees, warranties, or other -ees about the following code. That said, it seems to be working for me...)
[per drupal coding standards, omit the closing '?>' in the actual module ]
Note: you may want to set up an additional cron job that visits each page (using wget, curl, lynx, etc) that has been cleared from the cache shortly after cron.php has been run. That way the page cache will be re-populated before real visitors visit the pages. If it's possible to incorporate that step into this module, that would be even better...
*sigh* you don't
*sigh* you don't listen;
As I said before, twice now... Just set the minimum cache lifetime to a value other than 'none' and it'll rebuild the cache not on your cron but when a user goes to any page (when that amount of time has passed). Your code is unnecessary? Set it to a minute if you like, it's still going to be better than an hourly cronjob... Not that you're listening...
Pobster
Is "minimum cache lifetime" wrongly named?
The name says just what the original poster is worried about, that Drupal will wait at least that long before clearing the cache, not that it will wait at most that long. If it does the latter, as Pobster claims, it should be relabeled "maximum cache lifetime." I'm not just mincing words here. "Minimum" and "maximum" have completely different meanings.
On the other hand, if "minimum cache lifetime" is correctly named, which is what the original poster is concerned about, Pobster's "solution" will not help at all.
Perhaps someone could clarify this? I haven't used this setting at all (though I do see this problem with anonymous users, so I'd like to know the answer too).
Americans... We all speak
Americans... We all speak English - what is the problem here?!! ;o) It's so called 'minimum cache lifetime' because it's not called on a cronjob, it's called when someone visits your site and so is the minimum amount of time before the cache is recreated - if no-one visits your site for an hour then the cache won't be recreated until then. Don't think of it in terms of waiting FOR something to happen, it's about the lifetime of something to exist - the cache needs to be AT LEAST 1 minute old before it's recreated, that's the minimum 'age' it can be - regardless of whether it's an hour later.
...I'm not giving you "Pobsters Solution" I'm simply reading the instructions!
Pobster
Ok, I understand the phrase
Ok, I understand the phrase now, but I still think it's confusing, and apparently I'm not the only one. There are many phrases which are ambiguous in English, and I submit that this phrase, used in this context, is one. (And I don't think my country of origin is the reason, however much fun it may be for the rest of the world to poke at Americans.)
Meh you lot get the last
Meh you lot get the last laugh when pretty much anything I install on my PC I can only choose en_US or 'American' as the language... ;o)
Pobster
I read the description of
I read the description of minimum cache lifetime like isaac77: the "minimum cache lifetime" forces cached pages ton persist for _at least_ as long as the setting. They force drupal ton ignore "empty cache" COMMANDs until the "min cache lifetime" has elapsed. But i don't believe that this setting forces the cache ton renew once the "min lifeftime" has expired.
I tested this with a revenue-sharing for Adsene 50/50 in testmode (publisher-id is displayed):
cache disabled:
- for publisher-ID changes with approx. each 2. Side call, like it should be
cache enabled:
- a comment to a node or an edited node empties the cache
- if nobody edits a node and noboby posts a comment cache doesn't change and the publisher-id is always the same
cache enabled with a minimum cache lifetime (of 3 minutes):
- a comment to a node or an edited node empties the cache only if duration of minimum cache lifetime is expired.
- if nobody edits a node and nobody posts a comment, cache is not deleted and the publisher ID does not change - the cache is not deleted after expiration of minimum cache lifetime.
In the description of minimum cache lifetime you can read, that this is for high traffic sites. And there it makes sense. If each minute a posting is written (like in drupal.org), then the cache is deleted each minute and it's like you disable the cache. But if you enable a minimum cache lifetime, cache is only deleted after this time and anonymous users see new comments only after this time.
See also http://drupal.org/node/103995
I still have this problem
I still have this problem as well. Is there something like http://drupal.org/node/103995#comment-181373 for Drupal 5? Does Drupal 6 have this issues? I have a few sites that don't get a lot of posts (and no comments), and the Upcoming Events block gets terribly out of date.
what about the code above
Does the code i posted above (http://drupal.org/node/142242#comment-230284) work for you? Same disclaimers apply, but it has worked for me on a few 5.xx sites...
For Drupal 6, running
For Drupal 6, running /cron.php a few times should get the page cache cleared by system_cron(). Minimum cache lifetime should also be set to a small value, say 5 minutes.
--
http://ball.in.th, http://บอล.th - ชุมชนคอบอลอันดับ 1 (ยังไม่ใช่ แต่เราจะไปให้ถึง 555)
Maybe
http://drupal.org/project/cleaner
NancyDru