Create cache (file) invalidation logic

Boost caching can be seen and used (via webserver) as proxy cache. So I think it's a good idea to start to reuse system caching configuration on site /admin/config/development/performance

But instead of analyzing cache header in cached files it's easier to just use the creation time of the cached files. I can imagine that this can sometimes be a problem but only in very sophisticated setups and in any case this will be optional. So there will a Button to "Enable cron purge max_age".

Because drupal/php file search and deletion is not so fast I added possibility to user php exec with OS commands find and rm. And additionally or instead of cron there now also a drush command "boost:purge-max-age"

A good start would be time based.

Any opinion on cache tag based invalidation? medium term/ long term?

> A good start would be time based.

The code in this branch is already time based.

> Any opinion on cache tag based invalidation? medium term/ long term?

Currently D9+ boost is not a real cache backend where cache tags can be added and used. It has more common with cache proxies outside of Drupal like varnish. If possible I would like to avoid extra data in database or make this optional maybe with a sub module.

On the other side is boost still a module and so we have much more possibilities as external full html caches. So there is maybe a way to "hook" on cache invalidation of the code page caches and other core cache operations.

In D7 the expire module was replaced by "purger"/"purge"

The expire module has some pretty sophisticated cache invalidation capabilities and works fairly well.

The expire module had support for boost or vice versa.

If cache tag support came in a submodule say for example called boost_purger that'd be really cool.

I recall assisting in the development of a module called boost_blast which was designed to invalidate the entire boost cache, worked well for the odd time that some extra force was needed.

Keep up the great work on this initiative. I would hope that once we get a tagged release, people will start using it and then support will grow from there.

I'm sure that boost_blast would be easy to port to D10, very simple module. the drupalmoduleupgrader should do most of the work. https://drupal.org/project/drupalmoduleupgrader

once there's a tagged release of boost for D10, I will then port boost_blast to D10.

The time based purging code if this issue is very fast and I currently see no need of additional purging modules. And if there will be a cache tag implementation in future etc. I think we should also directly add purging features.

It seems your module boost_blast is pointing on the multisite functionality of the d7 version of boost. I remember the domain path part of D7 but this domain/multisite thing is not code on D9+ version yet. So I just added a new issue for that: ✨ D9+ Multi-Domain and Multisite support Active

Well, I would just like to add an idea. It could be another approach to integrate boost with ECA → or rules → .

@Orkut Murat Yılmaz Please open an extra issue for this and please specify in which way you like to integrate. For me that has currently not a high priority especially because so many basic feature are still not stable.

Automatically closed - issue fixed for 2 weeks with no activity.