Open danemacmillan opened 1 year ago
Hi @danemacmillan. Thank you for your report. To speed up processing of this issue, make sure that you provided the following information:
Make sure that the issue is reproducible on the vanilla Magento instance following Steps to reproduce. To deploy vanilla Magento instance on our environment, Add a comment to the issue:
@magento give me 2.4-develop instance
- upcoming 2.4.x release
For more details, review the Magento Contributor Assistant documentation.
Add a comment to assign the issue: @magento I am working on this
To learn more about issue processing workflow, refer to the Code Contributions.
Join Magento Community Engineering Slack and ask your questions in #github channel.
:warning: According to the Magento Contribution requirements, all issues must go through the Community Contributions Triage process. Community Contributions Triage is a public meeting.
:clock10: You can find the schedule on the Magento Community Calendar page.
:telephone_receiver: The triage of issues happens in the queue order. If you want to speed up the delivery of your contribution, join the Community Contributions Triage session to discuss the appropriate ticket.
:pencil2: Feel free to post questions/proposals/feedback related to the Community Contributions Triage process to the corresponding Slack Channel
Hi @engcom-November. Thank you for working on this issue. In order to make sure that issue has enough information and ready for development, please read and check the following instruction: :point_down:
[ ] 1. Verify that issue has all the required information. (Preconditions, Steps to reproduce, Expected result, Actual result).Details
If the issue has a valid description, the label Issue: Format is valid
will be added to the issue automatically. Please, edit issue description if needed, until label Issue: Format is valid
appears.
[ ] 2. Verify that issue has a meaningful description and provides enough information to reproduce the issue. If the report is valid, add Issue: Clear Description
label to the issue by yourself.
[ ] 3. Add Component: XXXXX
label(s) to the ticket, indicating the components it may be related to.
[ ] 4. Verify that the issue is reproducible on 2.4-develop
branchDetails
- Add the comment @magento give me 2.4-develop instance
to deploy test instance on Magento infrastructure.
- If the issue is reproducible on 2.4-develop
branch, please, add the label Reproduced on 2.4.x
.
- If the issue is not reproducible, add your comment that issue is not reproducible and close the issue and stop verification process here!
[ ] 5. Add label Issue: Confirmed
once verification is complete.
[ ] 6. Make sure that automatic system confirms that report has been added to the backlog.
@magento give me 2.4-develop instance
Hi @engcom-November. Thank you for your request. I'm working on Magento instance for you.
Hi @engcom-November, here is your Magento Instance: https://882b1fcb1582f0688f079b4872326b69.instances.magento-community.engineering Admin access: https://882b1fcb1582f0688f079b4872326b69.instances.magento-community.engineering/admin_d356 Login: 4a348d08 Password: acd23f1b1221
Hi @danemacmillan , Thank you for reporting and collaboration. Verified the issue on Magento 2.4-develop instance but unable to reproduce the issue with below steps performed: Steps performed:
Enabled config cache: magento cache:enable config
Stores setup as shown below:
Apache server with virtual host configured as below:
Set the urls for both the website scopes as shown below: Note: static and media urls left blank
Getting 404 not found error for both the website scopes when trying to access : http://mg24.local/static, http://mg24.local/media http://en.mg24.local/static, http://en. mg24.local/media Kindly recheck the behavior on Magento 2.4-develop instance and elaborate missing steps / configuration details if the issue is still reproducible. Thank you.
Hi,
There are several problems with your attempt to reproduce. Mainly, they are just not following the steps mentioned in the original report.
Web Site
, each specifying their unique Web Site
code, which would mean one virtual host for base
and a second virtual host for base2
. Additionally, they need to have unique server names (domain names); they cannot be the same. Give them a unique name each. In your case, I would use base.mg24.local
for the virtual host that corresponds to the base
Web Site
scope code, and base2.mg24.local
for the virtual host that corresponds with the base2
Web Site
scope code. Web Site
scope (code being base
) in the scope changer located at the top left of the admin (see image a
), then set the Base URL, Base Link URL, Secure Base URL, and Secure Base Link URL; then you need to do the same thing for the "base2" Web Site
scope (code being base2
). Additionally, and more importantly, the whole point of this ticket is that the placeholders don't work: you're not using placeholders, you're explicitly setting a domain in the admin config. To repeat what was mentioned in the original ticket, you need to set the URLs with the placeholder values that Magento supports. That would look like this for each Web Site
scope:base
:
{{base_url}}
{{unsecure_base_url}}
{{base_url}}
{{unsecure_base_url}}
base2
:
{{base_url}}
{{unsecure_base_url}}
{{base_url}}
{{unsecure_base_url}}
You literally save the placeholder values (see image b
). This was explicitly written in the original issue, with the commands to execute to do this.
Lastly, you don't go visit the static URLs directly, though the problem will likely exist there as well. You visit the site itself, which will in turn build all the link, static, and media URLs and then cache them. You having a 404 has nothing to do with the issue, and only to do with your own misconfigured machine.
a) Note that I recreated what your scope changer menu would look like, based on the Web Site
s you displayed in your screenshot.
b)
--
To be clear, I wrote all of this in my original ticket. Yes, it's a complex set of steps, but I've merely repeated myself here, but will happily continue to guide you until you can reproduce.
Thank you for the response @danemacmillan Verified the issue again on Magento 2.4-develop instance with updated steps and the issue is reproducible. Hence updating the description and confirming the issue.
:white_check_mark: Jira issue https://jira.corp.adobe.com/browse/AC-7687 is successfully created for this GitHub issue.
:white_check_mark: Confirmed by @engcom-November. Thank you for verifying the issue.
Issue Available: @engcom-November, You will be automatically unassigned. Contributors/Maintainers can claim this issue to continue. To reclaim and continue work, reassign the ticket to yourself.
:x: You don't have permission to export this issue.
Preconditions and environment
2.4.3-p3
7.4.33
magento cache:enable config
Web Sites
, with codesbase
andbase2
Web Site
with oneStore
each, using codesstore1
andstore2
.Store
with oneStore View
each, using codesen1
anden2
.base/store1/en1
,base2/store2/en2
.fastcgi_param MAGE_RUN_TYPE website
and each host configured with their appropriate website code:fastcgi_param MAGE_RUN_CODE base
andfastcgi_param MAGE_RUN_CODE base2
.Steps to reproduce
With two
Web Sites
configured, now set their base URLs using the default placeholders, so that an explicit domain does not need to be configured, which will allow the deployment to exist at any domain, so long as it points to the correct deployment, as noted here:This is also noted in the Admin at
Stores > Settings > Configuration > General > Web > Base URLs
, should they want to set the URL values at each Web Site scope (not default).To simplify the process, just use the commands to set the URLs.
Web Site code:
base
Web Site code:
base2
Ensure at the very least the
config
cache is enabled:magento cache:enable config
. Everything else can be off.With Nginx (or Apache) configured with the relevant
MAGE_RUN_TYPE
andMAGE_RUN_CODE
per domain virtual host, navigate to the either of the domains first. For example purposes,base
will respond to domainhttps://base.test/en1/
andbase2
will respond to domainhttps://base2.test/en2/
.The first domain loads fine, with all its static and media assets also loading from the same base URL of
https://base.test/
, beinghttps://base.test/media/
andhttps://base.test/static/
.Now navigate to the second domain. It loads fine, except that all of its static and media assets are not loading from
https://base2.test/
, but are loading from the first domain, which obviously causes numerous CSP and CORS errors, while additionally all of the links on the site are pointing tohttps://base.test/
, which means the moment anyone interacts with the second site, they are brought to the first one.Disabling the config cache eliminates this problem.
Worthwhile debugging notes
Setting the
base_static_url
andbase_media_url
configs with placeholder values{{unsecure_base_url}}static/
and{{unsecure_base_url}}media/
does not remedy the issue. The problem is the same. For simplicity, they have been left empty, as they are optional anyway.Explicitly setting all of the URLs to real values instead of using the placeholders DOES NOT cause this problem. Both Web Sites load fine, respecting their specific URLs and not attempting to load from the other. The static and media URLs will load from their explicitly configured URLs, and not pollute each other's config cache values. In fact, the only reason I discovered this problem is because I was reviewing how to simplify deployments on different domains while still sharing a common DB without having to explicitly set domains in the DB. That was when I read that even the Base URL can be set to
{{base_url}}
, which would mean the domain that gets used is whatever is configured in the server's virtual host (Nginx or Apache). While it works for the Base URL, the static and media URLs pollute each other, based on whichever is accessed first.Expected result
After navigating to
https://base.test/en1/
, navigating tohttps://base2.test/en2/
should load all of its static and media assets from its own base URL ofhttps://base2.test/
.Actual result
Instead, what happens is that navigating to
https://base2.test/en2/
will have all of its static and media assets loaded from the Base URL of the first Web Site that was accessed, beinghttps://base.test/
.Additional information
Note that a similar problem was documented in #10693, though there was no mention of whether they also set the static and media URLs. The probably didn't. In all likelihood, the deployments that the user was making were single Web Site configurations, which would not have this problem, as there would be no other Web Site Base URLs polluting the Base URLs of the config cache.
Release note
No response
Triage and priority
Edit 1: Research
This method gets called on all configs within all scopes, regardless of the Store View being loaded: https://github.com/magento/magento2/blob/5f07eba878296a37bd5c3a2baecad48948547594/app/code/Magento/Store/Model/Config/Processor/Placeholder.php#L35
It then eventually calls a method to process all placeholders, which then replaces all the
{{base_url}}
and similar URL placeholders with the value detected from the request via this method: https://github.com/magento/magento2/blob/5f07eba878296a37bd5c3a2baecad48948547594/app/code/Magento/Store/Model/Config/Placeholder.php#L126What that means is that every
Web Site
-scoped config is replaced with the currently discoveredHTTP_HOST
, which is erroneous. The current Web Site scope would need to be known before attempting to replace placeholders, and the placeholder replacements themselves should only be done on the configs for the current Web Site scope, not all of them, as is being done now. What this means is that when the config cache is enabled, the moment the first Web Site within a multi-website configuration is hit, the domain for that site is used for every other Web Site scope config, and then saved to the cache. This happens because the code does not care about what scope the placeholder replacements should be made; instead it simply replaces all of them, regardless of scope. That means when the next site is loaded from a different domain, all of its Link, Static, and Media URLs have already been generated by the placeholder replacement operation from the first load of the other site.In summary, what this means is that the URL placeholder replacement logic runs way too early on the configs, and instead needs to be run only once scopes are known, and only run under the currently active scope.
Also, given how early in the process URL placeholders are being replaced, it means, for example, that code like this will never be run, as replacements will have already occurred (keep in mind that this section would not address the other URL placeholders, though, even if they managed to get to this section: https://github.com/magento/magento2/blob/5f07eba878296a37bd5c3a2baecad48948547594/app/code/Magento/Store/Model/Store.php#L669
Edit 2: Research
Based on git logs, much of this functionality was rewritten in a very large commit (https://github.com/magento/magento2/commit/a978a4cb72a2babba91cb78988bc4a41a70a60ab) by Sergii Kovalenko, which may be the source of the problem.