Issue with Remove URL Language Code #35541
Comments
|
I am unable to replicate this. Please click on Multilingual Status and check that there are no errors or warnings
|
All is fine there: Well, I can send you credentials to examine the site if you wish. |
|
A bunch of screnshots: Home menu ENG: Home menu RUS: Home menu (all languages): Content languages: System language filter: The screen with the issue: |
|
@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. 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 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. There have never be problems with this at Joomla! 3.x before ... problem is new with Joomla 4.x This comment was created with the J!Tracker Application at issues.joomla.org/tracker/joomla-cms/35541. |
|
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? 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. |
|
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. |
I uncommented |
|
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: PLEASE NOTE !!! Global Configuration / Site / SEO Search Engine Friendly URLs - Yes System - SEF plugin enabled with the following settings: System - Language Filter plugin enabled with the following settings: Language Selection for new Visitors - Browser Settings I use the Joomla default Language Switcher set to: Now for the WORKAROUND FIX: I added the following rule to the .htaccess in the Custom redirects section (before SEF): 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 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 Enable the plugin System - Redirect Go to System Dashboard / Redirects Make a new rule with the following settings: Expired URL New URL Status Clear site and browser cache. All the links redirect flawlessly and language is changed properly. 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: 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! This comment was created with the J!Tracker Application at issues.joomla.org/tracker/joomla-cms/35541. |
|
The problem seems to be solved :-) |
|
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 :-) This comment was created with the J!Tracker Application at issues.joomla.org/tracker/joomla-cms/35541. |
|
The URL with the default language in it should still work even with the remove language code enabled. It does so on 3.x. This comment was created with the J!Tracker Application at issues.joomla.org/tracker/joomla-cms/35541. |
|
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 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 :) This comment was created with the J!Tracker Application at issues.joomla.org/tracker/joomla-cms/35541. |
|
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. |
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 :(. |
|
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 |
|
Hi, I have the same issue since I am using J4. Can someone pls tell me, what to add where in order to solve that? This comment was created with the J!Tracker Application at issues.joomla.org/tracker/joomla-cms/35541. |
|
On a side note:
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
Simply put, a server operator should never , ever add 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 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 |
|
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). 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/). This comment was created with the J!Tracker Application at issues.joomla.org/tracker/joomla-cms/35541. |
|
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 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. |
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. |
|
@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. 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? |
|
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.
Yes.
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.
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!!!
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
At All-Inkl: Create a file
and you'll see. But as far as I see all-inkl doesn't manipulate the option EDIT: But all-inkl sets
which is a fallback setting for
|
|
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 |
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. @ReLater Is your post |
|
you should not buy a self managed vps if you dont have a clue what you are doing. |
What shall I say? Test it for your Joomla installation and we all know better! One can remove the setting and the 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": |
|
@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 |
|
I have the same problem on 2 website multilanguage. Only works when Seo is diasbled This comment was created with the J!Tracker Application at issues.joomla.org/tracker/joomla-cms/35541. |
and others
Steps to reproduce the issue
Install any additional language and create multilingual content.
I've installed Russian and there is English-GB as the default.
Go to plugins > system - language filter and enable its settings and the plugin itself.
Take attention: the param Remove URL Language Code is enabled!
Then create two categories and assign Russian and English to these categories. Create two articles.
Create two additional menus: Top menu RUS and Top menu ENG and there is core Main menu with the default menu item which is set to all languages.
I create single article > select the right article, assign the language and save it as default home page for those language.
Then create two menu modules and language switcher.
All is as it should be.
The problem is when I attempting to switch between languages.
I see that URLs in the language switcher module are incorrect.
https://domain.com/index.php/en/ - this leads to "The requested page can't be found'.
No errors in server error.log and in Joomla error.log
Watch the screencast video showing this issue in action.
https://www.dropbox.com/s/fhmyuh4ik3ap4ht/j4-language.mov?dl=0
BUT! If I disable 'Remove URL Language Code' param in the plugin settings, all works fine.
Joomla 4.0.2
PHP 8.0.3
The text was updated successfully, but these errors were encountered: