-
-
Notifications
You must be signed in to change notification settings - Fork 546
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
Use Localize middleware in frontend user and nocache controllers #7892
Conversation
PR Summary
|
Just pulled this in and it works like a charm. Thanks Jack! |
Nice one, @jacksleight |
Great stuff! |
This unfortunately only "appears" to work because your default site is the one with the translation. If you were to have multiple sites configured, and you used either feature (login form or nocache tag) from the second site, it'll show the language from the first site. This is because the Localize middleware determines the site by the current URL. So when you submit the form, you end up on something like The middleware should somehow figure out the referring URL's site, not the current one. And that should be done without breaking it for the other places where the Localize middleware is already being used. I'm going to close this for now, but we can reopen if this gets sorted. Either on this PR or a fresh one. |
Gotcha - sorta. For now I guess I can keep in these composer patches. I'm working on a project where localised messages are very important due to the target audience. How can we resolve this properly though? |
The Localize middleware (either the existing one, or a new one) would need to be able to look at the referring url to determine the site, instead of the current url. |
Gotcha. Will open an issue for this. |
Oh not needed. My previous issues reopened due to GH magic. |
Fixes #7890
Fixes #7893
Only implements the Localize middlewear rather than the full
statamic.web
group. Could be done in the routes file but I just copied the approach from theFrontendController
class.