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

Since Magento 2.2.1, certain variables in the configuration get resolved to their actual value #15972

Closed
hostep opened this issue Jun 9, 2018 · 4 comments
Assignees
Labels
Component: Config Fixed in 2.2.x The issue has been fixed in 2.2 release line Fixed in 2.3.x The issue has been fixed in 2.3 release line Issue: Clear Description Gate 2 Passed. Manual verification of the issue description passed Issue: Confirmed Gate 3 Passed. Manual verification of the issue completed. Issue is confirmed Issue: Format is valid Gate 1 Passed. Automatic verification of issue format passed Issue: Ready for Work Gate 4. Acknowledged. Issue is added to backlog and ready for development 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

@hostep
Copy link
Contributor

hostep commented Jun 9, 2018

Before Magento 2.2.1 (2.2.0 and 2.1.x), when you entered a variable in the configuration like {{unsecure_base_url}}. Magento still rendered that value as entered in the configuration field. But since Magento 2.2.1, the variable gets resolved to the actual value. And if you save that particular configuration again, it will overwrite the value in the database with the actual current value instead of still storing the variable.

After git bisecting, I've identified the commit 86d46ce to have introduced the problem, more specifically, the changes in the file app/code/Magento/Config/Block/System/Config/Form.php are responsible for this problem. I also see that part of the above commit was reverted again in 6c9a8b2, but it wasn't fully restored to how it used to be.

/cc @viktym: since you were involved in those commits, you might have an idea of what we need to do to fix this issue? Thanks!

Preconditions

  1. PHP 7.1.18

Steps to reproduce

  1. Setup a clean Magento 2.2.1 installation (or 2.2.4 or 2.3-develop, tested with commit 33393e2)
  2. In the backend configuration go to: General > Web > Base URLs & Base URLs (Secure)
  3. Enter {{unsecure_base_url}}media/ in "Base URL for User Media Files" and {{secure_base_url}}media/ in "Secure Base URL for User Media Files"
  4. Save Config
  5. Look at those two fields you just edited

Expected result

  1. "Base URL for User Media Files" should contain: {{unsecure_base_url}}media/
  2. "Secure Base URL for User Media Files" should contain: {{secure_base_url}}media/
  3. In the database, the values are still at {{unsecure_base_url}}media/ & {{secure_base_url}}media/
  4. Resaving the configuration and looking at the database again, values are still at {{unsecure_base_url}}media/ & {{secure_base_url}}media/

Actual result

  1. "Base URL for User Media Files" contains: http://example.com/media/
  2. "Secure Base URL for User Media Files" contains: https://example.com/media/
  3. In the database, the values are still at {{unsecure_base_url}}media/ & {{secure_base_url}}media/
  4. Resaving the configuration and looking at the database again, the values have been replaced with http://example.com/media/ & https://example.com/media/
@magento-engcom-team magento-engcom-team added the Issue: Format is valid Gate 1 Passed. Automatic verification of issue format passed label Jun 9, 2018
@PascalBrouwers
Copy link
Contributor

What's even worse in a multistore setup is if correct it by entering manually {{unsecure_base_url}}media/ for "Base URL for User Media Files" in the global scope, but have entered a different "Base URL" in the website scope and have "Base URL" still set to "Use Website" on the store scope. The base url for the media files will still be resolved to the url of the global scope!

E.g.
global base url: mystore.com
website base url: mystore.nl
store base url: Use Website
Media urls on mystore.nl are resolved as mystore.com

@ghost ghost self-assigned this Jul 6, 2018
@ghost ghost added Issue: Clear Description Gate 2 Passed. Manual verification of the issue description passed Issue: Confirmed Gate 3 Passed. Manual verification of the issue completed. Issue is confirmed 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 Issue: Ready for Work Gate 4. Acknowledged. Issue is added to backlog and ready for development labels Jul 6, 2018
@ghost
Copy link

ghost commented Jul 6, 2018

HI @hostep thank you for your report.
We've acknowledged the issue and added to our backlog.

@magento-engcom-team
Copy link
Contributor

Hi @hostep. Thank you for your report.
The issue has been fixed in #18067 by @hostep in 2.3-develop branch
Related commit(s):

The fix will be available with the upcoming 2.3.2 release.

@magento-engcom-team magento-engcom-team added the Fixed in 2.3.x The issue has been fixed in 2.3 release line label Mar 30, 2019
@magento-engcom-team magento-engcom-team added the Fixed in 2.2.x The issue has been fixed in 2.2 release line label Apr 11, 2019
@magento-engcom-team
Copy link
Contributor

Hi @hostep. Thank you for your report.
The issue has been fixed in #22140 by @hostep in 2.2-develop branch
Related commit(s):

The fix will be available with the upcoming 2.2.9 release.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
Component: Config Fixed in 2.2.x The issue has been fixed in 2.2 release line Fixed in 2.3.x The issue has been fixed in 2.3 release line Issue: Clear Description Gate 2 Passed. Manual verification of the issue description passed Issue: Confirmed Gate 3 Passed. Manual verification of the issue completed. Issue is confirmed Issue: Format is valid Gate 1 Passed. Automatic verification of issue format passed Issue: Ready for Work Gate 4. Acknowledged. Issue is added to backlog and ready for development 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

3 participants