put the most recent forum posts block into memcached

you should add a check to see if any node access module is active. if yes, do per user caching, or none at all. here is the code:

if (count(module_implements('node_access_records'))) {
  // per user cache (like old D5 menu system)
}
else {
  // one global cache
}

for now, how about a custom PHP block (or theme function) that caches the result for the desired time - no need to even hack core...

you should add a check to see if any node access module is active. if yes, do per user caching, or none at all. here is the code:

if (count(module_implements('node_access_records'))) {
  // per user cache (like old D5 menu system)
}
else {
  // one global cache
}

@justinrandell, just FYI, caching is a general Drupal API, not memcache specific.

So if you use cache_set() and cache_get(), it should work with the database cache, memcached, and flat file cache.

Just do a cache_set on the HTML of the final block, and retrieve it the same way.

If you look at the affiliates module, it does exactly that http://drupal.org/project/affiliates.

The permissions thing that moshe mentioned does not apply to Drupal.org, since we don't have private forums or private forum posts, but it is a good thing to have as a general feature for the forum module.

Another option is the block cache module too http://drupal.org/project/blockcache.

That patch looks OK for drupal.org. It's not something that could be committed to CVS HEAD as is, but it should work in the drupal.org use case. We don't use any node access modules on drupal.org so no need to worry aboutt hat.

For CVS HEAD, Gerhard proposed a more generic solution: http://drupal.org/node/80951 ... as we will upgrade drupal.org to CVS HEAD before the final Drupal 6 release, it might be worth putting some time and effort into issue #80951.

In other words: this patch should get the job done (short term solution), but let's focus on polishing #80951 (medium + long term solution).