Problem/Motivation
- Enable Language module
- Go to Configuration > Regional and Language > Languages and add a second language
- Go to the Detection and selection tab and disable URL detection and instead enable Session detection
- Enable the language switcher block on Structure > Block layout
- Go to the frontpage
- Click the language switch link for the second language in the list
- Click on the Home menu link. There should be no query parameter in the URL at this point
- Check the link to the second language in the language switcher link
Expected result:
Because you are already in that language the URL should be http://example.com
Actual result:
The link is actually http://example.com?language=[first]
where [first]
is the language code of the first language in the list. And sure enough, if you click on the second language, the language will switch back to first. (This is only actually visible if you also enable Interface Translation module, but you can check the value in the {sessions}
table in the DB.)
What happens is that LanguageNegotiationSession::getLanguageSwitchLinks()
adds the same $url
object to multiple links. When those links are rendered, options are set on the $url
object, but because it is the same object, they are in fact set for all links. Thus they "stick" for all links, unless they are explicitly overridden to a different value.
Proposed resolution
1. We need tests exposing the current bug.
2. LanguageNegotiationSession::getLanguageSwitchLinks()
should clone
the $url
object before placing it into the links structure. We should also add a comment why we need to clone.
3. We should consider adapting LanguageNegotiationUrl::getLanguageSwitchLinks()
in the same way. I don't think it's possible to actually trigger a functional bug in this case, but the reasoning is the same. We are actually rendering the same URL object multiple times, when conceptually we want to render different URL objects.
Remaining tasks
User interface changes
API changes
Beta phase evaluation
Issue category | Bug because the language switcher switches the language to the wrong one in some circumstances |
---|---|
Issue priority | Normal because the default configuration is unaffected by this |
Prioritized changes | Prioritized because it is a bugfix. |
Disruption | No disruption |
Comment | File | Size | Author |
---|---|---|---|
#13 | session_language_switch_links-2505263-13.patch | 4.84 KB | maxocub |
#13 | interdiff.txt | 788 bytes | maxocub |
#7 | session_language_switch_links-2505263-6.patch | 4.84 KB | maxocub |
Comments
Comment #1
Gábor HojtsyYou don't seem to be working on this and neither anyone else, so removing from sprint.
Comment #2
maxocub CreditAttribution: maxocub commentedComment #3
maxocub CreditAttribution: maxocub commentedHere's a first patch.
Comment #7
maxocub CreditAttribution: maxocub commentedComment #13
maxocub CreditAttribution: maxocub commentedComment #15
maxocub CreditAttribution: maxocub commentedApparently I just needed to use TRUE & FALSE instead of '1' & '0' to change the language detection settings.
Comment #17
maxocub CreditAttribution: maxocub commentedComment #18
tstoecklerWow, impressive detective work @maxocub! I followed all the patches and had absolutely no clue why they were failing. Nice find! The latest patch looks great and includes exactly the "Steps to reproduce" from the issue summary as an automated test. Beautiful.
One minor note:
Just as a future reference: In new code we try to use the new
$edit = [...];
PHP 5.4 array syntax in core.It would be silly IMHO, though, to hold up the commit on that.
Comment #19
tstoecklerAdded beta evaluation.
Comment #20
plach@maxocub:
Great work, thanks!
Comment #21
webchickWow, nice find, fix, and tests!
Committed and pushed to 8.0.x. Thanks!
I don't know that we ever got 100% agreement on enforcing short array syntax everywhere (though I agree it's common) so we can maybe file a follow-up "Novice" patch to clean that up.
Comment #23
Gábor HojtsyYay, great work! Thanks!
Comment #24
YesCT CreditAttribution: YesCT commentedlooking at this for background on another issue, and noticed some nits.
issue for them: #2581817: Follow-up for #2505263: clean up comments
Comment #25
maxocub CreditAttribution: maxocub commented@YesCT: noted!
Comment #26
maxocub CreditAttribution: maxocub commentedComment #29
maxocub CreditAttribution: maxocub commentedComment #30
maxocub CreditAttribution: maxocub as a volunteer and commented