User tests: Successful: Unsuccessful:
This PR solves the issue at #4483
It fetches the application language tag and ensures it's not empty or null before defaulting to the site's default language.
Labels |
Added:
?
|
Labels |
Added:
?
|
Category | ⇒ | Multilanguage |
Rel_Number | ⇒ | 4483 | |
Relation Type | ⇒ | Related to |
Steps to test this are the same as in the description of the issue:
Expected result
User is logged in and the registered article in Swedish appears.
Note: Swedish can of course be substituted by any available langauge. Result should be the same, getting redirected to the site in that language after loggin in.
Labels |
Labels |
Added:
?
|
Thanks Jacobo!
Question: what is the default site language set for the user logging in?
@infograf768 : The propose change only has affect if your account doesn't have a language selected.
Not sure how all of you can have login page displayed. When I tried to access to the menu item, I received the error message and have to use login module to login
U bent niet bevoegd deze pagina te bekijken
After login, I am redirected to expected page. So for me, it seems to work well (I reviewed the code as well)
PS: The propose change code will actually change the value of $lang_code to the language tag of active language of the current page, so I think change the code as suggested below will be shorter:
Original code:
if (empty($lang_code))
{
$lang_code = self::$default_lang;
}
Modified code:
if (empty($lang_code))
{
$lang_code = self::$tag;
}
Test conditions:
1. Article 1 set to lang B (not site default) with a Read More and set to registered.
2. Menu Item for single article menu item, loading Article 1 and set to lang B and public access
Clicking on the menu item displays the article with its Intro Text and Read More link asking to login
Even when setting Automatic Change to No in the Languagefilter plugin and user has no lang selected in profile (therefore defaulting to default site language), this does not work here.
@joomdonation You're right, your code works and is a lot more efficient. Thanks!
@infograf768 Make sure you're using a private or incognito window when testing this PR. It seems there's another bug regarding redirection after logging in/out that may be setting a cookie (which would cause this to fail). I've reported that problem here at issue #4934
Labels |
Labels |
Removed:
?
|
@infograf768 and @joomdonation: could I get you guys to test this again? I'm trying to get my PRs closed/merged after all this time. Sorry for taking so long to update them.
Thanks!
We can't test this anymore as there were extensive changes in languagefilter.
I suggest you test again for the issue using staging.
In any case, the present code redirects the user to the site default language if no specific site language is set for the user who logins or the user site language does not exist anymore (When Automatic Change is set to Yes).
Solving the issue by always redirecting to the language in use would kill the Automatic Change functionality.
Status | Pending | ⇒ | Closed |
Closed_Date | 0000-00-00 00:00:00 | ⇒ | 2015-05-10 14:36:15 |
Closed_By | ⇒ | infograf768 |
Set to "closed" on behalf of @infograf768 by The JTracker Application at issues.joomla.org/joomla-cms/4797
Folks, I am closing this one as it is anyway obsolete and we have a working patch here:
#6915
can be tested also with a single article menu item loading a registered article as #6908 has been merged,
Can you please explain how to test