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.All chaches are flushed on every cron independently of variable boost_ignore_flush.
The problem is during cron process, the system's cron function is invoked, before boost_cron() run. The system cron does a cache clear, and the boost_flush_cache() is invoked without $_boost['cron'].
Solution: $_boost['cron'] doesn't need. As I see, this is used only boost_flush_cache. If want to check boost_flush_cache is called by cron, just simple check lock_may_be_available('cron').
| Comment | File | Size | Author |
|---|---|---|---|
| #1 | 0001-1430942-1-Fix-bug-all-chaches-are-flushed-on-every-c.patch | 1.56 KB | szantog |
| Selection_132.png | 43.38 KB | szantog | |
Comments
Comment #1
szantog CreditAttribution: szantog commentedAnd patch:
Comment #2
szantog CreditAttribution: szantog commentedLet's needs review. :)
Comment #3
rondev CreditAttribution: rondev commentedThank you.
I was just thinking about having a look at that.
After patching, I can say that it doesn't delete my cache at cron.
I need more times to see if now boost respects the conditions well.
Comment #4
rondev CreditAttribution: rondev commentedJust title typo
Comment #5
szantog CreditAttribution: szantog commentedHmmm.. I don't understand this.. This patch doesn't do anything, just changes the cron running checking method to stable one.
Just look at this:
This works on two of my sites. It just does exactly same, as the settings, the last node was post eg. 4:30 pm yesterday.
Comment #6
rondev CreditAttribution: rondev commentedSorry not to explain myself clearly.
I just tested that your patch doesn't flush all caches on every cron.
I just need more times to check the other conditions and how they work as before your patch none were working, all caches were flushed.
Comment #7
bgm CreditAttribution: bgm commentedCommitted to 7.x-1.x, thanks for the patch.
(bug reproduced locally, code makes sense and fixes the issue)
Comment #9
rondev CreditAttribution: rondev commented@Szantog,
I finally found where was strange behaviors I noticed. There is still some flush when you do http://yoursite.com/update.php.
In the function boost_flush_caches, your condition doesn't suffice
if (isset($_boost['base_dir']) && (lock_may_be_available('cron') || variable_get('boost_ignore_flush', BOOST_IGNORE_FLUSH) == FALSE))I modified to
if (isset($_boost['base_dir']) && lock_may_be_available('cron') && variable_get('boost_ignore_flush', BOOST_IGNORE_FLUSH) == FALSE)which work but modify the usual behavior regarding the main cache clearing.
We should do a better condition.
Comment #10
rondev CreditAttribution: rondev commentedChange status.
Comment #11
bgm CreditAttribution: bgm commented@ rondev: you're changing the logic in a way that the cache will practically never be flushed. The condition says that we may ignore the flush if cron called it, but we don't otherwise want to ignore a cache flush.
You might want to add an option to "ignore all cache flushes" and offer the admin a manual way to flush the cache?
In any case, that's a feature request, and the original request is resolved. Please open a new issue if you'd like to implement this.
Comment #12
rondev CreditAttribution: rondev commented@bgm
You are right. The szantog condition address the wanted behavior.
I noticed that update.php call
drupal_flush_all_cachesfunction which callboost_flush_caches(). And that is the normal behavior.It would be interesting too add a condition to avoid boost cache flush if a update.php is executed. I will open a feature request.