Cache for non Elements

[Anubarak]

Support Request

First of all, thank you very much for your awesome plugin. Under the hoods this is really special and you've done a great job.

I tried to find an easy/fast solution for our use-case but it was either way too much work or not that good. We usually work with yii\i18n\DbMessageSource https://www.yiiframework.com/doc/api/2.0/yii-i18n-dbmessagesource that means we save our translations in the Database and provide an area in the CP to allow our clients to change those.

That means we have custom records and a custom table to store translations. Obviously the cache of those won't be busted automatically so we have to find a way to bust it on our own and we have two solutions:

• re-creating your entire element handling to make it fit for custom records so the cache is properly busted when a record changes (ton of work)
• bust the entire cache (fast but not elegant)

Have you ever had such a use-case / can you think about an easier solution? I am open for any solution and having to extend your plugin won't be an issue I just wanted to avoid too much work if you could think about a better solution.

Thank you very much

Plugin Version

No response

[bencroker]

Thanks for the kind words, Robert!

Blitz has the concept of cache tags that could work well for your use-case. You’d just need to figure out what combination of translations to use per page.

Here’s what it might look like in the template.

{% set translationIds = <an array of translation IDs used on this page> %}
{% do craft.blitz.options.tags(translationIds) %}

And any time a translation is modified, you can have Blitz invalidate the tagged pages as follows.

$translationIds = <an array of modified translation IDs>;
Blitz::$plugin->refreshCache->refreshCacheTags($translationIds);

[Anubarak]

Hey Ben :)

Thank you very much for your fast answer - it works totally fine 👍 Your cache busting mechanisms are really good. At the first glance (few months ago) I was a little bit sceptical if everything will work when we use more complex queries / revert relations / difficult scenarios but everything worked great and especially with the ability to define custom tags we'll use your plugin way more often.

Thx again

[bencroker]

Glad to hear that works for your use-case!

I forgot to mention it earlier, but you probably figured out that the translation IDs should ideally be namespaced. Something like <siteId>:<translationId> would likely work well as a cache tag format.