Support for Drupal 7 is ending on 5 January 2025—it’s time to migrate to Drupal 10! Learn about the many benefits of Drupal 10 and find migration tools in our resource center.
This only seemed to happen after I made the jump from RC1 to RC2. Basically, for the node add/edit form, I had a fieldset and a textarea form element inside the fieldset, which was inserted using hook_form_alter(). This caused the textarea for the body to disappear. When I got rid of the inserted textarea or even moved it outside the fieldset, the textarea for the node body reappeared.
Comment | File | Size | Author |
---|---|---|---|
#12 | hidden_body_c.patch | 732 bytes | theborg |
#8 | hidden_body_b.patch | 2.83 KB | theborg |
#6 | hidden_body.patch | 1.87 KB | theborg |
Comments
Comment #1
Mike Wacker CreditAttribution: Mike Wacker commentedActually, it now appears to be an issue with the weights. The body textarea disappeared when I put the extra textarea outside the fieldset and assigned it a weight. But it reappeared when I removed the weight. Putting the other textarea also works inside a fieldset so long as the fieldset does not have a weight. This only happened with textareas as far as I can tell.
Comment #2
beginner CreditAttribution: beginner commentedConfirmed.
To reproduce enable the node_example.module http://api.drupal.org/api/file/developer/examples/node_example.module/6
Edit node_example_form() thus:
Notice the "Example Body" disappearing.
Is this critical?
This would break many module which implement hook_form() or hook_form_alter() on node forms (CCK?)
The temporary fix is not to use any weight... which is a regression in functionality.
Comment #3
catchSounds very similar to this: http://drupal.org/node/193921 but that was fixed :|
Comment #4
Gábor HojtsyDisappears == does not end up in the HTML output OR == does end up in the HTML output, but the JS hides it? This would greatly narrow down to where we should look and it is easy to tell if you reproduced the bug.
Comment #5
theborg CreditAttribution: theborg commentedEnds in the html output hidden because has the same parent as the teaser:
teaser.js is intented to hide only the teaser, not teaser + body.
Textarea wraps the teaser + body with a span that ends hidden.
Edit: Looks like if there is a textarea before the body, this wrap happens before the procesing of the teaser.
Comment #6
theborg CreditAttribution: theborg commentedThis patch moves the teaser with the grip provided by textarea before the body.
Comment #7
theborg CreditAttribution: theborg commentedBroken when textarea is not processed before.
Comment #8
theborg CreditAttribution: theborg commentedInverted form api processing to do the resizable before the teaser.
Comment #9
chx CreditAttribution: chx commentedNow, this is funny, we have specifically patched one to come before the other and now we need to swap? Why?? Will there be an issue next week asking to be swapped back?
Comment #10
catchReproduced, tested with beginner's instructions in #2 on FF2, IE6/7, Opera, Safari3(XP). All good. I'll leave it open for an extra review given the shortness of the criticals queue and this being the second time it's cropped up, but it seems fine.
Comment #11
catchchx, there's been minor changes to the teaser splitter (button/checkbox in a div, stuff like that) which may have broken the earlier fix (not sure which order they got committed in to be honest). I can confirm that the additional textarea doesn't break the split/join behaviour, and fixes the hiding issue. But yes this needs more eyes on it to make sure we don't go 'round in circles.
Comment #12
theborg CreditAttribution: theborg commentedAgree totally with chx and catch.
Much more simple patch, avoid processing teasers that have not passed teaser.js filter.
Comment #13
catchTested in all browsers I have access to and this one also worked cleanly.
Comment #14
Gábor Hojtsytheborg: this latest patch makes a lot of sense. teaser.js already ensures that non-processed textareas are processed near the end of its job, when the the textarea is already marked teaser-processed, so textare.js will run on it well. I committed this latest patch.
Comment #15
Anonymous (not verified) CreditAttribution: Anonymous commentedAutomatically closed -- issue fixed for two weeks with no activity.