In some cases, a redirect is successfully created and some users (in my case) anonymous users can see the node on the alias, but logged-in users get a 404 on the same page.
This happens when there is a mismatch in languages
It looks like https://git.drupalcode.org/project/domain_path/-/commit/1df8666 changed the way the default language was determined.
From:
$this->languageManager->getCurrentLanguage($this->method)->getId();
To
$this->languageManager->getCurrentLanguage(LanguageInterface::TYPE_CONTENT)->getId();
Method is defined at the start of the function (quite why it is used in the object scope I don't know)
$this->method = $config->get('language_method') ? $config->get('language_method') : LanguageInterface::TYPE_CONTENT;
What this means is that if a method other than LanguageInterface::TYPE_CONTENT is used there will be a mismatch between the method used to get the path and the language expected.
Reverting this change seems to resolve the issue.
Make patch and merged
None
None
None
| Comment | File | Size | Author |
|---|---|---|---|
| #6 | 3245281-remove-lang-change-6.patch | 1.01 KB | cameronwelch |
Show commandsStart within a Git clone of the project using the version control instructions.
Or, if you do not have SSH keys set up on git.drupalcode.org:
compare
Comments
Comment #3
shenzhuxi commenteddomain_path was not supposed to determine the $langcode by URL. It should just return the translated entity when matching the domain, content language expectation (D9 translation provided "Content language detection" as a separated option in language "Detection and selection") and path in the record.
So $this->languageManager->getCurrentLanguage($this->method)->getId() was replaced by $this->languageManager->getCurrentLanguage(LanguageInterface::TYPE_CONTENT)->getId(). The language of the interface should not be considered here.
Before the change, if $this->method was set to TYPE_INTERFACE and the logged in user had interface language set already, the interface language would rule out the content language and return incorrect translation or 404.
Drupal core Language module and Translation module should provide the consistent language code when "Content language detection" is not set separately from "Interface text language detection" So $language_manager should provide the correct language negotiation result.
The current situation for the interaction between language, translation and domain related modules is far from bug free. Different domains got different default languages for example https://www.drupal.org/project/domain/issues/3222865. So it's not uncommon that we can't get the content language expectation in the DomainPathAliasManager.
Currently, when the content language negotiation failed, "if ($langcode == NULL)", domain_path just return the first record no matter what's the language, so it can be a little bit more tolerant.
But if the the content language negotiation went wrong, domain_path can't return the right content.
Comment #4
nicholasthompsonI have ended up debugging this in #3362515 and in my case, I have a non-multilingual site.
The content (for whatever reason) is in a mix of "en" and "und"... however due to the NULL check, this line will always try to resolve to what I assume is the current language for the content?
For some reason I've yet to work out, the node in question is set to "und" (as is the domain source and domain path)... however this causes NULL to change to "en". I'm guessing this is because Drupal defaults the site language to "en" rather than "und"?
This causes the domain_path lookup to fail and it falls back to something else making the page access denied.
This is the same behaviour in 8.x-1.2
The patch from @JeremyFrench does not help in my case... in fact, for me, the best fix is to simply remove the line altogether... I assume this is a poor choice for other sites? Although does this mean other sites should fall back to using the alias for the language of the content, rather than the language of the site itself?
Comment #5
nicholasthompsonFor reference, this is my change - however I'm almost certain this is not the right fix for everyone.
Comment #6
cameronwelch commentedthe above caused an issue for me where aliases set to english would no longer be recognised - here's the patch I'm using instead
Comment #7
mably commentedShould be fixed in latest release 2.0.0-alpha1.
Feel free to reopen if necessary;