Skip to content

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

Closed
wants to merge 11 commits into from
Closed

Multilanguage store specific baseurl #3478

wants to merge 11 commits into from

Conversation

BlackIkeEagle
Copy link
Member

@BlackIkeEagle BlackIkeEagle commented Feb 19, 2016

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.

@BlackIkeEagle
Copy link
Member Author

I'll fix the 4 Failures in integration test 1

@KrystynaKabannyk
Copy link

hello @BlackIkeEagle, can you please update code of the PR and cover it by Travis tests?

@BlackIkeEagle
Copy link
Member Author

@KrystynaKabannyk I currently lack a bit of time. I hope I can attend this issue within reasonable time.

@BlackIkeEagle
Copy link
Member Author

There is a working update now, please verify.

@BlackIkeEagle
Copy link
Member Author

The build failure has nothing to do with this change!

@okorshenko
Copy link
Contributor

okorshenko commented May 3, 2016

@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

@okorshenko
Copy link
Contributor

Internal ticket: MAGETWO-52470

@okorshenko okorshenko added the Issue: Ready for Work Gate 4. Acknowledged. Issue is added to backlog and ready for development label May 3, 2016
@BlackIkeEagle
Copy link
Member Author

@okorshenko I'll try to address as soon as possible

@BlackIkeEagle
Copy link
Member Author

@okorshenko the cyclomatic complexity issue should be fixed now. I'll rebase on current development too.

@adragus-inviqa
Copy link
Contributor

So what does this do/fix?

@hshar7
Copy link
Contributor

hshar7 commented May 13, 2016

Hey @BlackIkeEagle thank you for fixing the cyclomatic complexity but unfortunately the integration tests are still broken.

@BlackIkeEagle
Copy link
Member Author

@hshar7 yeah sorry I was a bit overly enthousiast and cut some corners

@BlackIkeEagle
Copy link
Member Author

hmm PHP7 unittest failed because of: "The command "phpenv global 7.0" failed and exited with 1 during ."

@hshar7
Copy link
Contributor

hshar7 commented May 16, 2016

@BlackIkeEagle I ran that build again, seems to be working. Thanks for fixing those!

@hshar7
Copy link
Contributor

hshar7 commented May 16, 2016

@BlackIkeEagle if you have a minute could you please provide a brief description of this pr and its functionality?

@BlackIkeEagle
Copy link
Member Author

@hshar7

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,
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.

@hshar7
Copy link
Contributor

hshar7 commented May 19, 2016

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.

@BlackIkeEagle
Copy link
Member Author

@hshar7 was my mail sufficiently clear or are you waiting for a screencast too :)

@hshar7
Copy link
Contributor

hshar7 commented May 31, 2016

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

@BlackIkeEagle
Copy link
Member Author

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

@BlackIkeEagle
Copy link
Member Author

@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

@hshar7
Copy link
Contributor

hshar7 commented Jun 2, 2016

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

BlackIkeEagle and others added 7 commits August 19, 2016 12:23
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]>
_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]>
@okorshenko okorshenko removed their assignment Feb 12, 2017
@okorshenko
Copy link
Contributor

Hi @BlackIkeEagle
Thank you for your Pull Request. I will review this PR as soon as possible. Sorry for delay

@okorshenko okorshenko self-assigned this Apr 22, 2017
@okorshenko okorshenko added this to the April 2017 milestone Apr 22, 2017
@BlackIkeEagle
Copy link
Member Author

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

@okorshenko okorshenko modified the milestones: April 2017, May 2017 May 9, 2017
@okorshenko
Copy link
Contributor

@BlackIkeEagle could you please fix broken integration tests?

@BlackIkeEagle
Copy link
Member Author

@okorshenko I can pick this branch back up and see if I can get this working on develop and then fix the tests

@okorshenko
Copy link
Contributor

@BlackIkeEagle thank you. Please ping me once you will be ready for delivery.

@okorshenko okorshenko modified the milestones: May 2017, June 2017 Jun 1, 2017
@okorshenko
Copy link
Contributor

@BlackIkeEagle thank you for your contribution. Please create new PR when ready. Closing this PR for now

@okorshenko okorshenko closed this Jun 5, 2017
magento-engcom-team pushed a commit that referenced this pull request Nov 23, 2018
[EngCom] Public Pull Requests - GraphQL
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
Issue: Ready for Work Gate 4. Acknowledged. Issue is added to backlog and ready for development Progress: needs update
Projects
None yet
Development

Successfully merging this pull request may close these issues.

7 participants