The "Hide non translatable fields on translation forms" option, that has been introduced in #2878556: Ensure that changes to untranslatable fields affect only one translation in pending revisions doesn't apply to Url alias field. That produces more issues in case Url Alias field is marked as non-translatable - url alias added in original language doubles every time new translation is added.
Steps to reproduce:
Hide Url alias field if non-translatable
Test
Patch
Review
Url alias field is now hidden from entity translation form in case the field is marked as non-translatable and "Hide non translatable fields on translation forms" is checked.
n/a
n/a
| Comment | File | Size | Author |
|---|---|---|---|
| #7 | 3017157-7-TEST-ONLY.patch | 3.23 KB | zaporylie |
Comments
Comment #2
zaporylieJust tried to hack EntityChangesDetectionTrait::getFieldsToSkipFromTranslationChangesCheck to make sure the
pathfield, even if computed, doesn't fall into the same restrictions as the rest of the computed field. This successfully hides the field from the entity translation form but new URL alias is created anyways (in PathItem::postSave()).Comment #3
matsbla commentedI've checked this and can confirm the bug
Comment #4
berdirthe translatable/untranslatable checkbox doesn't work at all right now. It doesn't matter if it's translatable or not, the alias is *always* per entity language.
See #2689459: If you don't want to translate your URL alias, the original URL alias won't work with your translations. I would close this as a related/duplicate of that and then we'll have to solve that problem there.
The widget might need to hide itself then in that case as the generic code doesn't deal with computed fields.
Comment #5
zaporylieDid some research about the saving part - seems like a new alias. with langcode consistent with translation, is enforced by path_entity_translation_create(). That part can be fixed in #2689459: If you don't want to translate your URL alias, the original URL alias won't work with your translations as of your suggestion, but we still have an issue with widget being displayed even though "Hide non translatable fields on translation forms" is checked - and this is the scope for this issue. It seems like the regression was introduced in #2826021: FieldItemList::equals is sufficient from the storage perspective but not for code checking for changes.
Comment #6
berdirMy point is that right now, showing it is kind of the correct thing to do because the alias really is always translated/per language, no matter which translation setting you have (well, with the fallback, it gets more complicated, as it could be language neutral if it was created as that elsewhere. But that too is consistent no matter how the field is configured).
That does change as soon as we actually respect that setting, then showing it will be a bug. So it would make sense to fix it in the same issue.
Comment #7
zaporylieThank you @Berdir for elaborating on the problem (or the lack of it ). I still believe this is a bug even now and adding a failing test to prove it. The test is basically copied over from PathLanguageTest::testAliasTranslation with the modification - `settings[node][page][fields][path]` is set as untranslatable. I have added following two lines to prove that alias is created in incorrect language:
Still - the fix to that issue should probably land in #2689459: If you don't want to translate your URL alias, the original URL alias won't work with your translations. My point here is that right now showing a Path widget when the field is non-translatable is a bug.
Comment #13
jeroentI'm postponing this issue until #2689459: If you don't want to translate your URL alias, the original URL alias won't work with your translations is fixed.