Closed (won't fix)
Project:
Field Group
Version:
7.x-1.x-dev
Component:
Code
Priority:
Normal
Category:
Bug report
Assigned:
Reporter:
Created:
9 Jul 2013 at 07:53 UTC
Updated:
1 Jun 2024 at 14:11 UTC
Jump to comment: Most recent, Most recent file

Comments
Comment #1
maximpodorov commentedThe patch is rerolled for the current module version.
Comment #2
maximpodorov commentedThe patch is rerolled for the current module version.
Comment #4
maximpodorov commentedSwitching to 7.x-1.x since it's the only active branch.
Comment #5
maximpodorov commented#1: field_group-fix-html5-id-2037731-1.patch queued for re-testing.
Comment #6
nils.destoop commentedThe id's have been removed in the default behavior. However, if people preprocess an id on the group (because they really want one). The id will still be shown.
Comment #7
nils.destoop commentedComment #9
rreiss commentedHi.
The current "fix" on the dev version was to completely remove the field group's id attribute, I don't think this is the right decision.
What about upgrading from V1.3 to a newer version? CSS styles may be broken for those who used the IDs.
The Drupal way is to use drupal_html_id to prevent those issues.
I'm attaching my own patch (according to the code from 7.x-1.3).
My patch will only break in the case when someone used the ID selector to style multiple field group with the same ID, instead of using the class attribute. (Really bad practice!)
Please consider to change it before releasing a new version.
Comment #10
pelegr commentedI agree, it does seem a bit odd to me to completely remove
an ID attribute which may currently be in use by thousands
of users who may have behaviors which depend on this ID -
for the sake of html validation.
Perhaps the better option would be to merely
prevent duplicates as the patch above does.
Comment #11
nils.destoop commentedThe id attribute was not removed completely. A setting has been added to allow people entering an id if they want.
However, you are correct. I shall write an update hook so current id's are default stored in the setting. I wil also add your drupal_html_id() call.
Comment #12
nils.destoop commentedAn update hook was written. People that install the latest version will default get the old ids. They can remove them again in the UI.
Comment #16
nils.destoop commentedComment #17
maximpodorov commentedStupid robot.
Comment #18
milovan commentedI beleive this issue made a problem with fieldset. On a configuration of fieldset group, on Manage fields page , there isn't a text field to enter an id.
Also, on node edit / add, there isn't any id shown in fieldset. In 1.3, there was an id attribute for fieldset. In this issue you added an update hook (7007) to migrate ids to the new id configuration. While it might work fot html, this doesn't work for fieldsets and its ids, as it didn't migrate them, which results in code not rendering ids for fieldsets in configuration, node add and edit, and node view.
Comment #19
nemanja commentedThis doesn't make sense to me because if we put custom ID or leave it as default it will repeat itself everywhere no metter if it's default or not... The only option is to remove ID completely but that may break people's themes so i don't think that this is good solution that you provided.
Comment #20
eldrupalista commentedThis is breaking an important feature of the project I work on. I rely on on the id attribute of the groups for creating an ajax return wrapper. This commit breaks it.
I have to use 7.3 version because of this.
Comment #21
anybodyI can confirm that there is a further problem:
The horizontal-tabs.js relies on the "id" attribute and on form pages (widets configuration) the ID is now completely missing so that the tab to open can no more be addressed by its ID:
So I see two possible solutions:
1. Use something different from the ID to address the anchor in the JavaScript above
2. Allow to set an ID optionally in the WIDGET options (in DISPLAY options this is already possible)
What do you think?
Comment #22
sidharthapHi,
Thanks for the cool module. recently i upgraded from 1.3 to 1.5. My all updates run correctly.(Field_group 7007 and 7008)
My custom code has JS using the id like (user_user_form_group_first_step) but my page shows user-user-form-group-first-step due to which my multi step form not working.
As per the comment https://www.drupal.org/node/2037731#comment-8574291 It should work correctly. I tried removing the id name from filed setting which results no id being displayed on front end and not worked.
As per this https://www.drupal.org/node/2283245 removing "drupal_html_id" from code does the magic. Please add the code back from 1.3 version to maintain the ID in proper format and may be some other solution to track the duplicate.
if (isset($group->format_settings['instance_settings']['id']) && !empty($group->format_settings['instance_settings']['id'])) {
$element['#id'] = $group->format_settings['instance_settings']['id'];
}
else {
$element['#id'] = $form['#entity_type'] . '_' . $form['#bundle'] . '_' . $view_mode . '_' . $group->group_name;
}
Comment #24
nils.destoop commented