-
Notifications
You must be signed in to change notification settings - Fork 9.4k
Multilanguage store specific baseurl #3478
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
Multilanguage store specific baseurl #3478
Conversation
I'll fix the 4 Failures in integration test 1 |
hello @BlackIkeEagle, can you please update code of the PR and cover it by Travis tests? |
@KrystynaKabannyk I currently lack a bit of time. I hope I can attend this issue within reasonable time. |
There is a working update now, please verify. |
The build failure has nothing to do with this change! |
@BlackIkeEagle Thank you for your contribution. Could you please fix cyclomatic complexity in method app/code/Magento/Store/App/Response/Redirect.php : _isUrlFromOtherStore() Thank you! Please, see https://travis-ci.org/magento/magento2/jobs/125746121 |
Internal ticket: MAGETWO-52470 |
@okorshenko I'll try to address as soon as possible |
@okorshenko the cyclomatic complexity issue should be fixed now. I'll rebase on current development too. |
So what does this do/fix? |
Hey @BlackIkeEagle thank you for fixing the cyclomatic complexity but unfortunately the integration tests are still broken. |
@hshar7 yeah sorry I was a bit overly enthousiast and cut some corners |
hmm PHP7 unittest failed because of: "The command "phpenv global 7.0" failed and exited with 1 during ." |
@BlackIkeEagle I ran that build again, seems to be working. Thanks for fixing those! |
@BlackIkeEagle if you have a minute could you please provide a brief description of this pr and its functionality? |
the first commit had the usefull information but it seems github did not pick it up We have a website for example http://magento2.dev/ We have 3 stores, when we go to the homepage and switch the language everything seems to But for example when we go to a category page outside the "default site" This is normal because we find no match in the routing. if our category page is /category/subcategory we match in the When we are in a storeview where there is /fr or /en in the beginning of |
Hi @BlackIkeEagle I sent you an email yesterday but I'm not sure if you received it. Please email me at hsharhan[At symbol]magento.com to discuss this since we have some questions about this pr and it would be easier to talk there. |
@hshar7 was my mail sufficiently clear or are you waiting for a screencast too :) |
@BlackIkeEagle Yes thank you very much for the email it really did clear things up for me! In context of my reply I asked if we could close this as we do not think it is a bug. Is that okay? |
@hshar7 Could you leave it open for now, I want to check some things first but I have other work to do at the moment. I still think its a bug since we had to update all our 2.0.x stites with this patch to avoid issues. |
@hshar7 here a quick screenrecording where we get a 404 on the homepage without this patchset https://herecura.eu/files/recording-2016-06-01_12.35.23.webm |
@BlackIkeEagle Could you explain why you are adding the language codes to the base url? Instead of activating "add store codes to url" which would do the same and switching there would work correctly. These guys explain this pretty well: http://www.magestore.com/magento-2-tutorial/how-to-configure-store-urls-in-magento-2/ |
When a request is launched the area is deterined durning launch. When we have storeviews with the same domain and an added path in the url, all requests for that storeview will land in the area 'frontend' while we could have requests for webapi_rest, ... Before the cleaning of the store specific path was already done in the request preprocessor but for other than frontend requests this pathInfo update comes to late. So now the pathInfo is updated during launch. Signed-off-by: BlackEagle <[email protected]>
there were a lot of false positives detecting urls coming from other stores. this is now mitigated. Signed-off-by: Ike Devolder <[email protected]>
Signed-off-by: BlackEagle <[email protected]>
Signed-off-by: BlackEagle <[email protected]>
Signed-off-by: BlackEagle <[email protected]>
_isUrlInternal() was too complex, so now we have added another method to check if the 'internal' url is coming from another store. _isUrlFromOtherStore() Signed-off-by: BlackEagle <[email protected]>
Signed-off-by: BlackEagle <[email protected]>
Hi @BlackIkeEagle |
@okorshenko If something is not clear, or the intentions are not clear, let me know, I'll try to explain what we try to do. |
@BlackIkeEagle could you please fix broken integration tests? |
@okorshenko I can pick this branch back up and see if I can get this working on develop and then fix the tests |
@BlackIkeEagle thank you. Please ping me once you will be ready for delivery. |
@BlackIkeEagle thank you for your contribution. Please create new PR when ready. Closing this PR for now |
[EngCom] Public Pull Requests - GraphQL
We have a website for example http://magento2.dev/
We have 3 stores,
locale nl_NL; uses same base_url as website
locale fr_FR; uses http://magento2.dev/fr/
locale en_US; uses http://magento2.dev/en/
when we go to the homepage and switch the language everything seems to
work.
But for example when we go to a category page outside the "default site"
url we get a 404.
This is normal because we find no match in the routing.
if our category page is /category/subcategory we match in the
UrlRewriteRouter to /catalog/categroy/view/id/x .
When we are in a storeview where there is /fr or /en in the beginning of
the path, we match nothing and result in a 404.