Problem/Motivation
If you use field groups in node edit form and use "Details Sidebar" group then group is not visible on node translation page. Also the fields under that group are gone.


Steps to reproduce
- https://simplytest.me/
- Start with Field Group 3.1
- Add new field group to Article at /structure/types/manage/article/form-display
- Choose "Details Sidebar"
- Save and add some fields under the new group
- Create new node and test that it works
- Install "Language" and "Content Translation" modules
- Add some new language to site /admin/config/regional/language
- Enable translations on Article /admin/structure/types/manage/article
- Add new role eg Editor /admin/people/roles
- Add permissions to new role /admin/people/permissions:
- Create translations
- Translate Article content item
- Article: Create new content
- View the administration theme
- Add new user /admin/people and add Editor role
- Log in with the new user and create node (check that the group exists)
- Now add new translation /node/2/translations
- That group is not visible and the fields in it are gone. In my case it was title field but it's any field you add under group.
- There are some group types that work: Details, Tab and Tabs. Rest of them behave the same - they are gone.
Simplytest runs on Drupal 8.9.16
Locally I also tested this on dev branch.
Proposed resolution
The group and fields should be visible.
| Comment | File | Size | Author |
|---|---|---|---|
| #16 | interdiff_13-16.txt | 1.41 KB | hkirsman |
| #16 | 3222507-16.patch | 1.54 KB | hkirsman |
| #13 | 3222507-13.patch | 1.3 KB | swentel |
| #2 | manage-form-display.png | 106.94 KB | hkirsman |
| #2 | node-add-translation.png | 55.43 KB | hkirsman |
Comments
Comment #2
hkirsman commentedComment #3
hkirsman commentedComment #4
hkirsman commentedComment #5
hkirsman commentedComment #6
hkirsman commentedComment #7
swentel commentedJust to be sure, is it visible as user 1 ? It is for me here, just want to be able to rule that out.
Comment #8
hkirsman commentedIt is yes.
Comment #9
swentel commentedInteresting, I can reproduce, checking for patch.
Comment #10
swentel commentedThe thing is that I don't even see a sidebar when fieldgroup is disabled too, so core hides/ignores some detail elements if you don't have many permissions when creating a translation, not sure why or what the logic is at the moment. But it isn't necessarily a field group problem at the moment. Will check whether I can still come up with a fix though.
Comment #11
hkirsman commentedThanks for investigating!
By default user can't translate node. You'd need to specifically add permissions like:
- Create translations
- Translate Article content item
Then the button appears. Don't know what else to add.
Comment #12
swentel commentedYes, I've added those permissions. I can access the translate screen, so that's ok.
It's ContentTranslationHandler::entityFormSharedElements that starts hiding elements - based on translation status and permissions. Will be tricky to get around that.
Comment #13
swentel commentedSo it really is a core thing, but I can get around it. Patch isn't completely right though, but it's getting close.
Comment #14
hkirsman commentedSeems to be working already! What's missing?
Comment #15
swentel commentedWell, there should be an extra condition to check if we're on the 'add translation' route. I would also add an another condition which defaults to FALSE to expose this behavior because otherwise it might 'break' a lot of existing sites out there where suddenly the sidebar starts popping up. So something like this:
Comment #16
hkirsman commentedI've added the translation route check plus isset() function to check if $element['advanced']['#access'] exists before checking if it's FALSE. Got warnings in some cases when it did not exist. Tested on my setup and seems to work fine.
Comment #17
hkirsman commentedI also found this issue but don't think it's there anymore https://www.drupal.org/project/drupal/issues/3097407 ? Or actually maybe it is as it's about Claro theme.
Comment #18
swentel commentedOk, looks good to me. I'll leave it to zuuperman to have a second check before committing :)
Comment #20
nils.destoop commentedI tested the patch, and everything seems to be ok. Committed it to dev
Comment #21
vaidas_a commentedGuys, thank you for the patch, it solved the issue when adding a new translation.
Would be great if we have the same behaviour also when editing an existing translation too (route name 'entity.node.content_translation_edit')
Comment #23
swirtHi. I know this issue is closed and outdated. I opened a new one, however I wanted to call this out here so it is in context.
This was very heavy handed and broke code that we needed to run after this form_alter. We had it called out with module dependencies and explicitly setting the weight. This change completely took away our ability to control when our code ran.