[#8210] - languagefilter does not respect "return" parameter from login form
- Expected Behaviour
- 18 Mar 2016
- Medium
- Build: master
- # 8210
Steps to reproduce the issue
- Setup a multi-language page
- Leave languagefilter plugin in default settings
- Create a login form in non-default language on respective menu
- Set return_url_path to be not the menu item the login form is located at
- Open the site and switch to non-default language on login page
- login
Expected result
The page specified as return_url_path is opened in respective language
Actual result
The default page of default language is opened
System information (as much as possible)
The reason seems to be that languagefilter retrieves the active menu item and looks for the language association of this page. It does not check the already set 'users.login.form.return' user state value.
Additional comments
The return_url_path of a login form is important and shall never disregarded.
Votes
I understand this, but associations of return_url_path if present, not the current page, right?
nope, redirecting to associated current displayed item
what is the reason for ignoring the return value?
The problem originally came from the fact that one would choose anything as return value and it broke.
One must not forget that the login module can be set to ALL languages and therefore display on all pages.
So we choose to return to the Home page for the user preferred language when no associations or to the associated item if any.
I currently have the following situation: My login page disappears when a user logged in (it's guest-only). The languagefilter plugin redirects to this (now non-existent) page and therefore throwing a 403 error.
The only solution to my situation is currently to disable automatic_change, which I guess I do not want at the end.
Is there another solution possible?
| Status | New | ⇒ | Expected Behaviour |
| Closed_Date | 0000-00-00 00:00:00 | ⇒ | 2016-03-18 18:19:08 |
| Closed_By | ⇒ | brianteeman |
closing as expected behaviour as described by @infograf768
This comment was created with the J!Tracker Application at issues.joomla.org/joomla-cms/8210.
The associations have indeed priority.