Closed (fixed)
Project:
Drupal core
Component:
forms system
Priority:
Minor
Category:
Bug report
Assigned:
Reporter:
Created:
14 Nov 2005 at 00:43 UTC
Updated:
16 Jan 2006 at 08:21 UTC
Jump to comment: Most recent file
There is a bug either in profile.module (where it's called from) or form.inc with the "date" type form field. The date entered does not get saved.
To reproduce,
1. create a "date" field in user profile
2. set the date
3. save or just preview.
The date is going to be wrong. The reason is that all form field names for year, month, and day are the same:
<select name="edit[profile_bday]" id="edit-profile_bday"><option ... (for year)
...
<select name="edit[profile_bday]" id="edit-profile_bday"><option ... (for month)
...
<select name="edit[profile_bday]" id="edit-profile_bday"><option ... (for day)
Before the new Forms API they were:
<select name="edit[profile_date][year]" id="edit-profile_date-year"><option ...
...
<select name="edit[profile_date][month]" id="edit-profile_date-month"><option ...
...
<select name="edit[profile_date][day]" id="edit-profile_date-day"><option ...
I couldn't figure this one out and write a patch...
Darius
Comments
Comment #1
darius commentedOK, I figured this out myself, patch attached. The bug was in expand_date function in forms.inc.
Darius
Comment #2
chx commented'#name' => $element['#name']."[$type]" this makes no sense. Maybe you want $element['#tree'] TRUE? just a guess from the patch. If that works, then you can delete #parents and #tree from the [$type] array.
Comment #3
darius commentedYeah, my previous patch was a quick ugly hack (that worked). Thanks for the suggestion, the new patch attached.
Darius
Comment #4
dries commentedchx?
Comment #5
chx commentedIn my test, the patch proved to be unnecessary. On the other hand, using #tree is cleaner, so let's use that.
Comment #6
dries commentedCommitted to HEAD. Thanks.
Comment #7
(not verified) commented