Closed (duplicate)
Project:
Drupal core
Version:
7.x-dev
Component:
user.module
Priority:
Normal
Category:
Bug report
Assigned:
Unassigned
Issue tags:
Reporter:
Created:
23 Sep 2009 at 16:57 UTC
Updated:
4 Oct 2009 at 14:02 UTC
Jump to comment: Most recent file
Comments
Comment #1
damien tournoud commentedA first stab at this.
Comment #3
damien tournoud commentedTiny parse error in the previous patch ;)
Comment #4
dave reidAwesome.
Comment #6
dave reidAwesomely...failed. :)
Comment #7
damien tournoud commentedThis one should already be a little bit better.
Comment #9
sunThis part we should really discuss in #118345: Revamp hook_user_form/_register/_validate/_submit/_insert/_update first.
The entire validation here makes no sense, and as outlined over there, the purpose of this function should be to not store or to remove any value in {users}.data in case there are no user customizable blocks on the user form.
Can we please rename these functions to
user_account_form()
user_account_form_validate()
Or, if you don't like "form" for whatever reason (I like it), then at least "elements", but not "fields", because "fields" means something completely different now. ;)
Especially the order of terms in those function names looks strange to me... user-form-account-fields -- normally, we put "form" last...
uhm, maybe we can skip the entire naming question and just use a single user_form_alter()!
This additionally needs the $register condition.
oh, thanks for those! :) I also discovered that pre-FAPI stuff in #588550: Allow the user edit form to only ask for the current password when necessary (in a followup confirmation step)...
This review is powered by Dreditor.
Comment #10
sunTagging.
Comment #11
sunLet's continue over in #118345: Revamp hook_user_form/_register/_validate/_submit/_insert/_update -- as outlined/questioned above, we need to account for the bigger picture.