Language negotiation breaks updating Drupal 9 to 10

This was changed in 🐛 Missing url prefix on language neutral content Fixed

I get why LANGUAGE_NOT_SPECIFIED might need a default language prefix adding, but I do wonder if LANGCODE_NOT_APPLICABLE should have one at all.

LANGCODE_NOT_APPLICABLE should in my mind not have a language prefix: I have language negotation active on my site, but openid_connect that is used for authentication is very "touchy" about the URLs that you can use.

So in Drupal 9 my custom code generated "https://mysite.com/openid_connect/acm-idm" and after upgrading to Drupal 10 that is magically changed to "https://mysite.com/nl/openid_connect/acm-idm", which breaks openid_connect.

Patch that fixes the LANGCODE_NOT_APPLICABLE issue.

@sboden Please do not test on every platform configuration for a small bug fix that is unrelated to database. Test bots have a cost.

The in_array() can be removed now there is only one value to check.

Removed in_array and fixed CC failure in #6. please review

Patch #9 fails: when you remove in_array() the line should be changed to a '=='.

Something as:

if (!isset($options['language']) || ($options['language'] instanceof LanguageInterface && $options['language']->getId() ==
      LanguageInterface::LANGCODE_NOT_SPECIFIED)) {

Per #10 and will need a test case to show the problem.

I now see that there is a valid use case for generating language neutral URLs. Since we don't know the intent in \Drupal\language\Plugin\LanguageNegotiation\LanguageNegotiationUrl::processOutbound at least without adding an API, I'm wondering if the right way to fix this would be to revert 🐛 Missing url prefix on language neutral content Fixed , and fix the original bug in \Drupal\Core\Entity\EntityBase::toUrl and other instances that are generating URLs? It feels strange that \Drupal\Core\Entity\EntityBase::toUrl would have to care about the interface language but at the same time, it seems like that it needs to care about it because that's where we know which behavior we want.

@lauriii What do you think about just dropping the LANGCODE_NOT_APPLICABLE check? The original issue only mentions "language not specified", which to me means we could try to select a default, but "not applicable" means there doesn't need to be a language at all.

I think you're right. We could just drop LANGCODE_NOT_APPLICABLE from there. However, if an entity has LANGCODE_NOT_APPLICABLE we may still want to generate the link with the current language to retain the UI language. I'm fine if we move that to a follow-up to address this first.

Have fixed the tests and now i guess its in a mergeable format.

We've been using this for a couple of months now and it seems to work.

I'm triaging RTBC issues → . I read the IS and the comments. The issue summary is incomplete, particularly there isn't a proposed resolution. I have added the standard template but it should at least have an updated 'proposed resolution'.

#16 mentions moving some work to a follow up. I am not sure if that is still needed but I have added the tag and adding it to the remaining tasks so that gets considered.

Leaving at RTBC.

Opened 📌 Decide what to do with interface language for LANGCODE_NOT_APPLICABLE entities Active as followup. Plus, this already has tests, so removing the tag.

Committed f028872 and pushed to 11.x. Thanks!

Unsure whether this is eligible for backport. One on hand it seems like a serious bug for the URLs that it affects, but on the other hand some sites may already be used to the new buggy behaviour. Will discuss with the other committers.

The follow up was created.

I talked with longwave about this and he suggesting tagging for release notes.

Let's just mark this as fixed in 10.3.0, as there is a minor behaviour change let's not introduce it in a patch release. Anyone who is affected by this can patch, but with only 13 followers it seems this issue is not that widespread a problem.

Automatically closed - issue fixed for 2 weeks with no activity.