Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

Sign up for GitHub

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Jump to bottom

Upgraded to Magento 2.2.4 from Magento 2.1.9 - Locale and Store Configuration issues 'Store View' Locale not being used on frontend, 'Default Config' Locale being used instead #15205

Closed
callumstar opened this issue May 14, 2018 · 18 comments
Closed

Upgraded to Magento 2.2.4 from Magento 2.1.9 - Locale and Store Configuration issues 'Store View' Locale not being used on frontend, 'Default Config' Locale being used instead #15205

callumstar opened this issue May 14, 2018 · 18 comments
Labels
Fixed in 2.2.x The issue has been fixed in 2.2 release line Fixed in 2.3.x The issue has been fixed in 2.3 release line Issue: Format is valid Gate 1 Passed. Automatic verification of issue format passed

Comments

@callumstar
Copy link

Magento multi-store installations aren't using the store view specific values from the Store Configuration if they have been set to be different to the global 'Default Configuration'.

Preconditions

  1. Magento 2.2.4
  2. Multi-storefront installation
  3. PHP 7.0.28

Steps to reproduce

  1. Set global locale in Store Configuration in the admin (e.g. 'English (United Kingdom)')
  2. On one of the individual storefronts in the Magento installation, set locale to be different value to the global (e.g. 'French')
  3. Save configuration and then review frontend.

Expected result

  1. Locale should be using 'fr-FR' and the lang attribute should be set to be 'fr'.
  2. Translations should be using the 'French' locale

Actual result

  1. The frontend shows all storefronts in the global locale ('English') instead of using the storefront specific value.
  2. This means that all different language storefronts use 'English' and not their respective languages.
@magento-engcom-team magento-engcom-team added the Issue: Format is valid Gate 1 Passed. Automatic verification of issue format passed label May 14, 2018
@callumstar
Copy link
Author

Further to the above, we have done some further research and no other language apart from en_GB gets compiled in the 'pub/static/' folder regardless of what language/locale we have set.

@LSERRE
Copy link

LSERRE commented May 15, 2018

I got the same issue in 2.2.4, Default locale configuration is used for all stores view. This issue is really big.

@andy17612
Copy link

andy17612 commented May 15, 2018 •
edited
Loading

I tested others language, like Chinese , Japanese it can showing the language. *But something error on frontend , my theme some file is losed. On english frontend is working.I already changed file 777 . Ran update,compile or static-content:deploy , something are not working still.

@callumstar
Copy link
Author

Hi @magento-engcom-team / @magento-team,

Is there any reponse on this at all? It seems to be a pretty fundamental issue for users with multi-store websites and one that doesn't look to have been tested overly well by yourselves. It looks like the "Default Configuration' is used for all store views when loaded regardless if you have chosen to 'Use Default Values' or not.

I'm seeing similar issues now appear in the Issue Tracker:

@callumstar callumstar mentioned this issue May 16, 2018
Closed
@hostep
Copy link
Contributor

hostep commented May 16, 2018 •
edited
Loading

@callumstar: I tried to reproduce this on a cleanly installed 2.2.4 but couldn't reproduce (sorry, didn't test upgrading from 2.1.9), I performed following steps:

  • Installed Magento 2.2.4 with composer
  • Installed a French language pack using composer: https://github.com/Imaginaerum/magento2-language-fr-fr
  • Ran bin/magento setup:upgrade
  • Changed configuration for locale in 'Default Configuration' to 'en_GB'
  • Changed configuration for locale in the 'Default Store View' to 'fr_FR'
  • Flushed caches
  • Checked frontend in developer mode: frontend was translated in French and found <html lang="fr"> in the html
  • Checked frontend in production mode: frontend was translated in French and found <html lang="fr"> in the html

Can you try to provide clear steps to reproduce the issue (preferably on a clean install of 2.2.4)?

Additional thing you can check, check the files app/etc/config.php and app/etc/env.php and see if they contain a value for locale, because if it is defined in there, it will overwrite the value defined in the database (this is a new feature in Magento 2.2).

@callumstar
Copy link
Author

Hi @hostep,

I did some further digging after your testing and I agree that this changes the locale on the frontend if you change the values for the 'Default' store (the store you have assigned as the default store view).

However, you missed a critical step, you need to have multiple storeviews not just 1 storeview. If you change the values for the 'Default' store then it is fine. I just tested changing the 'Default' storeview and it works as expected (I switched the locale to IT and it changed it to IT) but then tried changing another storeview with the locale of FR and this then kept the IT value.

The issue is with having multiple storefronts not just a single 'Default Store View'.

I did also check the env.php and config.php files and both do not have the locale value set in them.

@LSERRE
Copy link

LSERRE commented May 17, 2018

Yes I agree with @callumstar. Moreover the problems occurs only in production mode I think.

@hostep
Copy link
Contributor

hostep commented May 17, 2018

Ok thanks for the additional information!

I'll do some more testing later on.
If this is turns out to be a new bug, then I don't recommend anyone upgrading to 2.2.4, because it would be a huge problem (issue #15245 also sounds like a complete disaster and will trigger all kinds of unexpected things to happen).

@hostep
Copy link
Contributor

hostep commented May 17, 2018 •
edited
Loading

Alrighty, I was able to reproduce, interestingly enough it only happens when you have multiple websites, if you only have a single website but multiple stores or storeviews, the problem doesn't trigger.

So here are the steps to reproduce:

  1. Setup a clean Magento 2.2.4 installation using composer
  2. Run composer require imaginaerum/magento2-language-fr-fr
  3. Run bin/magento setup:upgrade
  4. Go to Stores => All Stores => Create Website
  5. Name: Non Default Website, Code: non_default_website, Sort order: 10
  6. Go to Stores => All Stores => Create Store
  7. Web Site: Non Default Website, Name: Non Default Store, Code: non_default_store, Root Category: Default Category
  8. Go to Stores => All Stores => Create Store View
  9. Store: Non Default Store, Name: Non Default Store View / Code: non_default / Status: Enabled, Sort Order: 10
  10. Go to Stores => Configuration => General => Web => Url Options
  11. Set 'Add Store Code to Urls' to 'Yes' & Save Config
  12. Go to Stores => Configuration => General => General
  13. Switch to the Store View: 'Non Default Store View'
  14. Change Locale to 'French (France)' & Save Config
  15. Flush all caches
  16. Go to the frontend to http(s)://domainname/default
  17. You'll see everything in English: good expected!
  18. Now go in the frontend to http(s)://domainname/non_default
  19. You'll see everything in English: not good, unexpected, should be French
  20. In the backend, go to Stores => All Stores => Non Default Website
  21. Check 'Set as Default' and Save Web Site
  22. Repeat the frontend testing, and everything is reversed now, both storeviews now show up in French

So basically this is the same issue as reported in #15245, it's only with a different configuration. I tested with a couple of other configurations changed on the non-default storeview and all of them are getting ignored and the ones from the default website are taken.
So this is a huge problem.

Following @jokeputs advice from #15245 to try and see if reverting commit c18e36b also fixes this problem, and yes it does (but this is most likely not the correct way of fixing this).

@magento-engcom-team: this is a very serious issue, I really hope you can prioritise this and make sure it gets fixed in 2.2.5

@jfrontain jfrontain mentioned this issue May 30, 2018
Closed
@hostep hostep mentioned this issue Jun 6, 2018
Closed
fmarangi pushed a commit to fmarangi/magento2 that referenced this issue Jun 7, 2018
magento#15205: Postpone instantiation of session config by using a proxy
d23c198
@fmarangi fmarangi mentioned this issue Jun 7, 2018
Merged
4 tasks
hitesh-wagento pushed a commit to hitesh-wagento/magento2 that referenced this issue Jun 12, 2018
@hitesh-wagento
magento#15205: Postpone instantiation of session config by using a proxy
e935949
This was referenced Jun 12, 2018
Merged
Merged
@hostep hostep mentioned this issue Jun 24, 2018
Closed
@sidolov
Copy link
Contributor

sidolov commented Jun 24, 2018

Hi @callumstar. Thank you for your report.
The issue has been fixed in #15929 by @fmarangi in 2.2-develop branch
Related commit(s):

The fix will be available with the upcoming 2.2.6 release.

@sidolov sidolov added the Fixed in 2.2.x The issue has been fixed in 2.2 release line label Jun 24, 2018
@sidolov sidolov closed this as completed Jun 24, 2018
@hostep
Copy link
Contributor

hostep commented Jun 25, 2018

Let's quote from the PR to provide more accurate info:

fix will be available in 2.2.5 release. The comment above was autogenerated due to delivery to 2.2-develop branch, the changes were delivered to 2.2.5 release line in the separate internal pull request

@orlangur orlangur mentioned this issue Jun 26, 2018
Closed
magento-team pushed a commit that referenced this issue Jun 27, 2018
#15205: Postpone instantiation of session config by using a proxy
031a76b
@VladimirZaets
Copy link
Contributor

Hi @callumstar. Thank you for your report.
The issue has been fixed in #16046 by @hitesh-wagento in 2.3-develop branch
Related commit(s):

The fix will be available with the upcoming 2.3.0 release.

@VladimirZaets VladimirZaets added the Fixed in 2.3.x The issue has been fixed in 2.3 release line label Jul 2, 2018
@EliasKotlyar
Copy link
Contributor

I posted a solution for everyone who are not patient enough to wait until 2.3 here:
#15245

@Ctucker9233
Copy link

Doesn't look like it was shipped out as of 2.2.6 either. The fixed code doesn't appear in 2.2.8. I know code quality is extremely important, but the time to release fixes seems a little ridiculous.

@hostep
Copy link
Contributor

hostep commented Mar 31, 2019

@Ctucker9233: this was definitely fixed in 2.2.5. And 2.2.8 also contains the changes. Are you sure you are talking about the correct problem here? Any steps you can provide to reproduce on 2.2.8?

@Ctucker9233
Copy link

@hostep I'm just comparing code. I don't see this code in any variation in the 2.2.8 code. I'll double check to make sure.

@Ctucker9233
Copy link

@hostep Yes it is there. I just didn't see it. Not an issue then.

@dharmendrak2019
Copy link

Package zendframework/zend-stdlib is abandoned, you should avoid using it. Use laminas/laminas-stdlib instead.
Package zendframework/zend-mime is abandoned, you should avoid using it. Use laminas/laminas-mime instead.
Package container-interop/container-interop is abandoned, you should avoid using it. Use psr/container instead.
Package zendframework/zend-validator is abandoned, you should avoid using it. Use laminas/laminas-validator instead.
Package zendframework/zend-loader is abandoned, you should avoid using it. Use laminas/laminas-loader instead.
Package zendframework/zend-mail is abandoned, you should avoid using it. Use laminas/laminas-mail instead.
Package zendframework/zend-escaper is abandoned, you should avoid using it. Use laminas/laminas-escaper instead.
Package zendframework/zend-uri is abandoned, you should avoid using it. Use laminas/laminas-uri instead.
Package zendframework/zend-diactoros is abandoned, you should avoid using it. Use laminas/laminas-diactoros instead.
Package zendframework/zend-http is abandoned, you should avoid using it. Use laminas/laminas-http instead.
Package zendframework/zend-psr7bridge is abandoned, you should avoid using it. Use laminas/laminas-psr7bridge instead.
Package zendframework/zend-hydrator is abandoned, you should avoid using it. Use laminas/laminas-hydrator instead.
Package zendframework/zend-servicemanager is abandoned, you should avoid using it. Use laminas/laminas-servicemanager instead.
Package zendframework/zend-filter is abandoned, you should avoid using it. Use laminas/laminas-filter instead.
Package zendframework/zend-inputfilter is abandoned, you should avoid using it. Use laminas/laminas-inputfilter instead.
Package zendframework/zend-form is abandoned, you should avoid using it. Use laminas/laminas-form instead.
Package zendframework/zend-eventmanager is abandoned, you should avoid using it. Use laminas/laminas-eventmanager instead.
Package zendframework/zend-code is abandoned, you should avoid using it. Use laminas/laminas-code instead.
Package zendframework/zend-console is abandoned, you should avoid using it. Use laminas/laminas-console instead.
Package zendframework/zend-mvc is abandoned, you should avoid using it. Use laminas/laminas-mvc instead.
Package zendframework/zend-math is abandoned, you should avoid using it. Use laminas/laminas-math instead.
Package zendframework/zend-crypt is abandoned, you should avoid using it. Use laminas/laminas-crypt instead.
Package zendframework/zend-di is abandoned, you should avoid using it. Use laminas/laminas-di instead.
Package zendframework/zend-session is abandoned, you should avoid using it. Use laminas/laminas-session instead.
Package zendframework/zend-db is abandoned, you should avoid using it. Use laminas/laminas-db instead.
Package zendframework/zend-captcha is abandoned, you should avoid using it. Use laminas/laminas-captcha instead.
Package zendframework/zend-barcode is abandoned, you should avoid using it. Use laminas/laminas-barcode instead.
Package guzzlehttp/streams is abandoned, you should avoid using it. No replacement was suggested.
Package guzzlehttp/ringphp is abandoned, you should avoid using it. No replacement was suggested.
Package zendframework/zend-json is abandoned, you should avoid using it. Use laminas/laminas-json instead.
Package zendframework/zend-view is abandoned, you should avoid using it. Use laminas/laminas-view instead.
Package zendframework/zend-text is abandoned, you should avoid using it. Use laminas/laminas-text instead.
Package zendframework/zend-server is abandoned, you should avoid using it. Use laminas/laminas-server instead.
Package zendframework/zend-soap is abandoned, you should avoid using it. Use laminas/laminas-soap instead.
Package zendframework/zend-serializer is abandoned, you should avoid using it. Use laminas/laminas-serializer instead.
Package zendframework/zend-config is abandoned, you should avoid using it. Use laminas/laminas-config instead.
Package zendframework/zend-modulemanager is abandoned, you should avoid using it. Use laminas/laminas-modulemanager instead.
Package zendframework/zend-log is abandoned, you should avoid using it. Use laminas/laminas-log instead.
Package zendframework/zend-i18n is abandoned, you should avoid using it. Use laminas/laminas-i18n instead.
Package zendframework/zend-feed is abandoned, you should avoid using it. Use laminas/laminas-feed instead.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Assignees
No one assigned
Labels
Fixed in 2.2.x The issue has been fixed in 2.2 release line Fixed in 2.3.x The issue has been fixed in 2.3 release line Issue: Format is valid Gate 1 Passed. Automatic verification of issue format passed
Projects
None yet
Milestone
No milestone
Development

No branches or pull requests
10 participants
@hostep @LSERRE @VladimirZaets @EliasKotlyar @sidolov @Ctucker9233 @callumstar @magento-engcom-team @andy17612 @dharmendrak2019