I’m wondering where is the best place to store plugin data. In my case, the data is not associated with a frontend user page. It is only accessible via API calls. The plugin provides a custom panel view with some input, which needs to be stored somewhere. I thought of the following ways and would like to hear how some of you are handling this:
Plugin folder: I rejected this quite quickly as it’s not save when updating a plugin via git.
Plugin cache: Might work, but the data should actually be stored persistently. So flushing the cache would clear the plugin data, which is not good. So I rejected this idea, too.
Content folder: This is the way I’m going right now. I store the data in the content folder as the data really is some sort of content. However it isn’t page content. So I put the content in a folder with a leading dot in order not to have it confused with a regular page. The folder name is something like .my-plugin.
What do you think? Is this a good way to store plugin data? This approach works quite nicely in my Kirby installation without side effects. However, it appears a bit hacky to me. Do you have any other suggestions where to store plugin data that I didn’t think about?
I think it doesn’t really matter where this data is stored, if in the root or in the content folder. Not all data stored in the content folder must be page data.
Right, I didn’t think of a database approach. I will consider this in the future.
I’m just storing some coordinates and some values from text inputs, selects and similar. It’s not much. So it can easily be done in plain text. I guess I will stick to the content folder approach for now.
Yep, I agree, if it’s just a little bit of data, it’s not worth the database approach at all. If everything is in the content folder, it’s easier to back up all the content,
This goes somewhat beyond the scope of this thread, but what about providing an official logs root? Many plugins log stuff and it would be nice to have a dedicated directory for that, even if Kirby itself doesn’t write any data there. When used inside a plugin, a Logger utility (maybe like @bvdputte‘s kirbylog?) could write to a folder named after the plugin. Some plugins place their logs inside site anyway - so if I configured it to be somewhere else, all plugins using this core feature would follow this decision rather than writing to a hardcoded destination …
confusion !! I was about to open an issue on GitHub - I really think the feedback thing Leads to prioritising (only) popular suggestions - well … if you tell me this is where it belongs, I’ll post it there.
Plus I have to log in there, but I’m always logged into GitHub
Yes, what you would have put into the ideas repo on GitHub until very recently should now be collected on Nolt. On GitHub, it wasn’t really possible for us to keep track of most requested features, no real option to vote for users, hence the move to Nolt.
You also cannot expect us to go strictly by votes for upcoming features. We still need to decide in the end what we can realistically build and what does fit into our own vision for Kirby. You are helping us to prioritize with your feedback here.
(That was in reply to a troll comment, but should also reassure you that number of votes is not the only factor).
@S1SYPHOS , these are all things my plugin gives you. Granted, logs location folder is not in site/logs but site/kirbylogs, but everything else is there I believe?
I don’t really see any value in adding this simple logging utility to core, unless core itself can start logging things.
… which is exactly what I am going for. See the feedback thread above. It’s at least something to think about (though I have a feeling @bastianallgeier already did at some point) to provide an interface / uniform root for everything log-like.
In some projects I got 5+ plugins logging stuff all over the place … of course every single one of them could / should let me decide where to save it. It’s worth a discussion I believe, making it a core thing for developers.