Fix horrifying mess of crap in user module hooks

HEAD is broken : http://testing.drupal.org/node/35

core was broken

+++ modules/blog/blog.module	13 Jul 2009 11:47:37 -0000
@@ -44,7 +44,7 @@ function blog_access($op, $node, $accoun
-function blog_user_view(&$edit, &$user, $category) {
+function blog_user_view($user) {

Since we're cleaning things up anyway, let's rename $user to $account in all hook implementations for consistency.

+++ modules/profile/profile.module	13 Jul 2009 11:47:41 -0000
@@ -205,49 +205,49 @@ function profile_block_view($delta = '')
  * Implement hook_user_form().
+++ modules/user/user.api.php	13 Jul 2009 11:47:53 -0000
@@ -263,6 +211,181 @@ function hook_user_categories() {
+function hook_user_register(&$edit, $account, $category) {
+  if (variable_get('configurable_timezones', 1)) {

Out of scope for this issue certainly, but since you had your head this deep into user module, do we still need these hooks? Isn't hook_form_alter() just as good, or no?

+++ modules/system/system.api.php	13 Jul 2009 11:47:45 -0000
@@ -566,19 +566,6 @@ function hook_link_alter(array &$links, 
-function hook_profile_alter(&$account) {
-  foreach ($account->content AS $key => $field) {
-    // do something
-  }
-}

I'm not sure about removing this hook.

This was added back in #74395: hook_profile_alter() - let modules alter the profile page, and $account was passed by reference even in the dark days of Drupal 5. Unfortunately, there's not much there in the way of community discussion around why the change was necessary.

However, the overall pattern of "build up something by querying all modules that want to add primary content, then allow modules to alter the entirety of the primary content" seems pervasive wherever I search for a call to drupal_alter(). So IMO, let's leave it in, with an eye towards removing it in D8 if it really is unnecessary.

Alternately, get Moshe to chime in here and see what he has to say.

+++ modules/user/user.api.php	13 Jul 2009 11:47:53 -0000
@@ -12,79 +12,6 @@
-function hook_user($op, &$edit, &$account, $category = NULL) {

(and 1200 other - lines)

This makes me so happy I could squeal like a little girl. ;)

+++ modules/user/user.api.php	13 Jul 2009 11:47:53 -0000
@@ -251,9 +178,30 @@ function hook_user_operations() {
+function hook_user_after_update(&$edit, $account, $category) {
@@ -263,6 +211,181 @@ function hook_user_categories() {
+function hook_user_logout($account) {
...
+function hook_user_submit(&$edit, $account, $category) {
...
+function hook_user_validate(&$edit, $account, $category) {
...
+function hook_user_view($account) {

Is there any way I can convince you to add examples for these hooks? I'm not confident that if they don't get added now that they ever will be.

+++ modules/user/user.api.php	13 Jul 2009 11:47:53 -0000
@@ -263,6 +211,181 @@ function hook_user_categories() {
+ * The user account is being added.
...
+ * The user account is being changed.

Let's keep past-tense like elsewhere: the user account was just added/changed.

+++ modules/user/user.module	13 Jul 2009 11:47:57 -0000
@@ -23,7 +23,7 @@ define('EMAIL_MAX_LENGTH', 64);
+function user_module_invoke($type, &$array, $user, $category = NULL) {

Can we rename $array as $edit now?

20 days to code freeze. Better review yourself.

Committed to CVS HEAD. Great job, Berdir.

I'm marking this 'code needs work' so we can follow up on the user_edit/user_profile_form/user_edit_form stuff and other tidbits.

Also, let's document this sucker.

very nice work here ... can we please please get rid of the switch on $_POST. Thats pre-fapi code right there.

Lovely. Many thanks.

This is a great little clean-up! :D

+++ modules/user/user.admin.inc	13 Aug 2009 11:26:50 -0000
@@ -6,24 +6,20 @@
+/**
+ * Form builder; Return user administration forms.
+ *
+ * @ingroup forms
+ */

Convention is to @see document the validation/submit functions associated with a form.

+++ modules/user/user.admin.inc	13 Aug 2009 11:26:50 -0000
@@ -6,24 +6,20 @@
+function user_admin(&$form_state) {

While we're at it, can we make this "user_admin_form" to make it more explicit what it is at a glance?

+++ modules/user/user.admin.inc	13 Aug 2009 11:26:50 -0000
@@ -42,6 +38,7 @@ function user_filter_form() {
+  $form['#submit'][] = 'user_filter_form_submit';
@@ -153,6 +147,8 @@ function user_admin_account() {
+  $form['#theme'] = 'user_admin_account';
@@ -171,6 +167,8 @@ function user_admin_account() {
+    '#submit' => array('user_admin_account_submit'),
+    '#validate' => array('user_admin_account_validate'),

Why is this necessary? Doesn't the submit function fire automatically based on naming convention of $form_id?

+++ modules/user/user.admin.inc	13 Aug 2009 11:26:50 -0000
@@ -973,3 +975,77 @@ function user_modules_uninstalled($modul
+function user_multiple_cancel_confirm(&$form_state) {

PHPDoc please.

Also see note about @see.

18 days to code freeze. Better review yourself.

Fixed a recurring spelling error in http://drupal.org/update/modules/6/7#hook-user-changes (unecessary to unnecessary).

Edit: however, I don't have permissions to fix this in http://drupal.org/node/394070. Anyone who does have permissions is welcome to fix it.

@Berdir: Could you take a look at #549726: user_profile_form_validate() not called when submitting user_profile_form ? Maybe related to the recent changes, maybe not, but your work here definitely makes you one of the carbon-based organisms most intimate with the current state of user.module ;-)

This patch would be really nice to still get in. AFAICS, it doesn't break any public API function of User module. But we don't want to waste time in re-rolling if it doesn't have a chance, so please let us know.

I absolutely love the issue title here. Hitting the subscribe button.

Re-rolled against HEAD.

Might this be related to the "horrifying mess of crap" thing?

#892950: (Tests needed) No welcome mail sent to new users after site administrator approval

Possible, but not entirely sure.

Re-rolled against HEAD.

Although badly needed, this is D8 material according to the rules (I had to learn today). It may be backported at a later point in time (though that's unlikely).

Is this still needed?

It looks like most of the legacy code has been cleaned up when the forms were moved into classes already.