[language filter] Review HTTP redirect codes

[andrepereiradasilva]

Pull Request for Issue #11165.

Summary of Changes

This PR reviews the HTTP status code of the redirects in the language filter plugins (current all are non cached 301 Moved Permanently).

After this PR the behaviour is the following:

• /defaultlang* to /* (remove language code is set to Yes) = 301 Moved Permanently
• /* to /defaultlang* (remove language code is set to No) = 301 Moved Permanently (not cached)
• /* to /otherlang* (cookie language based redirect) = 302 Found

Testing Instructions

1. Use latest staging
2. Apply patch
3. Test in a multilanguage site the behaviour described above by testing all combinations in global config (SEF / non SEF / etc) and language filter plugin parameters.
4. Do a code review

More info

See discussion in #11196

[mbabker]

What's the benefit to not caching the second scenario? Something in my gut tells me this isn't the most optimal behavior.

[ggppdk]

Works:

Remove default language CODE : No (language filter plugin)

Remove default language CODE : Yes (language filter plugin)

All redirections that do not involve default language get a 302 code

[ggppdk]

I have tested this item ✅ successfully on 38b92ae

See my above comment

---

_{This comment was created with the J!Tracker Application at issues.joomla.org/joomla-cms/11206.}

[ggppdk]

@mbabker

no, we can not allow any redirection to be cached, that is what we fixed recently

e.g. using language code in the URL for default language

• user visits homepage URL with no language code (thus user does not have language cookie yet), the user is redirected to home page with language code and gets 301 code, informing browser / search engines that 2nd URL is appropriate in place of the other
• now user switches to other language and clicks on banner with home page URL, he get redirected to homepage with code 302,

now in this last case, we tell browser to cache it then we break the language switching again, that what we recently fixed

[mbabker]

Something still doesn't feel right but you're all the ones dealing with this behavior so I leave it to your capable hands.

[ggppdk]

@mbabker

Something still doesn't feel right ...

you are right that it would be nicer to allow caching of some redirects e.g. cache 301 for default language,
but we also need to support the language switching with all possible configurations ...

i just say that this PR does not deal with the topic that you discuss, other PR have dealt with the above,

• this PR only wants to remove the 301 code for redirects that are obviously not 301, and make them 302, and make no other changes

and this last purpose is succeeded in my tests that is why i marked a successful test

[andrepereiradasilva]

What's the benefit to not caching the second scenario? Something in my gut tells me this isn't the most optimal behavior.

Scenario: you have a site with /en/ (default langauge) and /fr/

If you use a 301 cached redirect.

First time you access / you get a 301 from / to /en/ and this will be cached in the browser.
So now you changed to /fr/ and navigate a little.
Now, while you are in french you access / trought a link (home logo for instance) or direct input. Since the 301 was cached before will go to /en/ (instead of going to /fr/), i.e, it will override the language cookie behaviour.

So we can't cache it.

[mbabker]

OK that makes sense.

[infograf768]

I have tested this item ✅ successfully on 38b92ae

---

_{This comment was created with the J!Tracker Application at issues.joomla.org/joomla-cms/11206.}

[infograf768]

RTC. We now get the correct redirections afaik

---

_{This comment was created with the J!Tracker Application at issues.joomla.org/joomla-cms/11206.}