@smz @dgt41
Please test.

@test: patch works fine. Thanks!

Can't you use JInput to check for the return or view parameter? Looks really wrong to directly access the $_SERVER variable.

Ah crap, I missed you check the referrer.
Honestly, that sounds quite messy to me. Code should behave the same no matter where we come from.

The issue is that a "normal" login (whether it comes from a direct login menu item or the login module) does not contain the return url. This is the only difference with what we get from the Read More.
Therefore our only way to decide about the language to display after login depends of this parameter.

Don't know how to use JInput for that.

is there HTTP_REFERER different from current URL?
I not sure, but in theory if you submit the form, then should be same
And then in this case can use

$url = JUri::getInstance();
if ($url->hasVar('return') && $url->getVar('view') === 'login' )
...
...

just theory

The issue is that a "normal" login (whether it comes from a direct login menu item or the login module) does not contain the return url.

The login module and com_users login view both support the return param, so I don't think it's fair to base the check on the existence of that.

(Anyway when sef on AND there is a login menu item, view=login is not in the referrer, just tested...)
So I change that part and let's try to find something else... :)

Why should it make a difference whether we come from a login page or the requested page (article view) is directly entered. In all cases it shouldn't redirect the user to the homepage but instead it should stay on the language and item requested by the URL.
Maybe that is the real bug? It just shouldn't redirect to the homepage at all after a login. If the URL already defines a language, that should have precedence over the default setting by the user.

I do not agree, @Bakual.
The whole point is that "Automatic Language Change" was specially introduced to redirect the user to its default site language home page (or the associated item in his language, if exists) when login , and I try to solve the "Register to Read More" special case.
That is the ONLY use for the user site language in multilingual.

@Fedik
HTTP_REFERER is different from current URL when login.
The current url does not contain the return but only ?task=user.login

Maybe we should respect return url if it is passed in the login form and only process "Automatic Language Change" if no return url is passed. Something like this:

$return = $this->app->input->post->get('return', '', 'BASE64'); 
if ($this->app->isSite() && $this->params->get('automatic_change', 1) && empty($return))
{

}

Ah, sorry. I think I am wrong. It will defeat the purpose of having "Automatic Language Change" when there return param is passed in the login module. So please ignore my comment.

yeah, tricky... What makes the Register to Read More specific is what we look for.

Infact, I don't think it is "Register to Read More specific". As a third party extension developer, in my extensions, I also have code:

• Redirect users to login page with return variable passed in the URL.
• Or has a login form within my extension to allow users to login before continue the process. In that form, I have return as hidden variable to ask Joomla to redirect users back to that page to continue the process

In this case, I would expect Joomla to respect the return url which I passed instead of redirect user to homepage in case no association found. I think I agree with @Bakual. Maybe in case no association is found and there is return url passed from login form, we should redirect users back to that URL instead of redirect to home language.

Codewise there is no difference if a user enters the URL manually, followed a link or clicked the readmore button (and went to login and back). It's all the exact same URL and should actually behave the same.
If you need a different behavior for readmore, you should add a parameter to the URL which says so. &readmore=1 or &fixedlanguage=1 or something like that.
Then it's easy to write code for it.

wrong comment

My mistake, deleted former comment.

The new code solves the issue by redirecting to the user site language Home page ONLY when login from the Home page.
It keeps redirecting to the associated menu item if logging from a page with such menu item.
Therefore it is B/C and redirect url set in the login module (except when the url is to another language menu item which should anyway never be done!) is now respected when NOT on the home page instead of always redirecting to the Home page.

Thanks @joomdonation . This was a 3 days collaboration work!

The behavior is now correct:

1. If an association of the active menu item is found, the the system will redirect to that association menu item

2. If no association is found and users login from homepage, he will be redirected to homepage of his language.

3. Otherwise, he will be redirected to the return URL (passed in the request)

This PR not only fixes the issue described in description but also fix wrong behavior before (always redirect to home page of user language if no association is found)

So @test success from me.

@smz @dgt41
need testers here :)

Code looks much better now. Nice work, thanks!

@test ok acoording to @joomdonation comment #6915 (comment)

@test: new patch works here. Thanks!

RTC

Sorry, too late, but @test:OK here too...

Merged. Thank you @infograf768!