We have a Kirby cache folder where we store cached pages, but where do we store cached plugin data?
The built in cache folder?
Somewhere in the plugin folder?
Somewhere else?
To use the built in cache folder feels natural at first sight but when thinking about it, it’s just cached pages in there. Should we really mix all kinds of data there?
If using the plugin folder, when updating the plugin it’s easy to just remove the old one first. Then the cache folder will be removed as well and that might not be what we want. The same thing if we remove the plugin and then regret what we just did.
So, where would you store your plugin cache data? And why?
You don’t store it anywhere, you tell Kirby to do it for you.
It’s just the same as with parts of pages. You shouldn’t feel bad about storing your plugin caches there, but you should probably prefix your cache keys with the plugin name.
But this might be hard if I for example never want to clear my plugin cache. Maybe it’s less of a cache and more of storing data. Or the plugin cache might have an expire date.
Plugin data that never ever expire. Where to put that?
Please note that caches are meant for information that can be regenerated at any time. Don’t rely on the data to be there, always have a fallback like in your code example that gets the information and stores it in cache again.
If the data is really persistent and can’t be regenerated, use a directory in /content or /site, depending on what kind of data it is.
If it is data that can be regenerated, also in the cache. Otherwise like I wrote above in content or site.
In the cache but with an expiry date. Kirby will delete the file from the cache automatically when it has expired.
The plugin folder has one huge disadvantage: It is meant for code. If you manage your site with Git submodules, you won’t be able to easily update the plugin.
You are right that a content page isn’t perfect. But then using a custom directory in /site would be the best way. However there are some situations where a content page is the right choice, especially if the data should actually be viewable from the Panel.
I would think the submodule situation can be handled by adding the data file to .gitignore, then the plugin needs to create the file if it doesn’t exist.
This mimics the behaviour of thumbnails and cache files, for git submodule purposes.
But then your data directory would again be a cache. You should never store permanent data in a directory that is ignored by Git. Users will assume that every “clean” directory of a plugin will only contain the unmodified plugin code, so they will assume that they can reinstall the plugin without losing anything.
And again: Caches should be stored in Kirby’s cache. Non-caches shouldn’t be stored in either of the Kirby cache or the “directory with .gitignore inside the plugin” cache.
I don’t have a site folder anymore. I use Bricks so I don’t need it. But a solution would be to let the plugin have a custom path with a fallback to site/something.
Let’s say I want to cache widget data every week and I save the cache to the cache folder. If a user save a page, then the cache is cleared, right? Then the cached might be cleared every day which means the widget cache will be cleared every day instead of every week. In the long run it means a slower Panel startpage.
In that case I wonder if the cache folder is good after all. It’s two different kinds of cache.
If I will build it, every plugin need to somehow be bundled with the repo url or at least the username of the plugin creator to build the url. Let’s say I keep this data in a single file which updates when a plugin is added, deleted or change. It might feel overkill to add a new folder in site for just one cache file. It could be possible to add it to the site root as a file, not sure what is best. Also if I have 4 plugins like this, should they all create their different site cache folders?
In conclusion, I feel like there are many different working approaches but no perfect one. I also agree that saving the data in the plugin folder also include some possible problems.
This topic kind of died with my last post. I’ve been thinking about it a bit more.
Kirby cache
A build in cache primarily for caching pages. When changes is made to the content, the cache is cleared.
Plugin cache
In this example it will be cleaned by a time interval. It will be cleared for example once a month because of the heavy loading time of a feature.
Thoughts
From my point of view these both caches does not work well together. If I create new pages every day the plugin cache will also be cleared every day which might not be what we want. Imagine a widget which have a hard time fetching data. Maybe we only want to run it once a month. It would be a disaster to have to reload it every time a page has changed.
Possible solution
I think that the @samnabi solution is not that bad after all. Having a cache in the plugin folder makes it isolated from the Kirby cache and they will not intervean with each other. But yes, we need to make sure that it’s not uploaded to the repo.
I also agree with @lukasbestle that we should never ever store permanent data in the plugin folder, only cache data that the plugin will recreate if it’s missing.
To have a real example:
Let it fetch some of the pages on the site remotely to check for some of the security issues. Save it to a cache and only refresh the cache daily, weekly or monthly. I will probably just have an option with a number of days as integer.
If nothing changes I will probably use a cache folder in the plugin for the cached data. It seems like the way to go.
I think what might be the best solution after all is a protection for non-page caches. Currently the whole cache is flushed on every change, but Kirby could be a bit smarter and only flush page caches. Would you mind opening an issue on GitHub?
