Flush is not flushing languages files

[lekoala]

Hello,

I've ran into a strange issue.

Usually, when I use ?flush=1 it flushes my translation. But I'm running a project where this does not happen.

I've tracked the issue down the issue to theses line in the i18n class:

public static function flush() {
    $cache = self::get_cache();
    $backend = $cache->getBackend();

    if(
        $backend instanceof Zend_Cache_Backend_ExtendedInterface
        && ($capabilities = $backend->getCapabilities())
        && $capabilities['tags']
    ) {
        $cache->clean(Zend_Cache::CLEANING_MODE_MATCHING_TAG, $cache->getTags());
    } else {
        $cache->clean(Zend_Cache::CLEANING_MODE_ALL);
    }
}

Basically, it seems that when using tags, the cache is not flushed. If I replace with CLEANING_MODE_ALL, it all works fine.

So I'm not sure if it's because the "getTags" method doesn't return the proper tags, or if the clean by tag mode is not working as it should.

Templates and everything else are working just fine, it seems to happen only for languages files.

any thoughts?

[kinglozzer]

Hi @lekoala,

Are you setting up a custom cache, either specifically for i18n or as a “default”? I just tested on 3.1.12 with the default cache setup (file) and it seems to be clearing the cache as expected

[lekoala]

Well, it's still happening there. Obvious ways to make it work are:

• disabling cache (set default lifetime to -1)
• deleting content of the cache directory
• use the CLEANING_MODE_ALL

However, sometimes it does work. I'm wondering if this could be due to the fact that I'm overriding some translations in mysite/lang (for instance, I have in /module/lang an entity that will be partially overrided in mysite) and that for some reason, it doesn't refresh the combined array properly.

Not really sure what's happening there.

[lekoala]

Ok ! Now I know what's precisely happening.

Working scenario:
You override some entity in mysite/lang, you change the translation, you flush, the translation is updated, yay

Not working scenario:
You change some translation in mymodule/lang (it doesn't matter if they are overriden or not, as long as some of them are overriden in mysite/lang), you go to another page (not sure if this step makes a difference or not), you flush, nothing happens (probably because it takes mysite/lang as the reference). Try updating mysite/lang with some new options, flush is not working anymore. It seems that the cache is in some strange state that doesn't clear with tags (CLEANING_MODE_ALL working just fine) anymore.

If anyone knows a way to simple override current behaviour to use CLEANING_MODE_ALL instead of the one with tags, I would be very happy (SS_Cache factory is not using injector so I don't see any obvious way to do this).

[chillu]

@kinglozzer This is coming from your commit in 570f261 and the associated pull request in #3558. Can you provide some insight here? Haven't had the time to give it much thought. Just some observations:

• By default, Zend_Translate_Adapter::$_cacheTags is set to false, so I don't think we're actually using tags here.
• From memory, the issue with tags on the default Zend_Cache_Backend_File adapter is that on every cache operation (read, write, delete) a separate metadata file is involved to store and retrieve caches, which slows down the operation. Check out Zend_Cache_Backend_File->_clean() for the gory details.

[kinglozzer]

@chillu The original issues we had were around caches overzealously clearing things: when you use a named Zend_Cache_Backend_File, using CLEANING_MODE_ALL will wipe all data from all caches - not just the single named cache you’re trying to clear. So running a flush would clear all file-based SS_Cache instances too - which isn’t necessarily desirable.

Tags are automatically enabled if the cache that’s passed to Zend_Translate_Adapter supports them: we set the cache here, which then triggers a method that detects tag support here. My PR #3558 used the same method to check if tags are supported by the cache and (should) react accordingly. I’ve just tried quickly debugging some methods in Zend_Translate_Adapter and my quick tests indicate that tags are definitely enabled when using the default file-based cache.

I’ll have a play around with the steps described above and see if I can recreate this and track it down.

@lekoala If this is causing you problems you can’t work around, in the mean-time you could do something like this in _config.php:

if(isset($_GET['flush'])) {
    i18n::get_cache()->clean(Zend_Cache::CLEANING_MODE_ALL);
}

[lekoala]

Hi @kinglozzer !
Your snippet does the job indeed! Thanks!

I've tested again, it's a very strange issue. As long as I stay on the same page, I can flush and everything refresh correctly.
If I navigate to another page, go back and then try to flush, it's not flushing (while flushing with CLEANING MODE ALL always work).

Tags are indeed enabled for file based cache.

[wernerkrauss]

@lekoala had a big issue with my lang files today. For me it was unescaped umlauts in the lang file (though inside quotes). A line like:

    db_PublishFrom: 'Veröffentlichungsdatum'

broke the whole lang for that module. changing ö to ö helped immediatly.

Did you have similar files with unescaped umlauts?

[lekoala]

Although I have some translations in german, I'm mostly writing in french so maybe there is something with accentuated characters, I don't know for sure, it's hard to diagnose.

I'm using kinglozzer solution for now and everything works fine, it's not like you change translation everyday anyway and flushing a few more files is no big deal.

[chillu]

We've replaced the Zend_Translate backend with symfony/translate in 4.x, and I've confirmed this no longer happens for me: #6221. Modifying a translation string and reloading the CMS with ?flush=all brings up the new translation in the UI