2.2.4: Wrong home page loaded in multi store setup

[jokeputs]

Preconditions

1. Magento 2.2.4
2. Stores > Configuration > General > Web > Url Options > Add Store Code to Urls: Yes
3. Add two websites with each a store view, for example:
   a. An international website with a store view with store code 'international'. This is your default website.
   b. A website for Belgium with a store view with store code 'nl_be'.
4. All websites use the same base url, for example: http://demo.shop.com/
5. Create two CMS pages:
   a. A page that will be the home page for the international store view.
   b. A page that will be the home page for the nl_be store view.
6. Configure the home pages: Stores > Configuration > General > Web > Default Pages > CMS Home Page:
   a. Use the international home page as your default configuration
   b. Set the nl_be home page for the Belgian website

Steps to reproduce

1. Visit the nl_be store view: http://demo.shop.com/nl_be/

Expected result

1. The home page for nl_be will be loaded.

Actual result

1. The home page for international is loaded.

Possible cause

I've already done some debugging and this commit seems to cause the issue: c18e36b.

Because Magento\Framework\Session\Config\ConfigInterface has been added as a constructor argument to Magento\Framework\App\Response\Http, Magento\Framework\Session\Config will be created during the $bootstrap->createApplication() part of pub/index.php:

$bootstrap = \Magento\Framework\App\Bootstrap::create(BP, $params);
/** @var \Magento\Framework\App\Http $app */
$app = $bootstrap->createApplication(\Magento\Framework\App\Http::class);
$bootstrap->run($app);

Next Magento\Framework\Session\Config in its own constructor will call Magento\Framework\App\Config\ScopeConfigInterface to get a configuration value. But the current store has not been determined yet at this point. This will only happen in the $bootstrap->run() part of pub/index.php.

Magento will fallback to the default store and this will cause the $resolvedScopeCodes array in Magento\Framework\App\Config\ScopeCodeResolver to have a wrong value for key null. Which in turn will cause the wrong homepage being loaded for the nl_be store view.

I'm willing to make a pull request for this but I don't see a good solution.

[callumstar]

Hi @jokeputs,

Did you find a temporary workaround for this issue? I'm having a similar issue where the Locale options aren't being set for multi-stores due to this also (see #15205).

[jokeputs]

@callumstar , not yet. If you would undo the changes from commit c18e36b, the right configuration values are loaded but that would be a very hacky workaround.

[LSERRE]

@jokeputs I tried to revert this commit but still got the issue

[gewaechshaus]

@jokeputs @callumstar - do you have any news related to this? We got the same issue in a MCE 2.2.4 store... You can see it in full effect on https://eu.makerdise.com. All links are wrong, some strings also. DAMN.

[callumstar]

Hi @gewaechshaus,

I've heard nothing from @magento-team or @magento-engcom-team regarding this. Somebody has verified this is an issue in the GitHub Issue that I raised (please find it here - #15205), they mentioned that there is a commit that you can do to attempt a fix for it for the time being, so I would suggest trying that.

We've taken the decision to not upgrade to 2.2.4 yet with any sites because of some of these frustrating bugs that have appeared in this version.

[gewaechshaus]

Hi @callumstar,
we could solve this in our case, there seems to be a new config flag "Base Link URL" under General -> Web -> Base URLs which had the default value checked in the related store view. Maybe somebody can verify this...?

[NicoDG]

warning: core hack ahead ;)

I managed to bypass the bug by adding the following in /vendor/magento/framework/Locale/Resolver.php

public function __construct(
        ScopeConfigInterface $scopeConfig,
        $defaultLocalePath,
        $scopeType,
        $locale = null
    ) {
        $this->scopeConfig = $scopeConfig;
        $this->defaultLocalePath = $defaultLocalePath;
        $this->scopeType = $scopeType;

        /* BEGIN DIRTY CORE HACK */
        $objectManager =  \Magento\Framework\App\ObjectManager::getInstance();
        $storeManager = $objectManager->get('\Magento\Store\Model\StoreManagerInterface');
        $localeList = array('en_US', 'nl_NL','fr_FR','en_US');
        $locale = $localeList[$storeManager->getStore()->getStoreId()];
        $this->setLocale($locale);
        /* END DIRTY CORE HACK */

        $this->setLocale($locale);
    }

[sidolov]

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

• d23c198b4a7e9f5237d19e999cb160ac4059e61e
• b0b82d0025d0556e0a05951c54c997f45623015a
• 7e835c3cdecf70cf36c36968d4cd4bac7574b3eb

The fix will be available with the upcoming 2.2.6 release.

[hostep]

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

[VladimirZaets]

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

• e935949d062e45b980c53c997427c15da85dc026
• 69810b7b30a5197d866230c983e816328f647f80
• a8f88315c15622afc7487950a4cdfd2f6e3494d6

The fix will be available with the upcoming 2.3.0 release.

[EliasKotlyar]

Here is a slightly modified version for everyone who dont want to wait until 2.3:
/vendor/magento/framework/Locale/Resolver.php

    /**
     * @param ScopeConfigInterface $scopeConfig
     * @param string $defaultLocalePath
     * @param string $scopeType
     * @param mixed $locale
     */
    public function __construct(
        ScopeConfigInterface $scopeConfig,
        $defaultLocalePath,
        $scopeType,
        $locale = null
    ) {
        $this->scopeConfig = $scopeConfig;
        $this->defaultLocalePath = $defaultLocalePath;
        $this->scopeType = $scopeType;

        /* BEGIN DIRTY CORE HACK */
        $objectManager =  \Magento\Framework\App\ObjectManager::getInstance();
        $storeManager = $objectManager->get('\Magento\Store\Model\StoreManagerInterface');
        $storeConfigManager = $objectManager->get('\Magento\Store\Model\Service\StoreConfigManager');
        $storeCode = $storeManager->getStore()->getCode();
        $storeConfig = $storeConfigManager->getStoreConfigs(array($storeCode));
        $locale = $storeConfig[0]->getLocale();
        /* END DIRTY CORE HACK */




        $this->setLocale($locale);
    }

Its a little bit better than the solution from @NicoDG , because there are no hardcoded stores. Still a bad core hack

[hostep]

@EliasKotlyar

Here is a slightly modified version for everyone who dont want to wait until 2.3

It's already fixed in 2.2.5 😉

Or if you are still on 2.2.4, you can use the official patch available over here: https://magento.com/tech-resources/download (MAGETWO-92926)

[esiemens]

i am still having this problem in 2.2.5, tried the fix mentioned above and there was no affect. does anyone have any ideal of where i should start to fix this?

[jfgalano]

I also have the same problem in 2.2.5, none of the fix mentioned works. thanks for help

[sidolov]

@esiemens , @jfgalano have you cleaned the cache after the upgrade? The fix was made in the configuration and cache should be flushed to take effect.

[melnikovi]

Hello.

@esiemens, @jfgalano did suggestion from @sidolov work for you? Also, could you try to reproduce issue on clean 2.2.5? I just tried and it seem to work. Please let me know.

@EliasKotlyar, @NicoDG, @gewaechshaus, @callumstar, @LSERRE did you by any chance tried to reproduce this issue on 2.2.5?

@jokeputs, @hostep from what I understand the fix in 2.2.5 work for you, but wanted to confirm. Please let me know.

[hostep]

@melnikovi: I tested the fix when it was being developed, but never really tested 2.2.5 itself to see if the issue was actually resolved.
So to be very sure, I just did test 2.2.5 and confirm the issues reported in #15245 & #15205 & #15873 are fixed indeed.

[melnikovi]

Thank you for trying reproduce this issue on 2.2.5 and confirming that it's fixed @hostep.

[jokeputs]

@melnikovi, yes the upgrade to 2.2.5 fixed the issue I had with the home pages.