Steps to reproduce:
- Create a text field which is similar to the standard Drupal body field (e.g., configured as "text area with summary" such that the JavaScript "Edit summary" link appears next to the field title on the node form) but create it as an independent field with a different name.
- Use a Zen-based theme on the content creation page.
- Go to the node form. The "Edit summary" link will not be present for the above field - instead, the body and summary will display separately one above the other.
This is due to code in zen_form_node_form_alter() which swaps out the classes that the Text module's JavaScript uses to add the "Edit summary" functionality.
Credit should go to mndonx for discovering the root cause.
I have a patch which fixes the problem by simply not swapping out the field type class in the particular case of a textarea with summary. It's not an ideal fix; however, considering that this is already exactly what happens for the standard Drupal body field (that field does not have its name begin with "field_" so none of the code in zen_form_node_form_alter() ever ran for it anyway) it seems reasonable to fix it by making other fields consistent. The Body field is used much more often in practice than a second "body-like" field, so if no one ever complained about the field type classes being inconsistent for the Body field they aren't too likely to complain about it here either.
Comment | File | Size | Author |
---|---|---|---|
#1 | zen-textarea-with-summary-1983516-1.patch | 989 bytes | David_Rothstein |
Comments
Comment #1
David_Rothstein CreditAttribution: David_Rothstein commentedHere is the patch.
Comment #2
David_Rothstein CreditAttribution: David_Rothstein commentedActually, on further thought, one could make an argument that this is really a core bug (why does the core JavaScript rely on the field type class rather than a widget class?). And for what it's worth, the patch at #822128: "Textarea + summary" widget broken when field allows multiple values (followup) and associated JavaScript uses fragile selectors seems to fix this too.
But it still might make sense as a patch for Zen in the interim.
Comment #3
JohnAlbinIndeed. That is poor design on core's part.
But I went ahead and applied the patch anyway. Thanks! http://drupalcode.org/project/zen.git/commitdiff/6737612