Have you tested this on a multilanguage site? What could be the impact?

Sounds like a good idea

@infograf768 - yes, I'm testing this on multilingual sites. The issue has always been that the language redirect plugin does a 303 redirect when there is no lang parameter in the url.
If you are making a get request - the browser would still fetch the request, which is ok, but not good for perfomance. If you do anything else like DELETE, PUT etc the redirect plugin still does a 303 redirect, but this time we have a get request and not the original DELETE, PUT - so your code is no longer working.

The code change I propose shouldn't have any impact on existing installs. It just ads the option to go around the stupid redirect without having to add a lang variable to the url.

The problem with adding the language to url is that you have to call JLanguage and get the lang_code. Then you have to store this in a JS variable and have to add it to your url (we can't use just lang=en, because some people are removing en from their installs???)

If someone has a better idea about this I'm all ears. This has annoyed me for long time. I've even faked GET requests as POST to just go around that stupid thing.

I guess I would just have to wait a concrete example from you to be able to judge on a real test as I am not sure I understand.
For example:

it will set a default language and won't bother redirecting you somewhere else.

Do you mean the "current language" or the "default site language"?

Also, would this parameter be present in the language filter plugin or per specific component or in Global Settings?

This parameter won't be present anywhere. No global config, no language filter plugin settings. This is a parameter for developers, that don't want to have a redirect by the language filter.

If you do a post request, here is what the language filter does:

// We are called via POST. We don't care about the language
        // and simply set the default language as our current language.
        if ($this->app->input->getMethod() == "POST"
            || count($this->app->input->post) > 0
            || count($this->app->input->files) > 0)
        {
            $found = true;

            if (!isset($lang_code))
            {
                $lang_code = $this->app->input->cookie->getString(JApplicationHelper::getHash('language'));
            }

            if ($this->params->get('detect_browser', 1) && !$lang_code)
            {
                $lang_code = JLanguageHelper::detectLanguage();
            }

            if (!isset($this->lang_codes[$lang_code]))
            {
                $lang_code = JComponentHelper::getParams('com_languages')->get('site', 'en-GB');
            }
        }

We set the default language as the current language. Then few lines later, we won't end up in the if (!$found) and do a redirect.

The only change I'm proposing is to add a check for $this->app->input->get('nolangfilter', 0) == 1, if we have nolangfilter=1 in the url, we will end up in the above POST block, we will set the $lang_code to the current language and our request will behave as expected (we won't experience an unwanted redirect).

This is all. Do you understand it better now?

Stll need to test
Side Note: it seems you are using an obsolete version of the plugin as present code is:

        // We are called via POST. We don't care about the language
        // and simply set the default language as our current language.
        if ($this->app->input->getMethod() == "POST"
            || count($this->app->input->post) > 0
            || count($this->app->input->files) > 0)
        {
            $found = true;

            if (!isset($lang_code))
            {
                $lang_code = $this->getLanguageCookie();
            }

            if ($this->params->get('detect_browser', 1) && !$lang_code)
            {
                $lang_code = JLanguageHelper::detectLanguage();
            }

            if (!isset($this->lang_codes[$lang_code]))
            {
                $lang_code = $this->default_lang;
            }
        }

The only thing that bugs me is that it may (and most likely will) end up in yet another undocumented feature of our CMS.

At the same time there is already the possibility to send the lang code with the request, which solves the issue as well. Yes, it nees a bit more code to pass the request as you explained above, but imho that isn't such a big deal. At least if the request is generated by Joomla. If it's coming from an extern place - it will be more complicate.

@Bakual - that is what I thought as well.

On the other hand - having to figure out the language just do send a DELETE request and delete item XYZ is annoying.

I've written in the past how annoying it is having to deal with that: https://compojoom.com/blog/entry/ajax-requests-on-multilingual-joomla-websites

The plugin is turned on on some sites, but turned off on another. The plugin is deciding that a POST request doesn't need any redirecting, but all other do? If this plugin is assuming all this, then why not make it able to do one more assumption?

Do you have better Ideas? I agree that this might end-up as another undocumented feature, but the current plugin behavior is also not documented. It's first when you see the redirects in the console when you start sniffing around and you find after few hours of digging that pluginX is doing a redirect. If you've found that pluginX is doing redirect because of condition Y and you have the chance to disable this behavior completely, why not?

but the current plugin behavior is also not documented.

True enough. Using &lang=* or so would maybe be more intuitive, but not sure how B/C this would be, it sure would need more code. I don't see a better approach myself and your suggestion sure is B/C.

@compojoom What is the status of this PR?

Looks like it is just waiting for people who understand it to find a way to
test it

I have tested this item ✅ successfully on 18c5aaa

I successfully tested this by using the mod_finder AJAX GET request and applying the &nolangfilter=1 to the URL. Please note that I removed the JRoute of the mod_finder serviceUrl, as this causing the input filters reading amp;nolangfilter instead of nolangfilter.

Without patch applied:

Request URL: http://joomla/index.php?option=com_finder&task=suggestions.suggest&format=json&tmpl=component&nolangfilter=1&q=langu
Request Method:GET
Status Code:303 See other

Request URL:http://joomla/index.php/nl/?option=com_finder&task=suggestions.suggest&format=json&tmpl=component&nolangfilter=1&q=langu
Request Method:GET
Status Code:200 OK

With patch applied:

Request URL:http://joomla/index.php?option=com_finder&task=suggestions.suggest&format=json&tmpl=component&nolangfilter=1&q=langu
Request Method:GET
Status Code:200 OK

So with the patch applied the 303 redirect doesn't take place.

Thanks @compojoom!

@sanderpotjer got on index.php?option=com_finder&task=suggestions.suggest&format=json&tmpl=component&nolangfilter=1&q=langu

without PR:

with PR:

I don't see a problem with the language plugin returning 3xx redirects when needed.
any ajax requesting app should be following redirects IMHO.

reggarding the PUT and DELETE (and even POST) methods the main issue is that the 301/302/303 redirects does not preserve the sended data on redirect.
if i'm correct 307/308 redirects solve that issue (see https://tools.ietf.org/html/rfc7538).

So if you change here https://github.com/joomla/joomla-cms/blob/staging/plugins/system/languagefilter/languagefilter.php#L446 the redirects codes from 301 to 308 and from 302 to 307 they should work.

at least for me worked (tried with this curl CLI command)

curl -Lkv -X "PUT" -d "foo=bar" -H "Host: mydomain.tld" https://127.0.0.1/index.php?option=com_content&view=featured

With the 308 redirect the "foo=bar" data was preserved, with 301 redirect it was not.

The problem is AFAIK some older browsers supported by Joomla 3.x (IE10- i think) ... don't support 308 redirects.
So for Joomla 3.x series the only workaround i see is making the same that was done for post method, ie, no redirect. And maybe in 4.x use the 307/308 redirects and remove those workarounds.

I have tested this item ✅ successfully on 18c5aaa

Tested:

Chrome (60.0.3112.101)

1. Opened Network Tab in developer tools
2. Check 'Preserve log' (!)
3. Visited /index.php?option=com_finder&task=suggestions.suggest&format=json&tmpl=component&nolangfilter=1&q=langu
4. Activated bugfix
5. Visited /index.php?option=com_finder&task=suggestions.suggest&format=json&tmpl=component&nolangfilter=1&q=langu again

Firefox (55.0.2)

1. Opened Network Tab in developer tools
2. Visited /index.php?option=com_finder&task=suggestions.suggest&format=json&tmpl=component&nolangfilter=1&q=langu
3. Activated bugfix
4. Visited /index.php?option=com_finder&task=suggestions.suggest&format=json&tmpl=component&nolangfilter=1&q=langu again

Behaviour

Chrome

With the bugfix not activated, the request is redirected (302) as described above. When the bugfix is enabled, the request can be executed directly without a redirect. Please note: To recreate this under Chrome, 'Preserve log' needs to be activated. Otherwise, Chrome will only show the final (successfull) result.

Firefox

With the bugfix not activated, the request is redirected (302) as described above. When the bugfix is enabled, the request can be executed directly without a redirect.

Tested @icampus

RTC after two successful tests.

@compojoom please resolve conflicting Files.

@compojoom can you please resolve conflicting Files?

Replaced by #21011 with merge conflicts resolved.