Skip to content
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

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

Closed
staradzinau opened this issue Dec 23, 2016 · 14 comments
Labels
bug report Issue: Ready for Work Gate 4. Acknowledged. Issue is added to backlog and ready for development

Comments

@staradzinau
Copy link

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 sevos1984 added the Issue: Ready for Work Gate 4. Acknowledged. Issue is added to backlog and ready for development label Dec 23, 2016
@sevos1984
Copy link
Contributor

Thanks for reporting, internal issue id MAGETWO-62648

@vishveskrish
Copy link

Is there any fix for this issue ?

@erikhansen
Copy link
Contributor

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
Copy link

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
Copy link

spyrule commented Dec 29, 2016

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
Copy link

Fix relevant for Magento 2.1.3

@korostii
Copy link
Contributor

korostii commented Jan 6, 2017

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.

@Ctucker9233
Copy link

Was the fix included in 2.1.4?

@spyrule
Copy link

spyrule commented Feb 8, 2017

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.

@ebaschiera
Copy link

@sammarcus
Copy link
Contributor

@Ctucker9233 yes! it's in the release notes 😄

@spyrule
Copy link

spyrule commented Feb 10, 2017

@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 ?

@KrystynaKabannyk
Copy link

Closing the issue since it was fixed under MAGETWO-62648 for 2.1.4.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
bug report Issue: Ready for Work Gate 4. Acknowledged. Issue is added to backlog and ready for development
Projects
None yet
Development

No branches or pull requests