Parameters from website configuration isn't applied to the corresponding store view

[staradzinau]

Preconditions

1. Install Magento ver. 2.1.3 CE with sample data
2. Set up at least one website with corresponding store and store view (in my case: Main Website, Main Website store and Default store view

Steps to reproduce

1. Go to admin panel, open Stores -> Settings -> Configuration
2. Set config scope to Default Config
3. Go to Catalog -> Catalog -> Product Reviews section
4. Set parameter Allow Guests to Write Reviews to "Yes"
5. Change config scope to Main Website
6. Set parameter Allow Guests to Write Reviews to "No"
7. Navigate to storefront as a guest and open any product page with "Reviews" tab

Expected result

1. Review submitting is enable for guest user

Actual result

1. Review submitting is disabled for guest user

Config parameters for the corresponding store view contains default values and have no connection to the website parameters values

[sevos1984]

Thanks for reporting, internal issue id MAGETWO-62648

[vishveskrish]

Is there any fix for this issue ?

[alexstpp]

Fixed here https://github.com/magento/magento2/blob/develop/app/code/Magento/Store/Model/Config/Processor/Fallback.php#L109

[erikhansen]

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.

[ericthehacker]

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.

[spyrule]

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.

[alexstpp]

Fix relevant for Magento 2.1.3

[korostii]

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.