Closed (fixed)
Project:
Chaos Tool Suite (ctools)
Version:
7.x-1.0-beta1
Component:
Code
Priority:
Normal
Category:
Support request
Assigned:
Unassigned
Reporter:
Created:
20 Oct 2011 at 15:43 UTC
Updated:
26 Apr 2014 at 17:30 UTC
Jump to comment: Most recent, Most recent file
Comments
Comment #1
merlinofchaos commentedThis is probably happening because Drupal records what HTML IDs are on the page and form api guarantees form IDs are unique. When I'm doing stuff in the modal, I often unset...I think it's $_POST['ajax_html_ids'] to ensure this doesn't happen, since modals are pretty insulated from everything else anyway.
This is probably going to be a bigger and bigger problem moving forward. I think this probably just needs to be documented; we shouldn't do it automatically but document that people may need to do it.
Comment #2
thetoast commentedI guess this is the drupal function that's called to give unique ids drupal_html_id($id) and looking at that function you're correct with $_POST['ajax_html_ids']. You can see a quote at the bottom from Ryan Szrama warning about the same behaviour.
But this still doesn't make sense as to why it doesn't rename the id for the user_register_form. To add to Robert's issue summary, the renaming of the id also happens with user_login........what makes user_register_form so special?
Comment #3
rvarkonyi commentedYeah, that's what I don't understand either. Anyway, I'll try and unset $_POST['ajax_html_ids'] and see what happens.
Thanks for the help.
Rob
Comment #4
rvarkonyi commentedYep, done it. Thanks
Comment #5
tim.plunkettI just hit this again in #1675522: Remove button broken if form is rebuilt (via ajax or failed validation).
field_collection has this same pattern (already in CTools and Views) as written by @merlinofchaos, and it solves my problem, and is unlikely to cause additional adverse side-effects.
Comment #6
tim.plunkettPer @dawehner's request, making this opt-in.
Comment #8
japerryReviewed and looks good, per Tim. Committed!