Support for Drupal 7 is ending on 5 January 2025—it’s time to migrate to Drupal 10! Learn about the many benefits of Drupal 10 and find migration tools in our resource center.
Hi
In hook_flush_caches() there is a piece of logic that checks if it was called by cron. It does this by checking lock_may_be_available('cron').
The problem with that approach, is that it spans across requests. So whenever cron is running, hook_flush_caches() will not flush, regardless of being called from cron or not.
Perhaps a better approach could be to check $_SERVER['PHP_SELF'] for 'cron.php'?
Comment | File | Size | Author |
---|---|---|---|
#3 | boost-cron-detection-1829832-3.patch | 3.72 KB | gielfeldt |
#1 | boost-cron-detection-1829832-1.patch | 2.76 KB | gielfeldt |
Comments
Comment #1
gielfeldt CreditAttribution: gielfeldt commentedHere's a patch...
Comment #2
bgm CreditAttribution: bgm commentedCan you give more information on how lock_may_be_available('cron') may span across requests?
Does checking for cron.php explicitely also work when the cron is called from drush?
Thanks for the patch.
Comment #3
gielfeldt CreditAttribution: gielfeldt commentedHi bgm
One of the main purposes of a lock/semaphore is that it's available across requests, so one may take concurrency into consideration. The lock is stored in the DB (or memcache or other backend). It's available to whoever asks for it. So if cron is running, and you then invoke the flush_caches, then Boost will not flush its caches, because it thinks cron is running ... because cron __is__ running, just in another request.
The patch didn't support Drush, well spotted. I've added a new patch that supports Drush as well.
Comment #4
gielfeldt CreditAttribution: gielfeldt commentedAny news on this?
Comment #5
heddnIt works. I tested both with drush and cron.php on a fairly complicated site that also has boost installed.
Comment #7
ram4nd CreditAttribution: ram4nd as a volunteer commented