Config parameters for the corresponding store view contains default values and have no connection to the website parameters values
Thanks for reporting, internal issue id MAGETWO-62648
Is there any fix for this issue ?
I can confirm that changing the vendor/magento/module-store/Model/Config/Processor/Fallback.php:171
file from
$code = $website['website_id'];
to this:
$code = $website['code'];
fixes the issue for me.
A corollary of this issue is that, when a config field is overridden at a website level, any children store views which are set to "Use Website" for that field will return the default scope value, instead of the overridden website value.
Whats odd for me, is that my Callback.php is completely different than the one posted in the fix. Is the posted fix, mostly changed for dev reasons, because as far as I can tell in the sample fix, the 'code' doesn't actually exist in the stock file.
Fix relevant for Magento 2.1.3
Is there any chance bugfixes for such common yet simple bugs would get streamlined through frequent (more frequent than once per 6 months) patch version releases?
For example, a 2.1.3.1 version containing just the fixes to bugs introduced in (supposedly stable) 2.1.3 would do just fine.
The thing is, for a project facing a launch in the next month, waiting half a year(or more? nobody really knows) for the next release, which just might introduce more new bugs than it fixes - is not really an option.
Running on the "develop" branch is obviously no solution neither: by definition, it should be less stable (right?)
That leaves us with trying to produce workarounds of various sorts for the most critical issues in the time given, including extending core methods via di (which reminds me: why would you ever declare a method private? it complicates extensibility and might force to duplicate whole class, as in this very case there isn't really a way override just the getWebsiteConfig() ) just for the sake of including a one-line bugfix in a clean way.
It is hard to overrate the amounts of time to be potentially saved by something as simple and straightforward as bugfixing the core functionality in timely matter.
It would also save you from having to process the duplicate issues appearing months after the buggy version get released.
Nevertheless, I am of course grateful of all the work you guys at Magento, Inc. do, I just wish that? organizationally, releasing the patches would improve.
Respectfully, a humble PHP developer.
Was the fix included in 2.1.4?
Its not listed in the fix list on 2.1.4, so my guess is no.
edit: I guess I missed it in the notes, ignore my comment.
@Ctucker9233 yes! it's in the release notes 馃槃
@ebaschiera , whats totally weird for me, in my 2.1.3 installation, that file is nearly 100% different than the one in that link, yet that link is indicating a single line of code change. Is that fix for CE or EE ?
Closing the issue since it was fixed under MAGETWO-62648 for 2.1.4.
Most helpful comment
Is there any chance bugfixes for such common yet simple bugs would get streamlined through frequent (more frequent than once per 6 months) patch version releases?
For example, a 2.1.3.1 version containing just the fixes to bugs introduced in (supposedly stable) 2.1.3 would do just fine.
The thing is, for a project facing a launch in the next month, waiting half a year(or more? nobody really knows) for the next release, which just might introduce more new bugs than it fixes - is not really an option.
Running on the "develop" branch is obviously no solution neither: by definition, it should be less stable (right?)
That leaves us with trying to produce workarounds of various sorts for the most critical issues in the time given, including extending core methods via di (which reminds me: why would you ever declare a method private? it complicates extensibility and might force to duplicate whole class, as in this very case there isn't really a way override just the getWebsiteConfig() ) just for the sake of including a one-line bugfix in a clean way.
It is hard to overrate the amounts of time to be potentially saved by something as simple and straightforward as bugfixing the core functionality in timely matter.
It would also save you from having to process the duplicate issues appearing months after the buggy version get released.
Nevertheless, I am of course grateful of all the work you guys at Magento, Inc. do, I just wish that? organizationally, releasing the patches would improve.
Respectfully, a humble PHP developer.