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.

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

2.2.4: Wrong home page loaded in multi store setup #15245

Closed
jokeputs opened this Issue May 16, 2018 · 19 comments

Comments

Projects
None yet
@jokeputs
Collaborator

jokeputs commented May 16, 2018

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

This comment has been minimized.

callumstar commented May 16, 2018

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

This comment has been minimized.

Collaborator

jokeputs commented May 16, 2018

@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

This comment has been minimized.

LSERRE commented May 16, 2018

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

@gewaechshaus

This comment has been minimized.

gewaechshaus commented May 23, 2018

@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

This comment has been minimized.

callumstar commented May 23, 2018

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

This comment has been minimized.

gewaechshaus commented May 23, 2018

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

This comment has been minimized.

NicoDG commented May 24, 2018

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

This comment has been minimized.

Contributor

sidolov commented Jun 24, 2018

Hi @jokeputs. 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.

@hostep

This comment has been minimized.

Collaborator

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

@VladimirZaets

This comment has been minimized.

Contributor

VladimirZaets commented Jul 2, 2018

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):

The fix will be available with the upcoming 2.3.0 release.

@EliasKotlyar

This comment has been minimized.

Contributor

EliasKotlyar commented Jul 23, 2018

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

This comment has been minimized.

Collaborator

hostep commented Jul 23, 2018

@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

This comment has been minimized.

esiemens commented Jul 25, 2018

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

This comment has been minimized.

jfgalano commented Jul 26, 2018

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

@sidolov

This comment has been minimized.

Contributor

sidolov commented Aug 7, 2018

@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

This comment has been minimized.

Member

melnikovi commented Aug 10, 2018

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

This comment has been minimized.

Collaborator

hostep commented Aug 11, 2018

@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

This comment has been minimized.

Member

melnikovi commented Aug 11, 2018

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

@jokeputs

This comment has been minimized.

Collaborator

jokeputs commented Aug 14, 2018

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

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment