Problem
- Using field_group to group fields used in a Paragraph bundle using horizontal tabs.
- I'm arranging all my Paragraph bundles using a common scheme; eg. 'Group1', 'Group2', 'Group3'.
- The machine name of each set of tabs is therefore the same for multiple Paragraph bundles: eg. group_group1, group_group2 etc.
- The machine name of each group is used to set the containing element ID.
- The current version of field_group uses the ID of each group to target the correct horizontal tab.
- As Multiple Paragraph items can be added to any node, there's a likelihood that multiple tab groups will share the same ID (/machine name).
- In these cases, selecting a tab will activate the first instance of the tab type on the page, leading to a confusing admin experience.
Proposed resolution
- Provide unique ID for each tab group or target with reference to the tab that's firing the click event.
| Comment | File | Size | Author |
|---|---|---|---|
| #18 | unique_id_for_tab_elements-2941010-18.patch | 4.42 KB | lukus |
| #12 | unique_id_for_tab_elements-2941010-12.patch | 706 bytes | lukus |
| #6 | unique_id_for_tab_elements-2941010-#6.patch | 706 bytes | lukus |
Comments
Comment #2
lukusHappy to contribute a fix, but would like to know whether this problem is known (and / or what the preferred resolution would be).
Comment #3
scottsawyerI just noticed this on a site I am currently building. In my case, I have paragraphs which have field groups ( tabs in this case ) that contain settings for things like background color or text color.
Paragraph 1 - tab = Background Color
Paragraph 2 - tab = Background Color
If you are editing Paragraph 2, and click the tab "Background Color", the tab in Paragraph 1 is triggered. Both tabs seem to behave otherwise, but what commonly happens is, when you are editing Paragraph 2, suddenly you are looking at Paragraph 1's Background color. I have set the background color on the wrong paragraph several times before I realized that I wasn't actually going crazy. If it's confusing for me, it will completely confound my ( totally inexperienced ) editors.
I haven't dug into the module's code just yet to see what kind of selectors are used for the triggers, but if it is #id and we're running into some sort of duplicate ID issue, then we definitely need to consider a more robust solution.
My initial thoughts ( without having actually looked at the code yet ), is use some sort of UUID for the ID.
I haven't actually confirmed this quite yet, maybe my issue is different and maybe it has something else to do with the JavaScript.
Comment #4
lukusI agree .. fundamentally, we have a situation where the same ID is being used multiple times in one document. Fixing this is probably the most efficient way of resolving the problem.
I know there was a function that could be called in D7 to ensure that an ID is unique .. will check to see if the same exists for D8.
L
Comment #5
lukushttps://api.drupal.org/api/drupal/core%21lib%21Drupal%21Component%21Util...
Comment #6
lukusPatch attached. Making use of Html:getUniqueId to ensure ID is unique.
Solves issue mentioned above.
Comment #7
lukusComment #8
lukusComment #9
scottsawyergreat job lukus, it seems to be working for me in my brief test.
Comment #10
lukusComment #12
lukusRerolled patch.
Comment #13
lukusComment #15
nils.destoop commentedThis was a duplicate of #2904577: Duplicate CSS ID confuses behat and is now fixed for all type of groups. Lukus, I reverted my commit of 2904577 and recommited + a credit on your name.
Comment #16
lukusHi @zuuperman, thanks for commiting this.
I've encountered what seems like a bug in the current dev release (https://www.drupal.org/project/field_group/issues/2993664)
Bearing this in mind, I'm going to roll a patch against current beta release so I can move ahead with current project I'm working on.
Comment #17
lukusComment #18
lukusComment #20
lukusThis issue is still occuring for me.