I would prefer (B/C) you keep the Options # as they were, as well as Default.
Add the new Option with a new #.
And also explain why you want to get rid of cookies.

ok i understand the options part, i can change it.

The "Set-Cookie" http header can be problem with server/proxy frontend caching, with the "Set-Cookie" http header no server/proxy cache is made.
This happens because the server/proxy cache always thinks it's a new page so it doesn't cache it or cache it per session (not global page cache).

In joomla you can disable the session "Set-cookie" http header by disabling the cookie plugin.
But, as it is, you cannot disable the langfilter cookie, this pull request is for allowing that flexibility.

Understand the reason.
I'm a lonely fighter against parameters bloating and its corresponding Usability Experience toll, and as such I wonder why you need to add a parameter option in languages, as there is already the enabled state parameter of the joomla cookies plugin which is there to tell same. So 2 questions:

1. Why not check that existing parameter ?
2. Optionally: We could take that opportunity to clean-up the cookies software architecture here at same time than avoiding adding yet another option and implement a Single Point of Responsability ? Maybe we could we use the joomla cookies plugin for that cookie too ? That way, when the joomla cookies plugin is disabled, all joomla cookies are not sent anymore ?

hi beat, i think that is a really good idea!
Joomla system cookies should be controled from just one place.

I agree that if the joomla auth cookie plugin is disabled it should not send the langfilter plugin cookie. Also the cookie lifetime choice is already in the auth cookie plugin. And, since they are two joomla core plugin, i don't see really no benefits in overridding that value for the langfilter plugin. But i don't have sufficent joomla core knowledge to analyse that in deep.

I can help, but i just don't have suficcient joomla core knowledge to do the changes you propose without risk of breaking something else ...

Please don't use parameters from another plugin. That would be code nightmare.
I'm also not that convinced yet that this makes sense.

The "Authentication - Cookie" plugin is the "remember me" functionality. It makes sure that you are automatically logged in again on your next visit. For that, a cookie is created on your machine.
It can be seen as a (minor) security risk and can be disabled for that reason.

Correct me if I'm wrong but the language filter plugin (to my knowledge) creates a cookie to store your current language selection. It isn't tied to a user at all and will also work for guests. Also it has no impact on security at all.

So the two plugins serve completely different needs and shouldn't be tied together.

You could maybe use the setting from the global configuration (I think that's what Beat meant). If the session storage is disabled, disabled also the cookie in the language filter. However I'm not sure if that will always be the expected behavior.

Personally I don't have an issue with adding a new option to existing parameters as proposed in this PR. I can however see the UX issue with adding additional parameters. Especially if the same could be achieved with simple template overrides and the like.

Ah, the rememberme function being security-related, then things should be kept separate as it would not be "Single Point of Responsability" anymore.

ok so i will leave the PR as it is.

Another approach to solve this issue is to use HTML5 local storage instead of cookie. It comes with a price though Not all the browsers support it (IE7), more info here:
http://caniuse.com/#search=Storage
Joomla is using it for tab state:
https://github.com/joomla/joomla-cms/blob/staging/libraries/cms/html/behavior.php
@ptopenweb @Bakual

IE7 isn't supported by Joomla 3 anyway. IE8 is the lowest. See http://docs.joomla.org/Joomla_Browser_Support

I guess then that we can elevate the language plugin from cookie to HTML5 local storage, or there’s something I am missing?

I think one issue with local storage is that you will need JavaScript to read it and send the data to the server. Unlike cookies which are sent with the request automatically.
So it will need a bit different approach I think.

@Bakual You are right js is needed, but in return joomla! gets to be very friendly for varnish or any other proxy. But If I was supposed to code that I wouldn’t do it like is done in tabs, with the script as a file (one more http req) but I would use addScriptDeclaration(). Of course this is a lot more work than just adding one option to skip the cookie altogether, but I think it’s worth it

This PR does not take cate of all code concerning lang cookie.

Closing in favur of

#5126

Which needs testing as there are apparently some issues when user logs

This comment was created with the J!Tracker Application at issues.joomla.org/joomla-cms/4092.