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

Magento 2.1.0 issue with method "getAreaCode" & "setAreaCode" #6063

Closed
thietdv-doan opened this issue Aug 9, 2016 · 4 comments
Closed

Magento 2.1.0 issue with method "getAreaCode" & "setAreaCode" #6063

thietdv-doan opened this issue Aug 9, 2016 · 4 comments
Labels
bug report Issue: Confirmed Gate 3 Passed. Manual verification of the issue completed. Issue is confirmed Issue: Format is not valid Gate 1 Failed. Automatic verification of issue format is failed Issue: Ready for Work Gate 4. Acknowledged. Issue is added to backlog and ready for development non-issue Reproduced on 2.1.x The issue has been reproduced on latest 2.1 release Reproduced on 2.2.x The issue has been reproduced on latest 2.2 release Reproduced on 2.3.x The issue has been reproduced on latest 2.3 release

Comments

@thietdv-doan
Copy link

Preconditions

  1. Magento version 2.1.0

Steps to reproduce

  1. Open file "vendor/magento/framework/App/State.php"
  2. Check 2 methods "getAreaCode" (line 136) & "setAreaCode" (line 119)

Expected result

  1. There should be a fix for this 2 methods to allow us to check if "$this->_areaCode" has been set or not then we can set if it has not been set.
  2. But the method "getAreaCode" always throw an exception

Suggestion

  1. Just return null / false if "$this->_areaCode" has not been set instead of throw exception in "getAreaCode" method
@andimov andimov self-assigned this Aug 17, 2016
@AVoskoboinikov AVoskoboinikov removed their assignment Aug 31, 2016
@jakobfdev
Copy link

+1
This is especially annoying with commands, where you need to check if the area code is set before executing and you have to catch unnecessary exceptions upon execute.
Any progress? No need?

@Morgon
Copy link

Morgon commented Dec 15, 2016

To change this request a little, I wouldn't mind if an exception was thrown if there is an attempt to set the area code to a different area. So, if code gets set for frontend multiple times, it should return null/false, but an unexpected change to another area would indicate possibly-undesired behavior and should be noted

@magento-engcom-team magento-engcom-team added bug report Issue: Format is not valid Gate 1 Failed. Automatic verification of issue format is failed TECH labels Sep 11, 2017
@magento-engcom-team
Copy link
Contributor

@thietdv-doan, thank you for your report.
We've created internal ticket(s) MAGETWO-84622 to track progress on the issue.

@magento-engcom-team magento-engcom-team added 2.1.x Issue: Ready for Work Gate 4. Acknowledged. Issue is added to backlog and ready for development Issue: Confirmed Gate 3 Passed. Manual verification of the issue completed. Issue is confirmed Reproduced on 2.1.x The issue has been reproduced on latest 2.1 release Reproduced on 2.2.x The issue has been reproduced on latest 2.2 release Reproduced on 2.3.x The issue has been reproduced on latest 2.3 release labels Nov 28, 2017
@magento-engcom-team
Copy link
Contributor

@thietdv-doan Thanks for reporting this issue. Considering that area should be set initially and can not be changed, current behavior is correct.

magento-engcom-team pushed a commit that referenced this issue Aug 31, 2020
[trigger] MC-30502: JSUnit tests incompatible with Node v10 or v12
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
bug report Issue: Confirmed Gate 3 Passed. Manual verification of the issue completed. Issue is confirmed Issue: Format is not valid Gate 1 Failed. Automatic verification of issue format is failed Issue: Ready for Work Gate 4. Acknowledged. Issue is added to backlog and ready for development non-issue Reproduced on 2.1.x The issue has been reproduced on latest 2.1 release Reproduced on 2.2.x The issue has been reproduced on latest 2.2 release Reproduced on 2.3.x The issue has been reproduced on latest 2.3 release
Projects
None yet
Development

No branches or pull requests

6 participants