Is Symlink needed when upgrading from 9.1 to 9.1.3?

[Forni-ice]

Running on 9.1 and I want to upgrade to 9.1.3. Do I need Symlink enabled? Or Can I go ahead and upgrade wit out it?

It is not possible to enable Symlink my host tells me and did read somewhere that Symlink was needed for the upgrade?
Is there a way past this?

Server software version: LiteSpeed
PHP version: 8.3.8
Memory limit: 1024M
Max execution time: 300
Upload Max File size: 256M
MySQL version: 10.11.6-MariaDB-0+deb12u1-log
PrestaShop version: 9.1.0
PrestaShop distribution: classic
PrestaShop distribution version: 4.0
Current theme in use: hummingbird

[kpodemski]

I don't think it is required anymore. Let me ping @Quetzacoalt91, who will know better! :)

[Quetzacoalt91]

No it's not mandatory anymore. It used to be on PrestaShop 9.0.0 and 9.0.1. :)

[kpodemski]

@Forni-ice, could you let us know more about the error you encountered?

[Forni-ice]

Thank you for your reply. It is greatly appreciated. I have not upgraded yet. Instead I installed a test version of 9.1.3 on the same server. The install went fine. So I think an Upgrade to a live store is okay. My host is pretty strict on the .php but I will check if he allows Symlink under maintenance for a short time. That is a good Idea. I am doing a backup of everything now and will test things this week. Best regards Asgeir

…

On Mon, 1 Jun 2026 at 19:31, Hassan Sardar ***@***.***> wrote: Short answer: for a *9.1.0 → 9.1.3* patch upgrade, you usually do *not* need symlink support on the server the same way as a major jump to 9.0.x. What symlink is used for PrestaShop (and the 1-Click Upgrade / Update Assistant module) may create *symbolic links* for Symfony assets under admin-dev/bundles/ during install/upgrade/finalize steps. If PHP symlink() is disabled, older upgrade flows could fail or warn. Core has been improved so that when symlinks are unavailable, it can fall back to *hard copies* instead (see core fixes around install/finalize and assets:install). That is why many shops on shared hosting (LiteSpeed included) still run without enabling symlink. For your case (9.1 → 9.1.3) - This is a *minor/patch* upgrade within PS 9.1, not 8.x → 9.x. - Your stack (PHP 8.3, MariaDB 10.11) looks compatible. - If your host cannot enable symlink, you can still try the upgrade, but: 1. *Full backup* (files + DB) first. 2. Use the *latest autoupgrade / Update Assistant* module from the marketplace. 3. If the upgrader shows a symlink error, check whether the module version supports the no-symlink fallback (newer core + module combinations handle this better than older 7.x module builds). Workarounds if symlink stays disabled 1. Upgrade on a *staging/VPS* where you control PHP (symlink enabled), then deploy the upgraded files + DB to production. 2. *Manual upgrade* following the official docs (replace core files, run upgrade CLI), then run post-upgrade cache clear and BO checks. 3. Ask the host to enable symlink *only during maintenance* if they allow temporary changes. Practical recommendation Do *not* block yourself only because symlink is disabled—test on staging first. If 9.1.3 upgrade completes and admin-dev/bundles/ contains the expected folders (or copies), you are fine. If you hit a specific error message from the upgrader, paste it here and we can map it to symlink vs another requirement (permissions, memory, module incompatibility). — Reply to this email directly, view it on GitHub <#41563?email_source=notifications&email_token=BJ5Q2HVL5L6VRDDF42JHR6T45XK23A5CNFSNUABIM5UWIORPF5TWS5BNNB2WEL2ENFZWG5LTONUW63SDN5WW2ZLOOQXTCNZRGQYTEMBSUZZGKYLTN5XKO3LFNZ2GS33OUVSXMZLOOSWGM33PORSXEX3DNRUWG2Y#discussioncomment-17141202>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/BJ5Q2HTGD74JB35ISUOX7JD45XK23AVCNFSM6AAAAACZQW5CGCVHI2DSMVQWIX3LMV43URDJONRXK43TNFXW4Q3PNVWWK3TUHMYTOMJUGEZDAMQ> . Triage notifications, keep track of coding agent tasks and review pull requests on the go with GitHub Mobile for iOS <https://github.com/notifications/mobile/ios/BJ5Q2HUYDONNZVHHRVWLNX345XK23A5CNFSNUABIM5UWIORPF5TWS5BNNB2WEL2ENFZWG5LTONUW63SDN5WW2ZLOOQXTCNZRGQYTEMBSUZZGKYLTN5XKO3LFNZ2GS33OUVSXMZLOOSVGM33PORSXEX3JN5ZQ> and Android <https://github.com/notifications/mobile/android/BJ5Q2HUL2MTANGH73EYZMWD45XK23A5CNFSNUABIM5UWIORPF5TWS5BNNB2WEL2ENFZWG5LTONUW63SDN5WW2ZLOOQXTCNZRGQYTEMBSUZZGKYLTN5XKO3LFNZ2GS33OUVSXMZLOOSXGM33PORSXEX3BNZSHE33JMQ>. Download it today! You are receiving this because you were mentioned.Message ID: ***@***.*** com>

[Forni-ice]

To continue and keep you updated. The Upgrade is done and went well. However a lot of translation strings are changed and some from Creative Elements Page builder and some randomly through out the store. I contacted CE and they told me to tell you about this issue. Their words "The issue is coming from your native PrestaShop."

…

On Tue, 2 Jun 2026 at 17:29, Ásgeir Sæm ***@***.***> wrote: Thank you for your reply. It is greatly appreciated. I have not upgraded yet. Instead I installed a test version of 9.1.3 on the same server. The install went fine. So I think an Upgrade to a live store is okay. My host is pretty strict on the .php but I will check if he allows Symlink under maintenance for a short time. That is a good Idea. I am doing a backup of everything now and will test things this week. Best regards Asgeir On Mon, 1 Jun 2026 at 19:31, Hassan Sardar ***@***.***> wrote: > Short answer: for a *9.1.0 → 9.1.3* patch upgrade, you usually do *not* > need symlink support on the server the same way as a major jump to 9.0.x. > What symlink is used for > > PrestaShop (and the 1-Click Upgrade / Update Assistant module) may create *symbolic > links* for Symfony assets under admin-dev/bundles/ during > install/upgrade/finalize steps. If PHP symlink() is disabled, older > upgrade flows could fail or warn. > > Core has been improved so that when symlinks are unavailable, it can fall > back to *hard copies* instead (see core fixes around install/finalize > and assets:install). That is why many shops on shared hosting (LiteSpeed > included) still run without enabling symlink. > For your case (9.1 → 9.1.3) > > - This is a *minor/patch* upgrade within PS 9.1, not 8.x → 9.x. > - Your stack (PHP 8.3, MariaDB 10.11) looks compatible. > - If your host cannot enable symlink, you can still try the upgrade, > but: > 1. *Full backup* (files + DB) first. > 2. Use the *latest autoupgrade / Update Assistant* module from the > marketplace. > 3. If the upgrader shows a symlink error, check whether the module > version supports the no-symlink fallback (newer core + module combinations > handle this better than older 7.x module builds). > > Workarounds if symlink stays disabled > > 1. Upgrade on a *staging/VPS* where you control PHP (symlink > enabled), then deploy the upgraded files + DB to production. > 2. *Manual upgrade* following the official docs (replace core files, > run upgrade CLI), then run post-upgrade cache clear and BO checks. > 3. Ask the host to enable symlink *only during maintenance* if they > allow temporary changes. > > Practical recommendation > > Do *not* block yourself only because symlink is disabled—test on staging > first. If 9.1.3 upgrade completes and admin-dev/bundles/ contains the > expected folders (or copies), you are fine. > > If you hit a specific error message from the upgrader, paste it here and > we can map it to symlink vs another requirement (permissions, memory, > module incompatibility). > > — > Reply to this email directly, view it on GitHub > <#41563?email_source=notifications&email_token=BJ5Q2HVL5L6VRDDF42JHR6T45XK23A5CNFSNUABIM5UWIORPF5TWS5BNNB2WEL2ENFZWG5LTONUW63SDN5WW2ZLOOQXTCNZRGQYTEMBSUZZGKYLTN5XKO3LFNZ2GS33OUVSXMZLOOSWGM33PORSXEX3DNRUWG2Y#discussioncomment-17141202>, > or unsubscribe > <https://github.com/notifications/unsubscribe-auth/BJ5Q2HTGD74JB35ISUOX7JD45XK23AVCNFSM6AAAAACZQW5CGCVHI2DSMVQWIX3LMV43URDJONRXK43TNFXW4Q3PNVWWK3TUHMYTOMJUGEZDAMQ> > . > Triage notifications, keep track of coding agent tasks and review pull > requests on the go with GitHub Mobile for iOS > <https://github.com/notifications/mobile/ios/BJ5Q2HUYDONNZVHHRVWLNX345XK23A5CNFSNUABIM5UWIORPF5TWS5BNNB2WEL2ENFZWG5LTONUW63SDN5WW2ZLOOQXTCNZRGQYTEMBSUZZGKYLTN5XKO3LFNZ2GS33OUVSXMZLOOSVGM33PORSXEX3JN5ZQ> > and Android > <https://github.com/notifications/mobile/android/BJ5Q2HUL2MTANGH73EYZMWD45XK23A5CNFSNUABIM5UWIORPF5TWS5BNNB2WEL2ENFZWG5LTONUW63SDN5WW2ZLOOQXTCNZRGQYTEMBSUZZGKYLTN5XKO3LFNZ2GS33OUVSXMZLOOSXGM33PORSXEX3BNZSHE33JMQ>. > Download it today! > You are receiving this because you were mentioned.Message ID: > ***@***.*** > com> >

[Forni-ice]

So, before upgrading, I asked CE to clarify if the software was 9.1.3. ready, and they said it was. I have cleared the Performance Cache a few times after each change. I don't have access to the Symfony cache Let's take Product Comments (Reviews) / ModulesProductcommentsShop I see in my is-IS folder that files have changed and are now not translated. That shows when I open the ModulesProductcommentsShop.is-IS.xlf In the ACP International > Translations under Installed Module translations, my translations for this module are blank. Now if I translate the default ModulesProductcommentsShop.xlf and upload it, I see the changes immediately in the ACP International > Translations under Installed Module translations. However, if I clear the Performance Cache I do not see the changes on my site?

[Forni-ice]

Thank you for your great explanation. Can you tell me if version 9.1.3 added any translation strings and if so do you have a list of altered files? Regards

…

On Thu, 4 Jun 2026 at 11:39, Hassan Sardar ***@***.***> wrote: You’ve narrowed it down well. What you’re seeing matches how PrestaShop 9 handles translations: the Back Office translation screen and the storefront do not use the same source, and Performance cache is not the translation cache. What’s going on with Product Comments (ModulesProductcommentsShop) PrestaShop keeps three layers for module strings: Layer | Where it lives | What you see -- | -- | -- Default (reference) | translations/default/ModulesProductcommentsShop.xlf | Source wording for the BO editor Locale files | translations/is-IS/ModulesProductcommentsShop.is-IS.xlf and/or modules/productcomments/translations/is-IS/... | Pack shipped with core/module Your overrides | ps_translation in the database | What International → Translations → Installed module translations normally shows After the upgrade: 1. is-IS XLF files were replaced with a new pack (often English or empty targets) → files “changed and not translated”. 2. Your DB overrides for that module are blank → the “Installed module translations” screen has nothing saved for you anymore. 3. Editing/uploading the *default* .xlf updates what the BO editor shows for the reference catalogue — not automatically what the front office reads. So CE saying “it’s native PrestaShop” is partly fair for the upgrade wiping/replacing packs and DB overrides; it doesn’t explain why your fix appears in BO but not on the site. Why BO shows changes but the site does not Performance cache (BO button) mainly clears Smarty page cache. It does not reliably clear: - Symfony translator cache under var/cache/... - Compiled catalogues under var/cache/translations / cache/translations (depending on setup) - LiteSpeed full-page cache (common on LiteSpeed hosting) The front office loads translations roughly like this: 1. Core translations/is-IS/*.xlf (Shop domains, not Admin) 2. Theme themes/hummingbird/translations/is-IS/ if present 3. Module modules/productcomments/translations/is-IS/ ModulesProductcommentsShop.is-IS.xlf 4. Database overrides from ps_translation (your saved BO edits) It does not use translations/default/... on the live shop. So if you only change the default file in the BO tool, you fix the editor preview, not necessarily the runtime files the FO uses. What to do (in order)1. Fix the locale file, not only the default file On the server, check these paths (FTP / file manager): translations/is-IS/ModulesProductcommentsShop.is-IS.xlf modules/productcomments/translations/is-IS/ModulesProductcommentsShop.is-IS.xlf themes/hummingbird/modules/productcomments/translations/ (if it exists) Put your Icelandic text in the is-IS files (correct target-language / translated <target> nodes), not only in translations/default/. After upgrade, the module folder copy is often the one the FO actually picks up. 2. Save overrides in the database (BO) In International → Translations → Installed module translations: 1. Module: Product Comments 2. Language: Icelandic (is-IS) 3. Translate strings there 4. Save (so rows go into ps_translation) Blank screen = no DB overrides left; re-saving is the proper fix for merchant-specific wording. 3. Clear caches without Symfony CLI If you only have BO + FTP: 1. BO: Advanced Parameters → Performance → Clear cache (you already did) 2. FTP: delete contents of (with shop in maintenance mode): - var/cache/prod/ (entire folder contents, not the folder itself if the app recreates it) - var/cache/dev/ if present 3. Also clear Smarty if separate: - var/cache/ Smarty dirs, or cache/smarty/cache/ and cache/smarty/compile/ on older layouts 4. LiteSpeed: purge all cache in the hosting panel / .htaccess LSCache purge — this is often why FO still shows old text after BO changes That is the “Symfony cache” equivalent when you don’t have SSH. 4. Confirm language is active International → Languages: is-IS enabled, correct locale is-IS, assigned to the shop. 5. Export/import the right pack (optional) International → Translations → Export language Export Installed module translations for is-IS / Product Comments, edit XLF, re-import — or use Modify translations and save to DB. Do not rely only on uploading the default catalogue file. Quick test for one string Pick one visible FO string (e.g. “Write your review”): 1. Change it in Installed module translations and Save. 2. Purge var/cache/prod + LiteSpeed. 3. Hard-refresh the product page (private window). - If it updates → problem was cache / wrong file layer. - If it stays wrong → FO is still reading modules/.../is-IS/*.xlf or theme overrides; update those files. — Reply to this email directly, view it on GitHub <#41563?email_source=notifications&email_token=BJ5Q2HRTBEKYVBK7E656COL46FNYPA5CNFSNUABIM5UWIORPF5TWS5BNNB2WEL2ENFZWG5LTONUW63SDN5WW2ZLOOQXTCNZRHAYDANJSUZZGKYLTN5XKO3LFNZ2GS33OUVSXMZLOOSWGM33PORSXEX3DNRUWG2Y#discussioncomment-17180052>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/BJ5Q2HS73QB5ENUVS47ZHBD46FNYPAVCNFSM6AAAAACZQW5CGCVHI2DSMVQWIX3LMV43URDJONRXK43TNFXW4Q3PNVWWK3TUHMYTOMJYGAYDKMQ> . Triage notifications, keep track of coding agent tasks and review pull requests on the go with GitHub Mobile for iOS <https://github.com/notifications/mobile/ios/BJ5Q2HRDLDPZC5I7UK4RQPL46FNYPA5CNFSNUABIM5UWIORPF5TWS5BNNB2WEL2ENFZWG5LTONUW63SDN5WW2ZLOOQXTCNZRHAYDANJSUZZGKYLTN5XKO3LFNZ2GS33OUVSXMZLOOSVGM33PORSXEX3JN5ZQ> and Android <https://github.com/notifications/mobile/android/BJ5Q2HV5ALSA5BLF77BLHXT46FNYPA5CNFSNUABIM5UWIORPF5TWS5BNNB2WEL2ENFZWG5LTONUW63SDN5WW2ZLOOQXTCNZRHAYDANJSUZZGKYLTN5XKO3LFNZ2GS33OUVSXMZLOOSXGM33PORSXEX3BNZSHE33JMQ>. Download it today! You are receiving this because you were mentioned.Message ID: ***@***.*** com>

[HassanSardar1]

List of altered files (9.1.1 → 9.1.2 / 9.1.0 → 9.1.3)