New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Fix for #6904 --> Fixed the check on published content languages. #7130
Conversation
Please see #6904 Evoking @infograf768... 😄 |
This is probably OK and in any case it will do no harm...
Utterly strange: smz@327cbfa passed Travis but it had mismatched parenthesis... 😕 |
|
||
// The user language has been deleted/disabled or the related content language does not exist/has been unpublished | ||
// or the related home page does not exist/has been unpublished | ||
if (!array_key_exists($lang_code, MultilangstatusHelper::getSitelangs()) |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
@infograf768 is there a need to keep this line or is it OK to be removed?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I've think over this for quite a long time as I'm currently reviewing the whole language filter and in the future I'll probably propose a code clean-up (but this is another story...):
Yes, I think this is a correct check as it could be the case that a language is installed and published, but the site admin had unpublished the home menu for it. This is probably a malpractice but I think there maybe be scenarios where this can be legit.
Only thing is that maybe we can perform this check beforehand, in the construct, where we set up $this->lang_codes and $this->sefs...
I have to think over that anyway, so I think it is correct to check that here, at least for the time being..
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Oh, c*ap!
I was talking about: !array_key_exists($lang_code, MultilangstatusHelper::getHomepages())
... while you probably were talking about !array_key_exists($lang_code, MultilangstatusHelper::getSitelangs())
sorry...
Good find! $this->lang_codes is much better then checking again the db.
|
Hi, Jean Marie!
true: my concern was not to negate a possibly already performed check of the browser language. We'll probably need to introduce a new temp variable... I'll look into that. Concerning
Isn't this being a bit overprotective? Wouldn't that be possible only if a site admin had deleted that folder? And in case this is really needed/advisable, wouldn't it be better to perform that test beforehand in Thanks! |
JM, to be honest I think using $this->current_lang in case there is a problem with the user lang is correct: We set up $this->current_lang in Here, in onUserLogin(), we've surely been through that and if we set here $lang_code to $this->default_lang we negate the benefit of browser detection already performed by parseRule. |
per @infograf768 request, added check: !JFolder::exists(JPATH_SITE . '/language/' . $lang_code)
another possible scenario (without browser detection involved):
|
btw, if someone else is interested in the code review of the language filter I'm working on (I already submitted that to JM...), it is visible @ https://github.com/smz/joomla-cms/tree/LanguageFilter and of course I accept advices/criticism/PRs I don't think it is ready yet to be proposed as a PR here. Who knows, maybe for 3.5... 😄 |
You are right. We can take off that check. But I insist on using
as this corresponds to an admin parameter: let or not the frontend user choose his/her default site language or, when letting the choice, user choosing the default language Changing this behavior would not be B/C. As for browser detection, it is separated from user login. |
JM, I obeyed to your request, but, respectfully, I'm still unconvinced: Assuming that:
This will be the behavior:
I sincerely think my version is more respectful of user's wishes and if this is not what the behavior used to be, well, from my point of view I think we are fixing a bug, not breaking B/C. Not allowing users to select language in their profile, should not mean to force the default language down their throat... |
Please do not delete the comment:
|
Fixed! |
+ some minor optimizations
You can take off @smz Something that must not be forgotten: if someone wants the current language to always be loaded when logging, then it is just a matter of setting "Automatic Language Change" to No.... |
@infograf768
Exactly! In that block of code we are only dealing with the case when "Automatic Language Change" is permitted, and that's why (unless there is a technical reason I'm missing) I'm against your interpretation that the default behavior should be using the default language. In my opinion the default behavior should be "do nothing" and hence use BTW, but this another story, I find that the string describing the "Automatic Language Change" option is misleading. It says:
IMHO it should say something like:
... or something similar... |
|
The code, as it is, implements @infograf768's and your interpretation. Apparently there is a majority (of very much esteemed joomlers) that thinks this is the way it has to be and thus I'll accept the fact that my interpretation is somehow illogical. Point taken and no problems for me. ... but you can't convince me! 😄 Once again and for the last time: There is a very nice Japanese site about, let's say Manga, to which I want to participate. Unhappily I can't read nor write Japanese, but, luckily for me, the site is also available in Italian. The site administrator has even been so kind to allow registered users to set-up their preferred language. Nice! I go to that site and in order to register I switch the site language to Italian (otherwise I can't understand a word... not even where the login fields are). Wow, now I can read! I register and then I log in with the intent to then modify my profile and set up Italian as my default. WTF... I can't read anything again.... Ufffff.... back to the language switcher in order to set-up my preferred language... 😕 Ah... and then why if my preferred language (Italian) is deleted and I then switch to French (which I can understand), I log in and I'm kept in French? |
@smz : concerning your example with the Japanese/Italian site.
Note, concerning the tip:
This is also true. To test, just login and then change in your profile the default site language: you will be redirected on save to the said language. I agree the tip could be more explanatory, but I am afraid some people will not like it as they always insist that a tip is not a doc... As it is, this PR is now OK for me. @roland-d rtc for me. |
PR works as intended. This comment was created with the J!Tracker Application at issues.joomla.org/joomla-cms/7130. |
RTC Thanks 😄 This comment was created with the J!Tracker Application at issues.joomla.org/joomla-cms/7130. |
As this is just a code simplification, I guess it can go in 3.4.2 |
Merged with 28c4327 |
Thanks to all! |
Fixees joomla#7130. References joomla#6904
There is no need to go to the database: we already have $this->lang_codes setup to perform this check...
This also remove the newly introduced
protected $db = null
, so that we do not create B/C legacy.