Confirmed that in both cases the 301 redirect for home-page without language code

• is not cached for browsers: chrome, firefox, edge

Issue #11159 ("Remove language code" for default language is ON (lang-filter plugin))

• language switching for all languages while in home page is now possible
• type or click the home page without language code then he will get the default language without any redirect

This is expected and correct behaviour according to configuration ! (also if you see the language switcher URL you will see that default language does not have language code)

Issue #11143 ("Remove language code" for default language URL is OFF (lang-filter plugin))

• type or click the home page url without language code, you are redirected to home-page URL with language code of the last switched language

Please test without cache / page cache, or clean cache after every configuration change of language filter plugin

I have tested this item ✅ successfully on 963c58c

Works, see my previous comment, note i tested in browsers (firefox, chrome, edge, IE)

NOTE: if you don't see the 301 redirect in network console when clicking on URL that is supposed to do 301 redirect, it is because some browser clear their console on new page load, and if localhost it may update too fast to see it

I have tested this item ✅ successfully on 963c58c

at least 1 more tester for this ?

I have tested this item ✅ successfully on 963c58c

I have tested this item ✅ successfully on 963c58c

RTC and changed Title to add Regression. Thanks!

@wilsonge
Please get into 3.6.1

Changing back to pending. I have issues here in Firefox when browser caching enabled (for Home page). Can't switch to default language (en-GB here).

Folks, please test reverting
#10344

It solved the issue here.

@infograf768

Web-sites will not (at least they should not) change settings after initial setup for

• language filter plugin parameter "remove language code"
• system cache plugin parameter "browser cache"

Otherwise the 301 etc instructions to the visitor browsers are no longer valid, and its not possible to force browser to clean cache for a specific URL that the browser does not resend to the server, but instead retrieves it from the cache

if you clear both Joomla cache and browser cache then it should work ?

• i tested and it works, maybe you can give more detailed instructions

at least for me it worked (i cleared browser cache and Joomla cache after changing settings of the plugins)

@ggppdk
Yep, I know a bit how it should work. :)
I was successful when my Firefox had cache enabled when both:
Reverting #10344
Applying this patch

hhhmm i have it applied,

and i saw the effect you describe (when i had SEF off),

• but it worked after i cleaned cache in chrome,

later "today" i will retest with firefox and other browsers

I have tested this item ? unsuccessfully on 963c58c

Why are we using a 301 here? 301 is a permanent redirect. By telling caches not to cache a 301 you're effectively trying to convert it to a temporary redirect. But there is already a 302 redirect for exactly that purpose. Telling caches not to cache a 302 makes perfect sense and you might have less trouble with caches as a result.

@chrisdavenport

301, was decided to be re-applied, after some discussion for SEO reasons, in this PR
#8894

I am not 100% sure it is worth it,
but possibly 301 with zero expired time is the best choice ?

and then this PR is does the above, to fix problems related with 301 redirect
and it seems to almost succeed,

i will test the reported conflict of this fix with #10344

#8894 changed it from the default 303 to 301. As @andrepereiradasilva pointed out, this changed the semantics to that of a permanent redirect, which you're now trying to override by adding cache directives instead of using the correct, temporary redirect in the first place.

303 will lead to duplicate content on search engines because, as the specification says, "the new URI in the Location header field is not considered equivalent to the effective request URI." (https://tools.ietf.org/html/rfc7231#section-6.4.4)

Adding the cache directives is good, but the status code should be changed too, in my opinion.

Which files are patched? If I change only the plugins/system/languagefilter/languagefilter.php Joomla doesn't load content at all.
When I could download the upgrade?

i agree with @chrisdavenport . i'm not enterily in favour of a "301 Permanent Redirect" in the language filter redirect as i explained in the original PR that made that change #8894. Probably a "302 Found" is the correct awnser for this.

This PR only propose is to send HTTP headers for browsers to not cache language filter HTTP redirects (independently of the HTTP redirect type), doesn't changes the redirect HTTP status code type.

I have tested this item ? unsuccessfully on 963c58c

Able to reproduce the issue, I tested manually the patch, unsuccesfully.

@Sandra97 did you cleared the cookies and browser cache, or used a new private browser window for testing?

@andrepereiradasilva, I cleared the cookies and browser cache, tried with private browser and 2 different browsers but no change:

And all the menu items are now /it, some of the content displayed is in italian and some is english. If I revert the change, the display is ok, everything is nearly ok except of course that I can't display the default homepage in the right language

are you using todays latest staging?

remember a patch #10344 was merged yesterday that changes the same file. so, if you're not using latest staging, when using the patchtester, and since the patchtester replaces the entire file, applying this PR will include the changes from the merged PR in this file too and will break things.

So please try use latest staging + patchtester or try apply just the lines of code this PR changes manually, ie, without the patchtester: https://github.com/joomla/joomla-cms/pull/11161/files

I did the test by replacing manually the current content of the file by yours (whole content)

I did the test by replacing manually the current content of the file by yours (whole content)

You can't. that's what i'm saying, if you're not using the latest staging please add just the lines of code this PR adds. Don't replace the whole file nor use the patchtester.

Ok, I'll try like this.

I have tested this item ✅ successfully on 963c58c

Adding only the new lines to the file does the job. I'm now able to browse the default homepage.

thanks @Sandra97

@infograf768 @ggppdk and other testers.

To test:

• clean cookies and browser cache before testing OR use new private browser window.
• and use latest staging from today + patch tester OR apply the patch manually by changing just the lines this patch changes (see https://github.com/joomla/joomla-cms/pull/11161/files).

@andrepereiradasilva
i tested on the latest staging with 10344. browser cache on and cleaned(which i don't do usually). no jomla cache. cookies cleared.

ok then try without 10344 applied, because this PR just tells the browser to not cache the redirect, nothing more.

As I said, to get it to work, I reverted 10344 and then applied your patch. And then it works here.

then change your test to success please

I can't as #10344 is in the way for me here.

The fact that 10344 needs to be reverted for this to work tells me that the plugin's constructor is doing more than setting application values, which is exactly what that pull request removed from the plugin to force the event dispatcher to correctly respect the configured plugin ordering values. This also tells me that parts of the languagefilter plugin should NOT be the plugin but integrated directly into the application class because there is an extremely tight coupling to its constructor logic from within the application and this should NEVER be the case.

@mbabker

I tested again after quitting Firefox and relaunching.
I don't have the issue anymore after this patch. Means I do not have anymore to revert 10344
I have the feeling my problem was due to sessions (not cookies).

Well, that's a good sign.

I have tested this item ✅ successfully on 963c58c

RTc again.

@andrepereiradasilva
@infograf768

please read, or may i should open another issue

this patch seems good after cache clearing but there is another issue

I have site with default language e.g. "French"

1- if current language is French and i visit domain/ i get no redirection
2- if current language is German and i visit domain/ i get a 301 redirection to domain/de/
3- if current language is English and i visit domain/ i get a 301 redirection to domain/en/
4- if i visit domain/fr/ i get a 301 redirection to domain/

1 and 4 are good
2 and 3 the redirection are OK , but they must not have code 301 ! , right ?

[EDIT]
example of URL inside the page that has no language code is the logo image

Different issue, i will open new issue

Imho, 301 is indeed the wrong redirect as the origin URL is still valid. It hasn't moved permanently. It's only temporary or "see other". So 302 or 303 are the appropriate redirects.
On a sidenote: google.com redirects using a 302 to the localised country domain (eg google.ch).

I've been tearing my hair out trying to figure what I may have changed to cause the language to get stuck. I applied the patch, learned Joomla and browser cache and now it seems to be functioning as it should be.