JM, sorry for the delay answering to your call, but I had to set-up my test environment anew: as you may know I'd sweard myself to not contribute to Joomla! any more, but out of respect toward you I felt obliged to respond.

• I've set-up a testing environment (3.4.2-dev from current staging) with three languages: en-GB, fr-FR and it-IT (with the default "sample" article you get when you directly make a multilingual installation)
• I also created three "single article" menu items (one for each of the three languages, associated between themselves) pointing to the sample articles.
• navigated a bit around and...
• unpublished the fr-FR language
• after that, for the /fr/ URLs I get 404s, which I think is expected
• must be noted that an URL of the form http:/mysite/fr/... is translated to an URL of the form http:/mysite/en/fr/... or http:/mysite/it/fr/..., depending on the language cookie, but the same happens for e.g. /de/ URLs (de having never been installed...): unpublished language codes are simply not recognized and thus handled as a generic string.

All of the above is without your PR enabled: I will then install the patch and see what will change: stay tuned!

Off topic, but I don't know what to do with this issues as I've been out of Joomla for a while and thus don't know if they are already somehow addressed:

• Post installation messages cannot be hidden
• Default language is called English (UK) but the language code is en-GB
• A "New Menu Item" is not open in the "Detail" tab (where you should be in order to define the item type), if previously you have edited another menu item in a different tab
• Italian sample article is titled "Collega Articolo (it-it)" while it should simply be "Articolo (it-it)"
• Anomalous language switcher in 404 page (<li> not styled)

P.S.: I notice my old #5416 has not been merged yet... Any reason why?

JM, after having installed this PR I get the following errors when going to my (only) menu item beside the home page:

Notice: Undefined index: fr-FR in D:\UniServerZ\vhosts\dev\plugins\system\languagefilter\languagefilter.php on line 684

Notice: Trying to get property of non-object in D:\UniServerZ\vhosts\dev\plugins\system\languagefilter\languagefilter.php on line 705

Fore reference, my environment is:

PHP Built On    Windows NT SMZ 6.3 build 9200 (Windows 8.1 Business Edition) i586
Database Version    5.6.23
Database Collation  utf8_general_ci
PHP Version     5.4.39
Web Server  Apache
WebServer to PHP Interface  apache2handler
Joomla! Version     Joomla! 3.4.2-dev Development [ Ember ] 21-March-2015 20:30 GMT
Joomla! Platform Version    Joomla Platform 13.1.0 Stable [ Curiosity ] 24-Apr-2013 00:00 GMT
User Agent  Mozilla/5.0 (Windows NT 6.3; WOW64; rv:37.0) Gecko/20100101 Firefox/37.0

... but the very curious thing is that after reverting this PR (Installed through com_patchtester), I now get:

Notice: Undefined index: fr-FR in D:\UniServerZ\vhosts\dev\plugins\system\languagefilter\languagefilter.php on line 671

Notice: Trying to get property of non-object in D:\UniServerZ\vhosts\dev\plugins\system\languagefilter\languagefilter.php on line 692

... which I wasn't getting beforehand...

The point is not to check if a formerly existing url for a deleted language/content language does work as it may not.

It is to make sure that the switcher will not propose the language when browsing the site and that a site language disabled in the manager (or worse) will prevent using it as content language.

It is also to redirect the user —with a defined no-more-published-default-site-language or other missing aspects of that language in multilang— to the global site default language when logging.

Hi, JM!

The point is not to check if a formerly existing url for a deleted language/content language does work as it may not.

Of course the formerly existing URL cannot work, and according to my limited tests it "correctly didn't" (i.e.: 404) even without this PR.

It is to make sure that the switcher will not propose the language when browsing the site and that a site language disabled in the manager (or worse) will prevent using it as content language.

The language switcher did not propose the unpublished fr-FR as an available language in the frontend. In the backend, instead, fr-FR is available for content/menus/modules creation/editing, This happens both with and without this PR.

I will later try to uninstall fr-FR and see what happens. I'm unsure what should be a correct behavior in this case: should all the fr-FR related items (menus/content/modules) be deleted/unpublished? What about users that have the defunct language set as their default frontend/backend language? Is this a realistic scenario?

It is also to redirect the user —with a defined no-more-published-default-site-language or other missing aspects of that language in multilang— to the global site default language when logging.

As stated above in the frontend a generic 404 is displayed, due to the languagefilter plugin not interpreting the defunct language code anymore and making it part of a generic URL. What can be a better option? Continue to parse the unpublished language code and display the associated URL (in case that it exist) for the default language? A "special 404" stating that the language is not available?

Is there a consistent way to replicate the anomalies (e.g. loops) you're talking of in this PR's description?

OK, one aspect that this PR does fix is the case of a user with the default language for the front set to the defunct language when he logs-in:

• w/o this PR a loop happens and you get a "The page isn't redirecting properly"
• with this PR the user is routed to the default language

OK, one aspect that this PR does fix is the case of a user with the default language for the front set to the defunct language when he logs-in:

Yes, it fixes that part, the rest is just good sense to avoid some possible issues.
It comes in fact to complete:
#6718
as I saw the possible issues there.

Should I test this together with #6718?

They are independent.
#6718 prevents choosing as default user language a language which is not also a Content Language.

It is when dealing with that issue that I discovered it could happen, and therefore added this PR here.

got it!

Maybe we should also amend documenation and state that, although somehow addressed, it is a bad-bad-thing to uninstall/unpublish an existing content language and results may be unpredictable...

@test works here!

I like Sergio’s idea to block uninstall/unpublish a language that has menus, items etc still published ????

2 good test:
Setting RTC in issues.

Concerning blocking uninstalling/disabling a multilang language: I am more in favor of a Warning when trying to do so in the Extensions Manager. We could get a js pop up with that warning asking confirmation.
For another PR I guess.