Update from 6.5.0 to 6.5.2 language file nog working any more

  • Posts: 636
  • Thank you received: 26
  • Hikaserial Subscription Hikashop Multisite
1 day 23 hours ago #372902

-- HikaShop version -- : 6.5.2
-- Joomla version -- : 6.1.2
-- PHP version -- : 8.3

Hi Support,

After updating HikaShop from 6.5.0 to 6.5.2, the translations are no longer
loading anywhere in the back-end. Instead of the normal texts we now see the
raw language keys everywhere (for example SHOW_FOOTER, IMAGE_POPUP_MODE,
USE_CHOSEN, and even the update notice itself shows as
UPDATE_LANGUAGE / LOAD_LATEST_LANGUAGE). A screenshot is attached.

The important point: the Dutch language file is definitely present and
installed. We have verified this:

- In HikaShop > System > Configuration > Languages, Dutch (nl-NL) is listed
as installed. When we open it with the Edit icon, the full list of
translated strings is shown, so the file exists and is filled.
- Via FTP the file nl-NL.com_hikashop.ini is present and not empty, in both
/language/nl-NL/ and /administrator/language/nl-NL/.
- The files and folders have the correct read permissions.

What we have already tried, without any result:
- Reinstalled the HikaShop 6.5.2 package over the existing installation.
- Clicked "Load latest from server" for the Dutch language and saved.
- Cleared the Joomla cache.

So the nl-NL file is present, but HikaShop keeps showing the untranslated
keys after the update. Could you tell us what can cause the language file not
to be loaded, and how to solve it?





Kind regards,
Lumiga

Kind regards,
Lumiga
Attachments:

Please Log in or Create an account to join the conversation.

  • Posts: 85985
  • Thank you received: 14149
  • MODERATOR
1 day 19 hours ago #372906

Hi,

The Dutch translation itself is fine. We checked the nl-NL file our translation server delivers, and the one in our repository: both parse without any error, and so do the language files inside the 6.5.2 package. So the raw keys do not come from a broken file on our side.

What your screenshot shows is what happens when Joomla ends up with zero strings for HikaShop, which is why you get the keys instead of Dutch and instead of English. Since Joomla 5.2, each language ini file is parsed once and the result is stored in a cache file under administrator/cache/language, named after the ini file and its modification date. If that cache entry was created while the file was being replaced during the update, it holds an empty list of strings, and it keeps being used until the ini file gets a new modification date. We reproduced exactly your screenshot that way here.

So please try this first:

- with FTP, delete everything inside administrator/cache/language (and inside cache/language if that folder exists)
- reload your HikaShop backend

Note that the Clear Cache tool of Joomla defaults to the Site cache and does not clean that folder, which is why clearing the cache did not help.

If the Dutch texts do not come back, then one of the two files really fails to parse, and Joomla can tell us which line. Set System > Global Configuration > System > Debug Language to Yes, open a HikaShop page in your backend, and look at the bottom of the page: Joomla lists there the language files it could not parse, with the line number. Send us that and we will tell you what to correct.

One last thing worth checking: make sure /language/nl-NL/ does not contain a file named com_hikashop.ini without the nl-NL prefix. Joomla 6 loads that name first, and if such a file is there and is empty, your real translation is never read.

Please Log in or Create an account to join the conversation.

  • Posts: 636
  • Thank you received: 26
  • Hikaserial Subscription Hikashop Multisite
1 day 9 hours ago #372912

Hi Nicolas,

Thank you, that pointed us in the right direction. Here is what we found.

First a correction to our original post: our back-end runs in English (en-GB), so the file that matters here is en-GB.com_hikashop.ini, not the nl-NL one. Apologies for the confusion.

We followed your steps:

1. Via FTP we deleted everything inside administrator/cache/language (there was no cache/language folder). After reloading the back-end, the raw keys
were still there.

2. We set Global Configuration > System > Debug Language to Yes and opened a HikaShop back-end page. In the "Language files loaded" list, com_hikashop is not loaded from any location - all four candidate paths are marked as not found, while com_hikashop.sys loads fine. The full "Loaded" and "Untranslated" exports are attached (two .txt files).

3. That made us check the folder administrator/language/en-GB itself over FTP: and the en-GB.com_hikashop.ini is simply not there. The folder only contains en-GB.com_hikashop.sys.ini (4.8 KB) plus a few plugin language files (screenshot 5 attached).


So this is not a stale/empty cache entry - the main .ini was never present on disk. We also confirmed there is no unprefixed com_hikashop.ini in /language/en-GB/ or /language/nl-NL/. See screensho 6.



4. We then checked the Apache error log and found this repeatedly, from our host's (Combell) ModSecurity firewall, on back-end requests:
ModSecurity: Rule ... [id "35013"] ... Execution error - PCRE limits exceeded (-8): (null). [hostname "123spoedopleiding.nl"] [uri "/administrator/index.php"]

The firewall aborts the request when that rule exceeds its PCRE match limit while scanning the content (so it is not a byte-size limit as such).
Our reading is that this interrupted the writing of en-GB.com_hikashop.ini during the update: the small en-GB.com_hikashop.sys.ini has today's date, but the main .ini was never written.

Fix: we extracted en-GB.com_hikashop.ini from the 6.5.2 package and uploaded it manually via FTP to administrator/language/en-GB/. The back-end shows all texts again.

What we do not understand yet, and would value your view on:

On 6.5.0 everything worked, so en-GB.com_hikashop.ini was present and correct before the update. The update must therefore have replaced it. So:

- During the update (or the "load latest language" step), does HikaShop write/refresh this language file through an admin HTTP request to
/administrator/index.php? That is the request our firewall aborts.

- During that process, does HikaShop first delete or empty the existing .ini before writing the new one? If the delete succeeds but the write is then
aborted by our firewall, that would explain why the file was completely gone instead of just outdated.

Since a disk write was aborted here without any visible error, we realise other files could in theory have been affected too. We understand the real
fix is on our side - getting our host (Combell) to stop its firewall from aborting these requests - and we are taking that up with them.

Our only remaining question for you: apart from the language files, does the update (or the automatic language refresh) write any other files to disk through the back-end / an HTTP request? In other words, is checking and restoring the HikaShop / HikaSerial language files via FTP enough to be sure
the installation is complete, or are there other files written the same way that we should verify?

Kind regards,
Lumiga

Kind regards,
Lumiga
Attachments:
Last edit: 1 day 9 hours ago by Lumiga.

Please Log in or Create an account to join the conversation.

  • Posts: 85985
  • Thank you received: 14149
  • MODERATOR
1 day 5 hours ago #372915

Hi,

The update only update the en language file, and it does it automatically on the server side, so a modSecurity should have no influence over it.
Other languages are not included and need to be updated manually via the "Load latest version from our server" button of the language file edit screen. This manually process goes through the browser, and thus ModSecurity can block it. But blocking it shouldn't result in the file already there being deleted.
So, in short, I'm still not clear on how this could have happened.

Please Log in or Create an account to join the conversation.

Time to create page: 0.603 seconds
Powered by Kunena Forum