Pages expires long before their lifetime

cache get's nuked on every cron run. I think that fixed your issue correct? Should probably document this.

Hello,

I think I am having the same issue.

I was monitoring the cache folder, and for example, my index.html is regenerated every 20-30 minutes, when my minimum cache lifetime is set to 1 day.

Anyone else has this?

@giorgio79
How often do you run cron? How often does the frontpage's content change?

Thanks Mikey for comnig back.

The front page does change often, it shows new content in a views, and also popular pages that were just viewed in a block.

I understand these could cause a regeneration, but it was my understanding that the minimum cache lifetime overrides this feature. :)

Where did I go?

Boost expires that page's cache when the node is updated. You can see the logic in these functions
boost_nodeapi()
boost_comment()
boost_user()
They all have to potential to call boost_cache_expire(), which forces an expiration of the cache. You can comment out the calls to boost_cache_expire in these functions and that should give you what you want.

Thanks Mikey, just out of curiosity, do you agree that the minimum cache lifetime setting should override these?
I think we whould consider controlling this from the user interface, as I am sure many of us have blocks on their site with recent content, recent comments etc, still I think most of us would want it to update as per the minimum cache lifetime.

I think it depends. Its behavior should be a user controllable setting. Something to add to boost in the future. There's a lot of work to be done for this module; so if you wish to write a patch to add in this option, I would look it over and go from there.

Meanwhile I went ahead and commented out those functions. Works very nicely :)

guys - each page should expire either when the node is updated or when her life comes to its end - NOT when cron runs. Is the current situation "delete ALL on each cron run"? I observe just that with the latest boost-6-dev patched with the latest (no symlinks / i18n support patch) - maybe it is by design OR after the patch boost does not seem to work well with the new kind of file paths/urls??

If there is a performance penalty to check if a page is expired it would be a pitty - cause "delete all on cron" isn't nice either...

@rsvelko
Clearing the boost cache on cron is by design. Read from this comment down for the details.
http://drupal.org/node/183252#comment-1466010

we need to document this fast - right now in the README there is somewhat old and not all the info.

I think you mikeytown2 understand the logic enough - please write in the README:
- when (node updates etc or cron runs) and why (lifetime ended, content updated, JS/CSS cache regenerated) is it possible for a page to get expired

PS From this point further we can help and think of the way we continue with boost - it seems to me that deleting ALL on each cron is a neccessity which we can counter-attack with cache recreation (separate issue open already with its own caveats (performance cost of crawling mainly) )

@rsvelko
I run this after I run cron, it's alpha quality code, but it works for me right now.
http://drupal.org/node/363077#comment-1446462

Been thinking about this, and if css & js aggregation is turned off then cron doesn't need to clear the boost cache. IMHO thats a slower setup (no css/js aggregation) but I think some people might want this option. Then again why not use HTML Export or Save to FTP if your content doesn't change.

This would involve a check in the variable table (preprocess_css & preprocess_js) in these 3 Functions
boost_flush_caches()
boost_admin_modules_submit()
boost_admin_themes_submit()
Any other functions?

Attached is the proposed changes. It should allow one to run cron & not clear the cache if css & js aggregation is turned off.

Hi Mikey,

I checked HTML export and Save to FTP, and they are interesting.

It is true some of my content for example does not change much, maybe a comment a day, but I am happy if it is updated at the end of the day and not right away.

Blocks like Recent viewed blocks made my pages clear the next hit from a user so using Boost lost its purpose :)

fixed logic, patch now works correctly.

committed