Posted by drewish on August 2, 2009 at 6:38am
| Project: | Email Field |
| Version: | 6.x-1.x-dev |
| Component: | User interface |
| Category: | bug report |
| Priority: | normal |
| Assigned: | Unassigned |
| Status: | needs review |
Issue Summary
Putting help text on a single value form works great:
But it gets wonky with multiple values:
Seems like maybe email_textfield_process() should only pass the '#description' down when count($element['#columns']) == 1. I'll look at rolling a patch later.
| Attachment | Size |
|---|---|
| Single value | 7.42 KB |
| Unlimited value | 21.11 KB |
Comments
#1
I agree- this becomes very annoying when you have several lines of description text. However, I was not able to fix it myself in the manner that you described, so a patch would be appreciated. A good example of how this should behave is the standard text field, which only shows one description even for multiple values.
Also, it looks like the pictures in your post got overwritten by something completely unrelated... ? The attachments illustrate the problem though.
#2
I have this too - email behaves differently on even fields that are allowed 2 values, not just "unlimited". Here is a comparison of text field versus email field, both set to exactly 2 instances.
Fortunately, I had this already developed :)
http://dl.getdropbox.com/u/72790/email_field_oddness.png
#3
Is anyone able to roll a patch for this? I wasn't able to figure it out.
#4
Commenting out the description line at 224 removes the duplicated information on instances of the field where multiple values are allowed, but also removes the help text completely on single-only instances. Nightmare! :/
#5
Ok here's a partial fix, but this has to be added in a new/helper module, using form alterations. This appears to work with multiple and single instances of form elements, and leaves the generic description (under the entire form element) untouched. All good! :)
I've left all the "if" code intact as I've cut from my code - that's because I have a fair bit of form alteration code in this module - you may only need a small amount of the code below if you already have similar code in place in such a module.
Note that this code only works for ONE field - a field called "field_email" - if you have multiple email fields or they're named differently, you'll have to update the code accordingly.
function helper_module_form_alter(&$form, $form_state, $form_id) { // change this, obviously!// remove the stupid extra description inserted by email module if it hasn't been fixed
if (strpos($form_id, '_node_form') !== FALSE) { // are we on a node edit form?
if (module_exists('email')) { // is email.module installed?
if ($form['#field_info']['field_email']) { // is the email field element present in this particular node form?
$form['#field_info']['field_email']['widget']['description'] = '';
}
}
}
}
Hope that helps. Only useful in the interim, of course.
#6
Thanks NikLP-good solution for the interim. Surely everyone agrees that this is a bug that should be patched and not worked around with a separate module, right? Where is the maintainer on this? I would take a further look at this myself if there was at least some indication that the maintainer was interested in fixing it or at least reviewing patches...
#7
This is very annoying. Can we please find a work around? It's definitely a bug. Subscribing...
#8
It's bizarre, I've compared this module line-by-line to the phone module (which does NOT repeat help text), and I cannot figure out what's different to account for the repeated text. I'm tempted to put a support request into the phone queue...
#9
Dang, that was an easy fix- don't know how I missed it before: around line 224, change
'#description' => content_filter_xss($field['widget']['description']),to
'#description' => $element['#description'],I don't know if eliminating that content_filter_xss is a security issue or not- I don't think it should be, since an administrator is setting that description, and other modules don't use content_filter_xss here.
#10
patch