I am unable to replicate this. Please click on Multilingual Status and check that there are no errors or warnings

I am unable to replicate this. Please click on Multilingual Status and check that there are no errors or warnings

All is fine there:

But the issue occurs.
I've switched to PHP 7.4 and it did not help (I checked it for some case)

Well, I can send you credentials to examine the site if you wish.
Please note that this is a clean installation. No any 3rd party extension was installed except language package.

A bunch of screnshots:
Categories:

Articles:

Home menu ENG:

Home menu RUS:

Home menu (all languages):

Content languages:

System language filter:

The screen with the issue:
URL: https://domain.com/index.php/en/ (there should not be /en/ prefix for default language in language switcher)

@Sulpher Maybe it comes from not creating new categories and menus for both languages English and Russian but using the ones coming with the installation for all languages for English, changing their language from "All" to English?

What happens if you again make a new installation like you have shown in the video, but then in backend not touch the "Uncategorised" category and the "Main" menu and the module for that menu which are all tagged for all languages and create a new category and a new menu also for English and not only for Russian, and also a new module for the English min menu, and just unpublish the main menu for all languages?

That shouldnt make any difference

Shouldn’t … but it’s worth to be checked.

Well. I made a clean installation on the localhost (PHP 7.4) and repeated all actions - no such issue, all is fine.
There is PHP 8.0.3 and no mod_rewrite is in use at the hosting where this issue exist.
Then I made copy of the website that has this issue on my hosting via Akeeba and launched its copy at the localhost and it works fine again. No such problem occurs.
I even switched to PHP 7.4 and the hosting and mod_rewrite is still not used. So, the sites are identical on the localhost and at the hosting.
Thereby the reason is in hosting/server.
Is anyone needs more details to examine this issue? Maybe such problem can occur in another hostings too.

But what is strange is that mod_rewrite is not in use and htaccess file even not renamed (which could impact on server).

PHP Built On | Linux vh306 5.4.0-74-generic #83~18.04.1-Ubuntu SMP Tue May 11 16:01:00 UTC 2021 x86_64
Database Type | mysql 5.7.33-36
PHP 7.4.22
Webserver: Apache/2.4.29
WebServer to PHP Interface: apache2handler
Joomla! 4.0.2 Stable [ Furaha ] 24-August-2021 19:54 GMT

Maybe there is a problem with some PHP extensions?

I have the same problem with mod_languages

The Joomla! menu mod_menu works fine and knows how to rewrite.
But mod_languages always places the language-code (in my case /de/) even I set "Remove URL Language Code" at Language Filter Plugin.

There have never be problems with this at Joomla! 3.x before ... problem is new with Joomla 4.x

Additional info: I've disabled Search Engine Friendly URLs and all works fine. The problem is related to SEF/server configuration.

Additional info: I've disabled Search Engine Friendly URLs and all works fine. The problem is related to SEF/server configuration.

What does this mean?
Does it mean the problem is not the Joomla!-module but the web-server?
I wonder, cause it workes fine in J3

And rewriting works with the Joomla!4-menu. The problem comes only with the language-switch module

Additional info: I've disabled Search Engine Friendly URLs and all works fine. The problem is related to SEF/server configuration.

What does this mean?
Does it mean the problem is not the Joomla!-module but the web-server?
I wonder, cause it workes fine in J3

And rewriting works with the Joomla!4-menu. The problem comes only with the language-switch module

As I mentioved above, I made a backup of the site and launched it locally and it worked fine.
It means that there is something wrong in J4 script/switcher module/router which work wrong on some server environment and work fine with other servers. So, the problem is in J4 since the CMS must work stable with the different server environments.
So, somebody should debug it and find the reason.

I can provide credentials to any developer who has the experience and can debug the code to find the problem.

Same issue here. There have never been a problem with the same site on the same server with Joomla! 3.x. Problem is new with Joomla 4.x

I have the same issue. Language code of the default language is displayed in the URL, while it shouldn't when Remove URL Language Code is on "Yes". And I confirm the issue doesn't happen with J3.

localhost with MAMP, php 7.4.2: all is fine.

On the Hoster (INONOS und Rochen) with the switcher problem you need to set the Rewrite Base in the .htaccess. On the hoster without problemens not.

On the Hoster (INONOS und Rochen) with the switcher problem you need to set the Rewrite Base in the .htaccess. On the hoster without problemens not.

I uncommented RewriteBase / and refreshed the site page by clearing the cache, but it took no effect. the problem still exists.

I can confirm this issue on one of the largest Latvian shared hosting.

I had the same problem of not being able to switch to the default site content language from other languages (getting a 404 error) and found a WORKAROUND FIX for it.

My configuration:
WebServer - LiteSpeed V7.9 Cloudlinux 1.3
Joomla - 4.03
PHP - 8.0.8

PLEASE NOTE !!!
IN ALL THE LINES BELOW xx is your DEFAULT SITE CONTENT LANGUAGE CODE - for example en for English.

Global Configuration / Site / SEO

Search Engine Friendly URLs - Yes
Use URL Rewriting - Yes
Add Suffix to URL - Yes
Unicode Aliases - No

System - SEF plugin enabled with the following settings:
Site Domain - https://www.my-site-domain.xx

System - Language Filter plugin enabled with the following settings:

Language Selection for new Visitors - Browser Settings
Automatic Language Change - Yes
Item Associations - Yes
Add Alternate Meta Tags - Yes
Add x-default Meta Tag - Yes
x-default Language - Default frontend language
Remove URL Language Code - Yes
Cookie Lifetime - Session

I use the Joomla default Language Switcher set to:
Language - All

Now for the WORKAROUND FIX:
IN ALL THE LINES BELOW xx is your DEFAULT SITE CONTENT LANGUAGE CODE - for example en for English.

I added the following rule to the .htaccess in the Custom redirects section (before SEF):

RewriteCond %{REQUEST_URI} !^/xx/$
RewriteRule ^xx/(.*)$ /$1 [R=301,L]

It rewrites the "/xx/" part of the URI to "/" so it fixes the problem while viewing an article in some other language and switching to default site content language using Language Switcher. The rule has an exception - not to include the specific "/xx/" URI - which after rewrite should point to the root directory link '/', but it doesn't work that way - if there is no RewriteCond exception - clicking on the Language Switcher in the site home / root directory '/' won't change the language from other to the default site content language, it will stay on the other currently set.

In this stage, clicking on the Language Switcher in the site home / root directory '/' would give a 404 error - because it's excluded by the forementioned RewriteCond. For that to work, I use the Joomla Redirects - as it handles the language change properly.

Enable the plugin System - Redirect

Go to System Dashboard / Redirects

Make a new rule with the following settings:

Expired URL
/xx/

New URL
/

Status
Enabled

Clear site and browser cache.

All the links redirect flawlessly and language is changed properly.
Maybe someone would think of a much cleaner way to sort this out, but this works for me ;-).
Still - waiting for some inside Joomla fix, this is just a guerilla approach ;-).

Cheers!

@Sulpher: "Additional info: I've disabled Search Engine Friendly URLs and all works fine. The problem is related to SEF/server configuration."

I have my hosting at Rochen, and have the same switcher problem.

When I disable SEF the links across language pages works okay.

When I do not disable SEF finder works okay, after disabling SEF it stops working, and presents this as error message:
"404
View not found [name, type, prefix]: article, html, site"

I tried deleting the finder index and re-indexing all content, but this does not solve this extra issue.

I checked with the now latest version J4.04.

I will ask Rochen if they have any ideas on solving the issue, amd report back when I hear from them.

Cheers!

The problem seems to be solved :-)
But when going back to default language ?format=html is printed after the alias.

Hello,

i have the same problem!

It works well in joomla 3 and with joomla 4 local (xampp) it also works well.

So i think this is hosting problem but what is the solution?

I have also open a topic on https://forum.joomla.org/viewtopic.php?f=812&p=3643966#p3643966

Wait for your reactions.

Thank you.

Regards Ron :-)

The URL with the default language in it should still work even with the remove language code enabled. It does so on 3.x.

Hello,

I have still the problem.

The default language is German.

When you would go to my site, it would be www.site.com so not www.site.com/de
When I go to my Dutch site, it is www.site.com/nl and after that I go back to the German site and then the URL is www.site.com/de (wrong URL) and I get 404 messages.

Remove URL Language Code is on YES and that works well when you enter my site but not via module language switcher :(

Is this Joomla 4 bug because in Joomla 3 everything works fine!

Greetings Ron :)

I can try to find the issue origin if somebody has the working dev site (where the problem can be reproduced) and the Joomla super user credentials are informed (please use the contact form https://alterbrains.com/contact-us, not here). Additionally, FTP access is appreciated.

Hello AlterBrains,

Thank you for your offer.

Do you do this for free or do I have to pay?

What I find strange is that this bug was already reported in September 12, but there is still no neat solution for it.

Regards Ron

@Joomron I can explore the problem for free, just saw the post in FB group and can try to help.
And there is nothing strange, there are tons of open PRs/Issues but Joomla is community-driven :)

What I find strange is that this bug was already reported in September 12, but there is still no neat solution for it.

One of the reason is we could not easily re-procedure the issue. Yesterday, I tried to look at it, too, but I could not re-produce the issue both on PHP 7 and PHP 8 :(.

@AlterBrains I have sending you a mail ;)

@joomdonation I now have hosting parties where the problem occurs Vimexx and Hosting2go :(

You can have a look here: https://ourweb-projekt.de/joomla4/

It is Joomla 4.0.4 with Multilanguage Sample Data installed, Hosting is by IONOS

You can have a look here: https://ourweb-projekt.de/joomla4/

It is Joomla 4.0.4 with Multilanguage Sample Data installed, Hosting is by IONOS

@paternax You have same problem i see :( And you have set Remove URL Language Code on Yes ?

Yes I did

Please scroll to ISSUE RESOLUTION below if you just need a solution. Otherwise, please take your seats:

How to reproduce:

1. setup two languages, EN is default
2. enable " System - Language Filter" plugin, set "Remove URL Language Code" to YES, set "Language Selection for new Visitors" to "Site Language"
3. publish language switcher module somewhere.
4. Create homepage menu items for each language of the same type, i.e. "category blog" for language-specific category
5. associate menu items
6. associate content categories (important!)
7. load site, switch to non-EN language via language switcher module
8. click EN flag in language module, see error for the URL like https://site.com/en/

Check PlgSystemLanguageFilter::parseRule(), lines 400 - 406:

		// We are called via POST or the nolangfilter url parameter was set. We don't care about the language
		// and simply set the default language as our current language.
		if ($this->app->input->getMethod() === 'POST'
			|| $this->app->input->get('nolangfilter', 0) == 1
			|| count($this->app->input->post) > 0
			|| count($this->app->input->files) > 0)
		{

The code is triggered and $found is set to true, hence the redirect to https://site.com required in lines 348-358 never happens:

				// If we found our language, but it's the default language and we don't want a prefix for that, we are on a wrong URL.
				// Or we try to change the language back to the default language. We need a redirect to the proper URL for the default language.
				if ($lang_code === $this->default_lang && $this->params->get('remove_default_prefix', 0))
				{
					// Create a cookie.
					$this->setLanguageCookie($lang_code);

					$found = false;
					array_shift($parts);
					$path = implode('/', $parts);
				}

The code in lines 400 - 406 is triggered on the dev site provided by @Joomron because count($this->app->input->post) > 0 is evaluated even though request method is GET.

IMHO it's ridiculous to check for FILES or POST if request method is not POST. We are getting closer!

$this->app->input->post is an instance of Joomla\CMS\Input\Input and it should not contain any data on GET but it contains the cookies! Even though global $_POST is empty:

print_r($this->app->input->post);print_r($_POST);print_r($_COOKIE);die;

results:

Joomla\CMS\Input\Input Object
(
    [inputs:protected] => Array
        (
        )

    [options:protected] => Array
        (
        )

    [filter:protected] => Joomla\Filter\InputFilter Object
        (
            ...
        )

    [data:protected] => Array
        (
            [e7b0570ff50a05e8418c602ab81e93a1] => 9cc599fgdfgdfgdfgdfga53231c1
            [5c0408972a6555b170211cc2f9750d32] => a728bedfgdfgdfgdfg7a5e7881517b72
        )

)
Array
(
)
Array
(
    [e7b0570ff50a05e8418c602ab81e93a1] => 9cc599fgdfgdfgdfgdfga53231c1
    [5c0408972a6555b170211cc2f9750d32] => a728bedfgdfgdfgdfg7a5e7881517b72
)

So, why the hell $this->app->input->post contains the data on GET?

$this->app->input->post is auto-created via Joomla\CMS\Input\Input::__get() which creates new instance using the $_GLOBALS['_POST'] as a source of data:

if (\in_array(strtoupper($name), self::$allowedGlobals, true) && isset($GLOBALS[$superGlobal]))
		{
			$this->inputs[$name] = new Input($GLOBALS[$superGlobal], $this->options);

			return $this->inputs[$name];
		}

New instance of Joomla\CMS\Input\Input is created using empty array, Joomla\CMS\Input\Input::__construct() calls parent's Joomla\Input\Input::__construct() which uses $_REQUEST as a data source if passed source if empty!

	/**
	 * Constructor.
	 *
	 * @param   array  $source   Optional source data. If omitted, a copy of the server variable '_REQUEST' is used.
	 * @param   array  $options  An optional associative array of configuration parameters:
	 *                           filter: An instance of Filter\Input. If omitted, a default filter is initialised.
	 *
	 * @since   1.0
	 */
	public function __construct($source = null, array $options = [])
	{
		$this->data    = empty($source) ? $_REQUEST : $source;
		$this->filter  = $options['filter'] ?? new Filter\InputFilter;
		$this->options = $options;
	}

So, even though we have GET request method, $this->app->input->post will contain the data - cookies in our case because on dev site, $_REQUEST contains cookies:

print_r($_REQUEST);print_r($_COOKIE); die;

Array
(
    [e7b0570ff50a05e8418c602ab81e93a1] => 9cc599fgdfgdfgdfgdfga53231c1
    [5c0408972a6555b170211cc2f9750d32] => a728bedfgdfgdfgdfg7a5e7881517b72
)1
Array
(
    [e7b0570ff50a05e8418c602ab81e93a1] => 9cc599fgdfgdfgdfgdfga53231c1
    [5c0408972a6555b170211cc2f9750d32] => a728bedfgdfgdfgdfg7a5e7881517b72
)

On usual servers, $_REQUEST doesn't contain cookies. And it's recommended!

Now the issue is clear. Different settings of PHP variable on servers....

See the PHP variable request_order: https://www.php.net/manual/en/ini.core.php#ini.request-order

On dev server, it's empty, dev server uses strange PHP 7.4.22 which doesn't even have opache enabled (!).

request_order does not have any value though it should be "GP" and it's like this in absolutely most default php.ini files.

Even PHP documentation stands for:

Note that the default distribution php.ini files does not contain the 'C' for cookies, due to security concerns.

Hence, variables_order is used: https://www.php.net/manual/en/ini.core.php#ini.variables-order

Dev server's variables_order is EGPCS, even though it's usually GPCS by default, but it's not critical for our case.

That's why dev server's $_REQUEST insecurely contains cookies.

Another question us why the hell Joomla\Input\Input::__construct() insecurely uses $_REQUEST as a default source of data is empty array (not a null) is passed to constructor...

ISSUE RESOLUTION:

Set the GP as a value for PHP variable request_order.

And try to avoid hosting services which don't use default settings for php.ini from https://github.com/php/php-src

PS. all cookie values changed. 3 hours spent, it was an exciting challenge!

great work @AlterBrains! Thank you for investigating this problem and to everyone who took part into this thread.
Maybe it's worth updating Joomla System requirements article and mentioning this PHP param to be set correctly?

Very interesting discussion.
I am facing an issue with my 3 multilingual J4 sites (each at a different host!), do you think it is related?

See for example https://www.dynamique-solutions.be/ (in construction, started yesterday).
Issue 1 : in J3 it would automatically go to either /en or /fr
Issue 2 : whatever the page, the link on the the "Logo" is https://www.dynamique-solutions.be/ (without language code). If you click many many times on it, sometimes it displays French, sometimes it displays English. No consistency...

Thank you @AlterBrains your solution works

Pinging @SniperSister because this is actually a hidden security issue in Joomla. I also think @nibra should be alerted, IIRC he's in the framework team and the root cause is in the framework code, not the CMS code.

The real problem is how the Input class words. This line

$this->data    = empty($source) ? $_REQUEST : $source;

should actually read

$this->data    = is_null($source) ? $_REQUEST : $source;

The way it's written the magic properties get, post, cookie will be populated with the $_REQUEST superglobal contents if $_GET, $_POST or $_COOKIE respectively are empty.

This could lead to input variable shading which could potentially be abused against otherwise correctly written Joomla extensions which check for variables from a specific provenance (e.g. only POST variables on a controller task which should only be called through a POST request). This is exactly what happened here even though the end result was merely annoying instead of a major security issue. Next time we might not be that lucky...

is_null() is absolutely not sexy in 2021, it's better to use null-coalescing or at least direct comparison, nothing serious :)

$this->data = $source ?? $_REQUEST;
Or as min:
$this->data = $source === null ? $_REQUEST : $source;

My personal preference on code style is terse code. I'd be using null coalescing and refactor the living crap out of that constructor. However, I am not sure if the average drive–by Joomla contributor would understand it.

While I personally prefer null coalescing, I'd rather Joomla used is_null to reduce the probability of someone messing up in the future because they didn't understand the difference between null coalescing ?? and Elvis ?: operators or the difference between loose type comparison == and type–safe comparison === operators. Think about it as child–proofing the core code. It doesn't need to look sexy, it only needs to keep naughty kids from burning down the house.

Thanks @AlterBrains for the solution!

I have sent my hosting a mail with your solution!

Have a nice weekend

:)

@nikosdion thanks for the heads up, will look into it with the team!

Because my hosting does not want to cooperate and they will only switch to PHP 8 later this year, I have put the code below in .htaccess
php_value request_order GP
I got the solution from Johan Peters thanks friend :)

Hi, I have the same issue since I am using J4.
I read the thread above, also see, there is a solution.
Unfortunately, I can´t really use that - I am not a dev, just an experienced user.
Also saw the last comment of Joomron to add a line to the htaccess, which I did - but no success.

Can someone pls tell me, what to add where in order to solve that?
Thanks a lot!

On a side note:

Because my hosting does not want to cooperate and they will only switch to PHP 8 later this year, I have put the code below in .htaccess php_value request_order GP I got the solution from Johan Peters thanks friend :)

I have just tried adding the line in .htaccess but it gives an Internal Server Error with the following hosting companies: OVH & Infomaniak.

With PlanetHoster, adding the line does not generate the Internal Server Error... but the issues simply does not exist neither in the first place.

@woluweb On the vast majority of servers you will not observe the issue as the request_order does not include C (cookies). In fact, the official PHP documentation explains why this shouldn't be set:

Note that the default distribution php.ini files does not contain the 'C' for cookies, due to security concerns.

Simply put, a server operator should never , ever add C there to auto–register $_REQUEST variables for cookies. Whoever does that is absolutely ignorant about server security. Thankfully, the vast majority of server operators are not stupid like that.

This is also the reason why this problem has existed for years, definitely since Joomla 3 and probably even earlier. Nobody had worked with a host so utterly incompetent as to include cookies in the $_REQUEST superglobal.

That's another point to make here, especially to @theweasel68. No, just because you are using Joomla 4 it does not mean that you are affected. You are only affected if you use any version of Joomla released the past 8 years or so AND your host is doing something completely stupid. In my opinion, sure, Joomla SHOULD work around a bad server configuration BUT if your host is so stupid as to misconfigure their servers like that you should also consider moving to a competent host. There is no conceivable use case where registering cookie variables in $_REQUEST makes sense.

So far I can only say that until 3x it worked as far as I can say (I am not testing the language switcher again with every update).
After updating to 4x it does not work anymore.

Is the Host unprofessional or stupid? I don´t know - at least I don´t think so, as they are widely known and used in DE (https://all-inkl.com/).

Sad that Joomla 3 is ok, and Joomla 4 is not ?

@b2z I don't know if you participated in a different conversion than everyone else. Two posts above yours I explicitly stated:

This is also the reason why this problem has existed for years, definitely since Joomla 3 and probably even earlier.

This does NOT affect just Joomla 4. It affects Joomla 3 and very likely older versions. I only bothered going as back as 2014 on the basis that if someone's using something more than 8 years old they have other, more important issues to deal with.

Again, this is NOT a Joomla bug. It's a host doing something COMPLETELY IDIOTIC. There is no possible use case where registering cookie data in the $_REQUEST superglobal makes sense. PHP warns that this is extremely bad for security and explicitly warns NOT to do that.

In my opinion, any systems administrator who enables registering cookie variables in the $_REQUEST superglobal on a shared hosting environment should be immediately fired and blacklisted from the industry forever. If you are on such a host go to a different host as fast as you can. If they have missed a glaring security issue that the PHP documentation actively warns about there's not a cat's chance in hell that they have figure out other, more nuanced security issues on their servers. In short, it's a shithost, avoid at all cost.

@b2z I don't know if you participated in a different conversion than everyone else. Two posts above yours I explicitly stated:

This is also the reason why this problem has existed for years, definitely since Joomla 3 and probably even earlier.

This does NOT affect just Joomla 4. It affects Joomla 3 and very likely older versions. I only bothered going as back as 2014 on the basis that if someone's using something more than 8 years old they have other, more important issues to deal with.

Nick, I am sorry, but it's still not clear for me: the same hosting but two Joomla websites based on Joomla 3 and Joomla 4.
The multilingual site works well on J3, but on J4 is not.
That's why I build new sites with multilingual features on J3 yet since all works fine while J4 is not. So... Maybe is there something that need to be patched in J4?

@Sulpher The problem is on the host, not with Joomla. They are registering the cookie variables in $_REQUEST. The default source of JInput and its successors is the $_REQUEST variable. It just so happened that Joomla 3's multi language feature didn't check if the request is empty, it checked if there are no URL query parameters. It was wrong because it'd cause a redirect with POST requests, breaking things like AJAX requests. Joomla 4 fixed that. Incidentally, fixing Joomla 3's bug uncovered your host's WRONG PHP configuration.

Let me put it in a way you'll understand. There's this gas station you always refuel your car at. The owner puts water in the gasoline. Your old Zhiguli didn't have a problem running on the adulterated fuel; the damn thing was built to run on vodka if need be... but it was also very slow, inefficient and unreliable. Your new Ford Focus is much faster, very efficient and very reliable, but it does not run on the adulterated fuel. It sputters and stops. Do you really think that the Soviet-era Zhiguli is a better car than Ford Focus and Ford needs to change the engine to make it run on adulterated fuel just like the Zhiguli, with all the speed, efficiency and reliability issues that entails? Or do you think that the gas station owner should just stop putting water in the damned gasoline?

Think about this. For me the answer is pretty clear.

@Sulpher The problem is on the host, not with Joomla. They are registering the cookie variables in $_REQUEST. The default source of JInput and its successors is the $_REQUEST variable. It just so happened that Joomla 3's multi language feature didn't check if the request is empty, it checked if there are no URL query parameters. It was wrong because it'd cause a redirect with POST requests, breaking things like AJAX requests. Joomla 4 fixed that. Incidentally, fixing Joomla 3's bug uncovered your host's WRONG PHP configuration.

Let me put it in a way you'll understand. There's this gas station you always refuel your car at. The owner puts water in the gasoline. Your old Zhiguli didn't have a problem running on the adulterated fuel; the damn thing was built to run on vodka if need be... but it was also very slow, inefficient and unreliable. Your new Ford Focus is much faster, very efficient and very reliable, but it does not run on the adulterated fuel. It sputters and stops. Do you really think that the Soviet-era Zhiguli is a better car than Ford Focus and Ford needs to change the engine to make it run on adulterated fuel just like the Zhiguli, with all the speed, efficiency and reliability issues that entails? Or do you think that the gas station owner should just stop putting water in the damned gasoline?

Think about this. For me the answer is pretty clear.

You definitely have a sense of humor :-)) In fact, this is not a correct example because you used cars from a different era. Zhiguli was designed in 1970 and based on Italian Fiat, it does not use vodka and it is obsolete now. It is like comparing ZX-Spectrum and PC-based computer. Different epoch, different input data.
Let's return back to Joomla.
In other words, I've never seen the wrong work of multilingual sites based on J3 before J4 arrived and as you explained, it is because J3 did not check something in the code. Does it mean that the most of hostings come with the wrong configuration?
But as you wrote above (#35541 (comment)), changing some setting on the server-side is insecure.

So... what a typical user has to do? Is there that need to be fixed in Joomla or we must submit a request to hosting support asking to enable something on the server side? And... Will it break security or not?
Thanks.

Well, Joomla 3 and Joomla 4 have as much in common as the Zhiguli. Joomla 3 is 2009 technology, Joomla 4 is 2017 technology. These 8 years in computer years is the same as the 50 years separating the Zhiguli and the Ford. In both cases you can say the two things have some common lineage but the evolution that's taken place between them means they are very different, too.

In other words, I've never seen the wrong work of multilingual sites based on J3 before J4 arrived and as you explained, it is because J3 did not check something in the code.

Yes.

Does it mean that the most of hostings come with the wrong configuration?

NO!. Most hosts are not morons. Most hosts know what they are doing and do NOT enable registering cookie variables in $_REQUEST EXACTLY BECAUSE PHP itself warns them that this is stupid and insecure.

The problem is the minority of hosts who ignore the PHP documentation, have no idea about how site security works and do something completely moronic. Like your host.

But as you wrote above (#35541 (comment)), changing some setting on the server-side is insecure.

INCORRECT!. Read my comment again. Your host has changed the default, secure PHP setting to something INSECURE. The problem is that your host is a bunch of irresponsible morons who cocked up security for no good reason and against the clear warnings of the PHP documentation. If they can't understand something as basic as query parameter shading by cookies (it allows for dead easy phishing and cross–site attacks, for Pete's sake!) I seriously doubt they are competent enough to run a host. Even more so because this is not the case of someone not knowing to change an insecure default, it's the exact opposite: the idiot server administrator had to go and deliberately sabotage the security of the site's hosted on the server!!!

So... what a typical user has to do? Is there that need to be fixed in Joomla or we must submit a request to hosting support asking to enable something on the server side? And... Will it break security or not?

There is nothing to fix in Joomla. Joomla is not broken. What Joomla does is correct. It expects that the $_REQUEST superglobal will only include query string parameters and POST data, expecting that one might shade the other. It also expects that no server environment variables and cookies will be contained in the $_REQUEST superglobal because the PHP documentation clearly warns against doing that (and also because it's really fucking stupid for anyone to do that!).

Regarding security, IF YOU ARE ON AN AFFECTED SERVER YOUR SECURITY IS ALREADY COMPROMISED. Your server is INSECURE BY DESIGN.

What you should do? Tell your host they are fucking morons and demand that they fix their configuration. If they decline, go to a different host immediately.

THERE IS ABSOLUTELY NO VALID REASON WHATSOEVER FOR A HOST TO DELIBERATELY SABOTAGE THE SECURITY OF YOUR SITE BY REGISTERING COOKIES IN THE $_REQUEST SUPERGLOBAL. THERE IS ABSOLUTELY NO VALID REASON WHATSOEVER TO CONTINUE HOSTING YOUR SITES ON A SERVER OPERATED BY A COMPANY WHICH HAS SHOWN COMPLETE INCOMPETENCE IN PROVIDING A SECURE HOSTING ENVIRONMENT AND, IN FACT, WENT OUT OF ITS WAY TO IGNORE THE CLEAR AND EXPLICIT WARNING IN THE PHP DOCUMENTATION TO DELIBERATELY SABOTAGE THE SECURITY OF ITS SERVERS.

It's like a firm offering office space for rent where they have deliberately drilled through load bearing columns. It is extremely dangerous and unconscionable.

closing as not a Joomla issue

@theweasel68

So far I can only say that until 3x it worked as far as I can say (I am not testing the language switcher again with every update). After updating to 4x it does not work anymore. Is the Host unprofessional or stupid? I don´t know - at least I don´t think so, as they are widely known and used in DE (https://all-inkl.com/).

At All-Inkl: Create a file .user.ini in webspace of your Joomla. Enter:

request_order = "GP"

and you'll see.

But as far as I see all-inkl doesn't manipulate the option request_order and uses the PHP default settings (PHP 7.4.26, 8.0.13).

EDIT: But all-inkl sets

variables_order = EGPCS

which is a fallback setting for request_order when request_order is empty.

That said: You could also test

in your .user.ini if request_order is empty.

Thank you very much – I will try this!!

From: ReLater @.>
Sent: Donnerstag, 30. Dezember 2021 12:05
To: joomla/joomla-cms @.>
Cc: theweasel68 @.>; Mention @.>
Subject: Re: [joomla/joomla-cms] Issue with Remove URL Language Code (#35541)

@theweasel68 https://github.com/theweasel68

So far I can only say that until 3x it worked as far as I can say (I am not testing the language switcher again with every update). After updating to 4x it does not work anymore. Is the Host unprofessional or stupid? I don´t know - at least I don´t think so, as they are widely known and used in DE (https://all-inkl.com/).

At All-Inkl: Create a file .user.ini in webspace of your Joomla. Enter:

request_order= "GP"

and you'll see.

But as far as I see all-inkl doesn't manipulate the option request_order and uses the PHP default settings (PHP 7.4.26, 8.0.13).

—
Reply to this email directly, view it on GitHub #35541 (comment) , or unsubscribe https://github.com/notifications/unsubscribe-auth/AWURSOVEWSJKUR4ROBRRNELUTQ4GDANCNFSM5D4JMAQA .
Triage notifications on the go with GitHub Mobile for iOS https://apps.apple.com/app/apple-store/id1477376905?ct=notification-email&mt=8&pt=524675 or Android https://play.google.com/store/apps/details?id=com.github.android&referrer=utm_campaign%3Dnotification-email%26utm_medium%3Demail%26utm_source%3Dgithub .
You are receiving this because you were mentioned. https://github.com/notifications/beacon/AWURSOS7UQVGMRUUO7AKXITUTQ4GDA5CNFSM5D4JMAQKYY3PNVWWK3TUL52HS4DFVREXG43VMVBW63LNMVXHJKTDN5WW2ZLOORPWSZGOHPEEH5I.gif Message ID: @.*** @.***> >

I have at same issue on Joomla 4.x, but not on Joomla 3.10.x on the same server...

Which has already been explained

@alex-revo

I have at same issue on Joomla 4.x, but not on Joomla 3.10.x on the same server...

That has been answered already above. Check the server settings and/or ask your host! A security-relevant bug fix in Joomla 4 leads to this behavior.

@nikosdion @ReLater thanks for comments.

Nick, you wrote a big answer, but please note that despite the fact it is not Joomla problem, but it is problem that appears on various hostings where the Joomla 4 based sites are driven and it becomes a problem of webmaster/site integrator.

Not all hostings are bad and you should count that some people bought VPS and maybe cannot know some nuances.
As we can see - Joomla 3 does not do some checks and that's why we could trace this problem with security just now. Without this issue, we all even did not know about such a problem and security vulnerability.
So, I believe there should be kind of neutral information which every person can refer to and give such URL to hosting provider or use such text to submit a ticket to hosting provider. And if they will not fix it, then, of course, it's a reason to move the site to another provider.

@ReLater Is your post
#35541 (comment)
consist of enough information that is enough to provide to the hosting provider?

you should not buy a self managed vps if you dont have a clue what you are doing.

ReLater Is your post #35541 (comment) consist of enough information that is enough to provide to the hosting provider?

What shall I say? Test it for your Joomla installation and we all know better! One can remove the setting and the .user.ini file if one can set it in whatever other php.ini ;-)

If it doesn't solve the issue here we also know better.

The PHP manual speaks clear words about the "C" (security issue) and the inheritance of the setting.

I just know that IONOS, besides All-Inkl, standard(!) account has standard settings with the magic "C":

variables_order = EGPCS
request_order = ""

@eugene - good words!+1... sent while travellingAm 30.12.2021 15:53 schrieb Eugene @.***>:
@nikosdion @ReLater thanks for comments.
Nick, you wrote a big answer, but please note that despite the fact it is not Joomla problem, but it is problem that appears on various hostings where the Joomla 4 based sites are driven and it becomes a problem of webmaster/site integrator.
Not all hostings are bad and you should count that some people bought VPS and maybe cannot know some nuances.
As we can see - Joomla 3 does not do some checks and that's why we could trace this problem with security just now. Without this issue, we all even did not know about such a problem and security vulnerability.
So, I believe there should be kind of neutral information which every person can refer to and give such URL to hosting provider or use such text to submit a ticket to hosting provider. And if they will not fix it, then, of course, it's a reason to move the site to another provider.
@ReLater Is your post
#35541 (comment)
consist of enough information that is enough to provide to the hosting provider?

—Reply to this email directly, view it on GitHub, or unsubscribe.Triage notifications on the go with GitHub Mobile for iOS or Android.
You are receiving this because you were mentioned.Message ID: @.***>

@nikosdion ok, thank you. I have request_order set to empty and variables_order set to EGPCS. So a ticket to hosting support was created.

I have the same problem on 2 website multilanguage. Only works when Seo is diasbled