Optionally trigger recaching via hook_exit

Hmm, good one. Thought of it as well, in fact posted some thoughts about immediate recaching in #2714211: Rules Integration / 3.

We could fire a re-caching request immediately as we detect a node change, or at hook_exit().

The problem I see is that at that moment caches *most probably* are not yet expired. Esp. any external cache (Boost, Varnish, Akamai, ...) needs a certain time to receive the purge requests and process them. If we fired our re-caching request so soon, we would probably still hit the old cache.

That said, I am happy to implement recaching on hook_exit() as an option. It probably will work for standard Drupal page caching (database), and maybe for local types of caching, such as Boost. I just doubt it can ever work like that when using Akamai / Varnish / Fastly / ...

What do you think, @DamienMcKenna? Please correct me if I am wrong.

Does not apply to the current dev; could you do a quick re-roll?

Committed to 7.x-1.x-dev. Needs the tests -- and testing before we can close this issue.

Changed the checkbox that added caching via the exit hook to a radio button, so that the exit hook and cron become alternatives. Also made sure that the cron hook does not get executed if the exit hook is selected. Already committed to 7.x-1.x-dev. Is backward-compatible.

@DamienMcKenna -- some comments:

1. I'd say the &drupal_static lines may be moved outside the foreach() in recacher_expire_cache() -- correct?
2. Using static caching, you guarantee recacher_crawler() gets executed in recacher_exit(). But only once, if I am not mistaken. If variable 'recacher_max_urls' specifies that only a few URLs may be recached at a time, the rest of the expired URLs will never be recached.
3. About the tests -- could you add what you have in mind? I don't need they have to be exhaustive for now.

If you do any improvements please provide a patch based on the current dev. Thanks!

Thanks, @Damien!

Had to change lock_acquiare() to lock_acquire(), LOL :-)
Committed to 7.x-1.x-dev.

Testing both the scheduled and immediate caching. Please test this also on your side before I roll a new stable release.

Added a test to see whether there are any modules implementing hook_recacher_role_options(). Without this test, variable $recacher_role_options was being emptied.
See patch. Committed to 7.x-1.x-dev.

@Damien: I understand why you prefer not to disable hook_cron() if hook_exit() is being used.
What worries me is that after hook_exit() runs, even if it is not successful, it will clear the URLs from the queue, meaning hook_cron() will never get a chance to pick them up.

Therefore I propose to allow URL deletion from the queue only when hook_cron() runs.
hook_exit() may try to re-cache even earlier (if switched on at the config page), but will not delete the URLs it crawled.
The only disadvantage of this approach is that if hook_exit() manages to achieve the recrawl, then hook_cron() will do nothing. On the other hand, it will be a very fast and cheap call hitting the cache.

Patch attached, code committed to 7.x-1.x-dev!

Seems to work perfectly for me. What hook_exit() does not catch is cached by hook_cron(). Test OK.

Seems stable; marking as fixed. If you see any issues, don't hesitate to reopen.

Now also in 7.x-1.2.

Hey this is thanks to your report and a great initial patch DamienMcKenna ✓