| Project: | Drupal core |
| Component: | user.module |
| Category: | bug report |
| Priority: | normal |
| Assigned: | Unassigned |
| Status: | closed (fixed) |
Issue Summary
User.module manually creates several form fields (on lines 1091 and 1664) rather than calling the form_ functions in common.inc. The fields on line 1664 are lacking a class attribute and all are missing id attributes, making their appearances difficult to control. It strikes me as better if the form_ functions were used, but I don't know enough about user.module to know if this is possible. At least the class and id info should be added manually.
Relevant code:
Line 1091$group .= form_item(t('Password'), '<input type="password" class="form-password" name="edit[pass1]" size="12" maxlength="24" /> <input type="password" class="form-password" name="edit[pass2]" size="12" maxlength="24" />', t('Enter your new password twice if you want to change your current password, or leave it blank if you are happy with your current password.'), NULL, TRUE);
Line 1664$rows[] = array('<input type="text" size="32" maxlength="64" name="edit[name]" />', '<input type="submit" name="op" value="'. t('Add role') .'" />');
Comments
#1
This patch should take care of that. I was unable to get someone to review it, so it may have a rough spot.
Robin
#2
IMO, the usability of the forms degrades with this patch. It makes them look weird-ish.
#3
We can use container-inline to put the two password boxes on one row, no?
#4
That's a good thought, I'll try to make a patch with inline.
Robin
#5
Here is a much better way to approach confirm fields, via a new field type
form_password_confirm().I've tested this, and it works. It doesn't fix the second set of hard coded forms, I'll address them in a seporate patch.
Robin
#6
and for the second issue...
#7
I like this approach, it removes hardcoded html form core modules. +1
#8
#9