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

pobster’s picture

In 5.1 use the 'minimum cache lifetime', in 4.7 meh, disable the cache ;o)

Pobster

isaac77’s picture

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?

pobster’s picture

There isn't a setting for 'off', so 'none' *never* flushes the cache - here's the instructions;

The minimum cache lifetime is the minimum amount of time that will go by before the cache is emptied and recreated.

Pobster

isaac77’s picture

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...)


// $Id: cache_refresh.module,v 1.0 2007/4/8 08:27:00 i Exp $
 
/**
 * @file
 * Clears page cache entries for specified pages each time cron is run.
 */

/**
* Valid permissions for this module
* @return array An array of valid permissions for the custom_navigation module
*/

function cache_refresh_perm() {
return array('access cache_refresh', 'administer cache_refresh');
} // function cache_refresh_perm

/**
* Implementation of hook_cron()
*/

function cache_refresh_cron()
{

$pages_to_refresh = array('http://domain-name.com/pathtopage', 'http://domain-name.com/node/12', 'path to another page to clear');


/* A wildcard search is done. The page cache table will be searched for paths matching (or _partially matching_) those listed in the array above. Matches are then deleted.

foreach ($pages_to_refresh as $page_to_refresh)
{
cache_clear_all($cid = $page_to_refresh, $table = 'cache_page', $wildcard = TRUE); 
}

/*  I think that it would not work to list the homepage in the array of pages to clear:  the path to the homepage would match every entry in the page cache table in a wildcard search.  So homepage (if you need it cleared) is dealt with separately, using a non-wildcard search. Be sure to include both www.domain-name.tld and domain-name.tld  */

cache_clear_all($cid = 'http://domain-name.com/', $table = 'cache_page', $wildcard = FALSE); 
cache_clear_all($cid = 'http://www.domain-name.com/', $table = 'cache_page', $wildcard = FALSE);


}

[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...

pobster’s picture

*sigh* you don't listen;

function cache_get($key, $table = 'cache') {
  global $user;

  // Garbage collection necessary when enforcing a minimum cache lifetime
  $cache_flush = variable_get('cache_flush', 0);
  if ($cache_flush && ($cache_flush + variable_get('cache_lifetime', 0) <= time())) {
    // Time to flush old cache data
    db_query("DELETE FROM {%s} WHERE expire != %d AND expire <= %d", $table, CACHE_PERMANENT, $cache_flush);
    variable_set('cache_flush', 0);
  }

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

emdalton’s picture

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).

pobster’s picture

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

emdalton’s picture

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.)

pobster’s picture

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

Petra’s picture

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

gtcaz’s picture

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.

isaac77’s picture

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...

ball.in.th’s picture

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)

nancydru’s picture