This is similar to request https://drupal.org/node/1763412 but a request for an option to ignore all requests to flush caches, not just those related to modules being enabled, so I have made it a separate request.

We use Expire with Boost, and only wish items be removed from the cache when they are changed. With this use case we should never be flushing the entire cache and don't want to take the chance of having any process doing it. If there is some exceptional condition that requires the cache to be flushed, we will login to the server and delete the cache directory manually.

I will be submitting a patch with a proposed implementation of this option.

Thank you

Frank

Support from Acquia helps fund testing for Drupal Acquia logo

Comments

fbrooks’s picture

Attached is the patch for consideration.

It exposes a checkbox for the option in the admin interface. If the maintainers feel that this is too much of a niche feature, and might confuse those that use boost in a more typical configuration, we would be fine with the option not being included in the admin interface. It would be OK with us if a user needed to be aware of this option and set the variable manually to enable.

Thank you

Anonymous’s picture

Assigned: Unassigned »

Hi, really I'd like to know if you've found a bug as in theory what you haved worked hard to create is already possible.

boost_crawler - (which should probably be called boost_regenerator) alters any pages or family of pages that have been inserted/ updated/ deleted.
in admin/config/system/boost/expiration if the tick box Remove old cache files on cron is not selected

the apart from the installation of a new module or theme, as per the mention feature request, then this should replicate your stated aims of

We use Expire with Boost, and only wish items be removed from the cache when they are changed.

A cache flush after a module/ theme installation is not illogical per se, as a new theme or functionality may be required to be applied to the original site contents as well as the new.

fbrooks’s picture

Hi Philip,

Thank you for your prompt reply.

What we want is not entirely possible. Deselecting Remove old cache files on cron does stop Boost from clearing the cache as part of its own cron process, however any arbitrary process can still invoke boost_flush_caches and clear the entire cache at any time. That is what the option in this patch would allow an admin to stop.

We basically want complete control of when the boost cache is flushed. This option would provide us the one missing piece.

I don't know if I would call it a bug, but I would say that I think by deleting cached files, boost_flush_caches violates the expectation a caller to this hook should have based on the API docs.

https://api.drupal.org/api/drupal/modules!system!system.api.php/function/hook_flush_caches/7

The docs indicate that calls to the hook only return a list of database tables to be cleared and nothing more. Calls to this hook do not actually flush anything, contrary to what the name might suggest.

I don't think I want confuse this issue with a discussion of that though. Introducing an option to disable this behavior seemed like the simplest, least intrusive solution to our issue. Again, we would be fine if the option was not exposed in the admin interface.

Thanks

Frank

smitty’s picture

Issue summary: View changes
FileSize
4.42 KB

I think this is a useful option because not every change in the user-interface like installing or uninstalling modules has an impact on the cached pages. There are many modules which do not change the look of any page. So it's a pity if the boost cache is flushed with every module installed.

But I it would be handy if there would be an option to clear the cache manually from the performance panel.

So here is a patch with the option to accept flush commands coming from the Performance Panel (Button: Clear all caches)