Assuming you use a new flag (#1425156: Dynamic_cache should be bypassed in certain admin contexts (drush, cron, etc.)), your code is a single line away from being able to update the existing page cache value without having to first delete it from the DB (or, as I call it, surreptitiously refreshing page cache).

In a lot of cases, this is undesirable, but there are a few with great benefits. My particular use case is setting up a module to allow page cache bypass on a user-agent basis so that my site crawler can freshen page cache and all real users always load pages from cache.

To do so, you just have to add...
ob_start();
...above your drupal_page_header() call.

You could create an admin page to toggle whether to that happens, or you could create another global variable (or both, the admin page to choose default, and allow others' modules to override it if/when necessary). Whatever makes the most sense.

Comments

brian_c’s picture

brian_c commented

The issue you linked to has been resolved without changing the flag used (ie, Dynamic Cache will continue to piggyback on $conf['cache']), does this prevent the cache refresh technique you describe from working?

iamEAP’s picture

iamEAP commented

There are some issues with core that make my surreptitious cache refresh kind of moot anyway #891600: Page and block caches are cleared the same way on cron as on content change. Feel free to mark this as postponed or closed won't fix. I'll reopen if and when it's appropriate.

brian_c’s picture

brian_c commented
Status: Active » Postponed

K. If this feature is still desired, perhaps we can add a module-specific config flag that could be triggered.. $conf['dynamic_cache_refresh'] = true or whatever, could trigger DC to bypass cache and regenerate current page (which would replace the existing cache entry).