I tried the same procedure on my local VM and it worked just fine.
Also, I made a new translation and then upgraded to the latest tag from branch 1.6, cleared cache, etc… and the translation was applied.
After that I created a new translation and got the same problem as before… can this be a filesystem permission problem? Where are this translations stored?
Ok, it seems I found the answer to my problem: restarting php-fpm did the trick… so I guess the cache is stored in APC or something like that, right? Is there a setting to be altered for this?
Thanks
Edit: in order to have the cache updated I need to use the button “Update cache” and then re-start php-fpm.
This reply was modified 5 years, 2 months ago by Mauro Chojrin. Reason: Added more context
Hi Mauro, We are not using APC. By default everything cached in files and OpCache can be used for internal PHP cache. Clicking “Update Cache” button should be enough, if it’s required to restart php-fpm then it’s probably a bug.
Please describe steps to reproduce, what translations you updated and we’ll try to reproduce it locally. And share your configuration for opcache from <?php phpinfo() (not from CLI, because configuration can be different for CLI and php-fpm). Thank you.
Just check it after updating to 3.1 and I can still see the same problem.
Steps to reproduce:
1 – Open the translation panel (/admin/translation/) 2 – Filter by target language (In my case es_AR) 3 – Filter by translated: No 4 – Enter translation into “Translated value” field and save 5 – Update cache 6 – Symptom: CURRENT (CACHED) VALUE is not updated 7 – Restart php-fpm 8 – Reload page 9 – CURRENT (CACHED) VALUE is updated correctly
About the phpinfo:
Shell
1
2
3
Thisprogram makes useof the Zend Scripting Language Engine:
The issue is in opcache configuration. Translation cache is stored in php files. And not only translations are broken. You also will have issues with custom entities and fields added from UI. you have the setting opcache.validate_timestamps Off Off that means when files are updated – you will not get an update.
To solve an issue you have 2 options here: 1) enable opcache.validate_timestamps option 2) configure blacklist file for opcache
At first glance I’d say I could go either way… I guess the first option it’s more of a “set and forget” kind and the second will require me to update such config every time a new type of object needs to be left out… would you say there’s a big performance hit in taking the first approach?
We collect cookie information with a goal to provide you with the best user experience. By using this website, you agree to our use of cookies. Read Oro Inc.’s Cookie policy.
We collect cookie information with a goal to provide you with the best user experience. By using this website, you agree to our use of cookies. Read Oro Inc.’s Cookie policy.