I don't know if this is a bug or if it is supposed to do this by design, but for some reason, the cookie is not being set on 404 pages. This means that any links that I have in the actual custom 404 page that may just be "/node/23" for example will go to the last known good language code as opposed to the language code in the URL. This is an issue if for example someone was last at my French site and therefore has a "fr" cookie set, but then let's say they clicked a link in an email that was www.example.com/de/bad-page-that-triggers-404 that technically should be the German site. When they click a link on the 404 page, they get ported to the French site instead of the German site, since "fr" was the last set cookie even though "de" was in the URL. Is there a way around this?

THANKS

Comments

erich93063 created an issue. See original summary.

jeroent’s picture

jeroent
Primary language Dutch
Location 🇧🇪
commented
Status: Active » Postponed (maintainer needs more info)

@erich93063,

The cookie nog being set on 404 pages is by design. One of the conditions is "LanguageCookieConditionPathIsValid" which will check if the current path is a valid, existing page.

About the 404 page redirecting to the FR website, I tried to reproduce on a clean Drupal installation with the following language negotiation setup: URL -> Cookie and I could not reproduce this issue. Is there perhaps another module interfering with language_cookie?

erichhaemmerle’s picture

erichhaemmerle commented

Hi, thanks for getting back to me. So we just decided not to have links on the 404 page since this is still happening. It's not that big of a deal. I do have the language detection setup as URL > Cookie though. I have so many modules installed, who knows if one might be interfering with this. It's been a while since I looked at this, but I did just verify it is still happening. Basically, if a user comes to the site and specifies their language and they get a cookie set for that language, they will get the site in that language from that point on, but if they then were to go to a page that triggers a 404 page in a different language, either by manually typing a different language code in the URL (like what I did to test) or perhaps by clicking a link that now has a different language code in the URL and they go to the 404 page and click on a link which is set to go to "/node/1234", they get ported to their ORIGINAL language code, not the language code that was forced in the URL.

Again, this isn't a big deal as we now don't have links on our 404 page anymore. It actually does makes sense that this is by design though. If a page triggers a 404, it probably shouldn't change the users language to that of the non existent page anyway. I don't know. This was just something that my site owner wanted it to do.

THANKS

jeroent’s picture

jeroent
Primary language Dutch
Location 🇧🇪
commented

@erich93063,

I was thinking about this issue again and since the language cookie conditions are plugins, you could use hook_language_cookie_condition_info_alter to unset the path_is_valid check.:

/**
 * Implements hook_language_cookie_condition_info_alter().
 */
function mymodule_language_cookie_condition_info_alter(array &$definitions) {
  unset($definitions['path_is_valid']);
}

Anyway, created #3142828: Document hooks provided by language_cookie. to document the hooks provided by this module.

jeroent’s picture

jeroent
Primary language Dutch
Location 🇧🇪
commented
Status: Postponed (maintainer needs more info) » Closed (works as designed)