Manual path aliases are not the same as aliases on the node form

I'm pretty sure the current behavior is by design, so I guess we need to fix URL alias handling. Assigning to Gabor to get some direction.

I think the current behavior in terms of node language is by design. While users may need to review their nodes when they go multilingual, the 80% use case is you are usually creating content in the site default language and not in unknown. In fact with the current situation, its much more likely that you don't need to modify existing content when going multilingual, or only need to modify little as opposed to most with the Drupal 7 behavior. To filter down to nodes created before going multilingual you can also use a date filter, which is much more accurate compared to filtering by language, which would include nodes created after the change.

@quicksketch: as for criticality as per https://www.drupal.org/core/issue-priority data-loss bugs are critical, but here there is too much data rather than loosing data. Retitled for the actual bug vs. what made the bug happen.

BTW while that would not solve the problem per say, I would argue that the manual UI should allow for specifying language for the alias, it is supposed to be a fully capable UI to edit aliases.

What is the expected behavior if you create a language neutral alias for a path that has a language specific alias. I would think that the language specific always would win, and only function as a fallback.

However, if we want the default language to be applied to new content, this behavior should probably be applied to Taxonomy terms and nodes created via the API (right now it's the node form specifically that sets this behavior). [....] All entities that support language should default to the current site default language, not undefined, at the API level rather than in just the node form.

These were supposed to be resolved by #1966436: Default *content* entity languages are not set for entities created with the API last year. If that is not how it works then test coverage added there was insufficient(?). BTW that issue also showcases how intentional the behavior is. There are 252 comments over a year and a half on there.

URL aliases (at least for entities) should also always default to the current site default language. So that when editing an entity the latest alias is always shown in the entity form, creating consistency between the URL used and the alias in the form.

The alias widget in general should load/save the alias in the language of the (node) form. That would allow to load/save/edit aliases for translations also transparently.

I agree the admin/config/search/path form should default to the site default language for path aliases when a language selector is not present, same as entities. Its sad that path aliases are this non-entity non-config things, we need to reimplement behaviors for them that apply to everything else. :/

Unfortunately nobody is working on this, so removing from sprint.

Marked #2511968: Path field should fall back to language neutral aliases (also makes this happen for the form widget!) as duplicate.

The patch implements

Make it so that all aliases created on a single-language site use the default language instead of LanguageInterface::LANGCODE_NOT_SPECIFIED.

, looks good. For multilingual sites, path alias UI has a language selector and defaulting to site default there also makes sense.

Does need tests.

@catch: not sure it is an upgrade path issue on a multilingual site at least. On a monolingual site, we can update all existing path aliases (need an update function for that), but on multilingual sites, we cannot really be sure if a path was explicitly set to no language or implicitly.

Attached you'll find a test only and a test + patch from #15

Ran this manually and this looks good:

Just wondering if the language might not be set to English for another reason? Maybe we could do the test with another default language as well, just to be sure?

Yeah this at least proves we are setting a language now :) Another test (few more lines AFAIS) with another language would be nice.

Hmm is #24 actually still testing what is in the IS? It adds a new language so is this still a single-language site? :/

I think this looks fine. It fixes the situation described in the issue summary as well as adding more tests.

#13/#17 talk about an upgrade path, but I don't see one here. Do we need it or?

Yeah as I said we can do an upgrade path for und => en on sites without language module. On sites with language module, we don't really know the language of the paths, they may or may not be for the current default language and they or may not be intentionally und.

+++ b/core/modules/path/path.install
@@ -0,0 +1,17 @@
+      ->fields(array('langcode' => \Drupal::service('language.default')->get()->getId()))

To be very safe, I would only update aliases where the langcode was und. If the site had multiple languages before and is currently monolingual, then there is no significant data loss at least.

Or check if the unique langcodes is a single language (and optionally und). That is, the site was always monolingual at most, and only do the update then.

Again for such cases when there is data for aliases from a prior state of the site as multilingual.

Also we need tests for upgrade paths :/

Removing from sprint so it reflects what is currently being worked on. Unfortunately.

Downgrading this after a discussion with @xjm @effulgentsia @alexpott @plach @swentel @berdir @amateescu

There are two parts to this bug:

1. The language defaults on the path alias admin UI - we decided this is just a normal bug.

2. Those aliases not showing up on the node form, I've re-opened #2511968: Path field should fall back to language neutral aliases (also makes this happen for the form widget!) to be just about that bit.

The patch here addresses #1. We also discussed leaving the upgrade path here, since there's a risk of data-loss from it, and #2 mitigates a bit.

Reroll for 8.1.

Needs tests for the upgrade path. Got something started.

Based on the call that we had, it is my understanding that we will not have an update function, so we also don't need a test for it :)

Instead of fixing the data (only for single-language sites, impossible to do for multilingual), we'd fix the node form in #2511968: Path field should fall back to language neutral aliases (also makes this happen for the form widget!) to support existing aliases with UND.

Just because we change the default here doesn't mean that it is impossible to create such aliases. It is in fact perfectly valid to do so and we have to support that scenario properly.

We might be able to close this as a duplicate of #2511968: Path field should fall back to language neutral aliases (also makes this happen for the form widget!) and #2689459: If you don't want to translate your URL alias, the original URL alias won't work with your translations.

related? #2065977: drupal_lookup_path shows wrong url

So when I select none as the language for the url alias it allows me to use the alias for the translated path. For example /test and /es/test go to the same page when language none is selected. Is there a way to set the path language to none by default?

So when I select none as the language for the url alias it allows me to use the alias for the translated path. For example /test and /es/test go to the same page when language none is selected. Is there a way to set the path language to none by default?

This is my use case as well. Is there a patch for this?

Can we commit the patch without an upgrade path?

I ran into this today as well as I was developing code to prevent content managers from adding multiple aliases for the same system path. I was very confused by the behavior that aliases created on node forms are given the "en" language while aliases created on the alias form are given the "und" language, and have no option to select anything else.

I agree the path forward to fix this is that for monolingual sites, the form for manually adding an alias should behave the same way that the nod form does.

Nobody cares about the stable version.

@gagarine The release managers care. :P

Bugfixes should be filed against the bugfix branch unless fixing them is disruptive. Since this one requires an upgrade path, though, we usually make those changes minor-only, so I'm moving it to 9.1.x. Thanks!

Going by catch's update in #2484411-36: Manual path aliases are not the same as aliases on the node form, I've updated the issue summary to say this issue is now just about fixing the the language defaults on the path alias admin UI. Together with Berdir's comment #2484411-42: Manual path aliases are not the same as aliases on the node form, it sounds like the decision was made that an upgrade path is no longer necessary. There was also mention in other comments (e.g. #11) about defaulting the language selector to use the default language on multilingual sites, which isn't strictly within the scope of the current issue title, but sounds very relevant to me so I've included it in my issue summary update.

The most recent patch still includes the upgrade path, but is also very old - I'd be amazed if it still applies! But in the meantime, #3449408: Use interface language on the add URL alias form contains an mergeable MR which I believe is a solution for this anyway. It's tests need some work, maybe we can bring across updated tests from here to there, or the work from there to here?

@james.williams Looking at patch #39 here there is some useful looking test code usable in the test for #3449408: Use interface language on the add URL alias form

Saving credits from @catch's issue triage comment in #36.