Website Specific Shipping Methods are not working after upgrade 2.1.2=>2.1.3
netzweltvimal opened this issue · 26 comments
Preconditions
- 2.1.3
Steps to reproduce
- Set Different Shipping Methods for Multi Website
Expected result
- Shipping Method should be appear according to website
Actual result
- Not showing according to Website Shipping Method which is set in Admin=> Shipping Methods
- Some time fetal error "Shipping Address Not Set" on Cart and Checkout page
- Default Config Shipping Methods are showing , not Website Specific.
Looks like Website Level Configurations are not working at all..
We noticed this problem during base url setup as well.. we had setup base url at store level of each website.
But in case of shipping method, there is no option to enable /disable shipping method at store level. we can only set it at website level. So when we set the shipping methods at website level, it doesn't work.. it is always picking the shipping methods from default config.
Conclusion: Website Level Configurations are not working and it falls back to default config UNLESS there is any override at store level.
Website Level Configurations are not working and it falls back to default config UNLESS there is any override at store level.
Confirm.
Same for me
Try removing your configuration in the core_config_data table and then set is again via magento, this did the trick for us with themes: #7841
The problem is here Magento\Store\Model\Config\Processor\Fallback::getWebsiteConfig().
This line $code = $website['website_id']; should be replaced with $code = $website['code'];
As a workaround you can create your own module and extend the Fallback class using di.xml, but since almost all methods and properties has a 'private' scope, you will need to override them all.
@alexpoletaev can you be more specific,
This is what I have changed so far:
private function getWebsiteConfig(array $websites, $id) { foreach ($this->websiteData as $website) { if ($website['website_id'] == $id) { $code = $website['code']; return isset($websites[$code]) ? $websites[$code] : []; } } return []; }
Thanks
@abi2, you did the right thing.
@alexpoletaev still not working for me, any need to recompile?
Thanks
@alexpoletaev where is this file ?
@salelsol vendor/magento/module-store/Model/Config/Processor/Fallback.php
@alexpoletaev afther change file this modification works fine in all 3 multiwebsite frontend, but I can´t access to backend: Requested store is not found.
@alexpoletaev maybe I would be modify index.php:
index.php{main}";s:3:"url";s:7:"/admin/";s:11:"script_name";s:10:"/index.php";}
Autoload error
{$e->getMessage()}
HTML; exit(1); } $bootstrap = \Magento\Framework\App\Bootstrap::create(BP, $_SERVER); /** @var \Magento\Framework\App\Http $app */ $app = $bootstrap->createApplication('Magento\Framework\App\Http'); $bootstrap->run($app);@alexpoletaev backend works also. Many thaks for your help.
Internal ticket MAGETWO-62758 was created
Fix provided by @alexpoletaev is not working for General > Allowed Country settings. So Magento Team should provide the solution ASAP as this is very sensitive issue for any store.
Thanks
I agree with @MagePsycho that this bug needs to be fixed ASAP. It's the only new bug in 2.1.3 that actually prevents us from upgrading our shops to 2.1.3 since it has the potential of causing all kinds of unexpected issues.
@MagePsycho: For me the Allowed Country setting works when I apply the fix from @alexpoletaev btw (maybe you forgot to flush your caches?).
@veloraven: this exact same bug is also being tracked over here and got a different MAGETWO number assigned, just so you know if you didn't know already: #7943
And the issue was introduced in this commit: c1e806f#diff-5dec7e10285c9a96cf5b40b06ece36c0L107
@veloraven: I really would like to see this bug getting a very high priority, and being fixed in a new release in the first week of January if possible (for my part you can create a version '2.1.3.1' which only contains a fix for this bug).
And thanks to @alexpoletaev for discovering the fix!
Also affecting our clients - needs fixing ASAP
Extremely critical bug.
How did this get released? It must be one of the most fundamental functionalities in Magento 2.
Apparently the fix suggested in this issue is breaking the payment selection step in checkout. It appears as blank, and the corrisponding <div> stays hidden.
I am on Magento EE 2.1.3.
Sorry, my problem was on a 3rd party module, not magento core.
Do be aware that if this is a critical issue for you on 2.1.3, you can fix this issue by patching your installation by making the change I outlined here: #7943 (comment)
If you're installing Magento via Composer, you should check out this elegant composer-patches plugin that @hostep alerted me of that allows you to apply patches when composer install is run.
Rather concerning that something so elementary made it past their testers, if they use any.
@alexpoletaev , afther upgrading to M2.1.4 vendor/magento/module-store/Model/Config/Processor/Fallback.php has changed and $code = $website['code']; it´s O.K. , but I can´t access to subdomains like before in M2.1.3.
@alexpoletaev , Sorry issue is due because .htaccess was changed, now works fine.
Hi @netzweltvimal, this issue was fixed under MAGETWO-62648 in 2.1.4, that's why I closed it. If you have additional questions or info please feel free to reopen this one or create a new one.