Enhancements to the login and registration forms

[wpdavis]

I would like to propose a significant overhaul of the registration and login forms for 3.2, which I'd be happy to take on. A few things that I think would be helpful:

Combine registration processes for multisite and single-user into one form on one page.
Allow the registration and login to be templatized — no reason this should be for MS only.
Standardize filters, actions and variables between MS and single-user when at all possible.

A few related tickets:

#17904
#17306
#17085
#16866
#16411
#17630

[wpdavis]

I decided to start off by compiling a complete list of all actions and filters used during the signup and registration processes.

ACTIONS:

• login_enqueue_scripts (S)
• login_head (S)
• login_footer (S)
• lostpassword_post (S)
• retreive_password (S) (Deprecated)
• retrieve_password (S) passes $user_login
• retrieve_password_key (S) passes $user_login, $key
• password_reset (S) passes $user, $new_pass
• register_post (S) passes $sanitized_user_login, $user_email, $errors
• login_init (S)
• login_form_$action (S)
• lost_password (S)
• lostpassword_form (S)
• register_form (S)
• login_form (S)
• signup_header (MS)
• before_signup_form (MS)
• signup_blogform (MS)
• signup_extra_fields (MS) passes $errors
• signup_hidden_fields (MS)
• signup_finished (MS)
• preprocess_signup_form (MS)
• after_signup_form (MS)
• wpmu_activate_user (MS) passes $user_id, $password, $meta
• wpmu_activate_blog (MS) passes $blog_id, $user_id, $password, $signup->title, $meta
• wpmu_new_user (MS) passes $user_id

FILTERS:

• login_message (S) passes $message
• login_errors (S) passes $errors
• login_messages (S) passes $messages
• allow_password_reset (S) passes true, $user_data->ID
• retrieve_password_title (S) passes $title
• retrieve_password_message (S) passes $message, $key
• user_registration_email (S) passes $user_email
• registration_errors (S) passes $errors, $sanitized_user_login, $user_email
• lostpassword_redirect (S) passes $redirect_to
• wp_signup_location (S) passes wp-signup location
• registration_redirect (S) passes $redirect_to
• login_redirect (s) passes $redirect_to
• signup_another_blog_init (MS) passes array of blogname, blog_title and errors
• signup_create_blog_meta (MS) passes array of lang_id and public
• add_signup_meta (MS) passes $meta
• signup_user_init (MS) passes array of user_name, user_email and errors
• signup_blog_init (MS) passes array of user_name, user_email, blogname, blog_title and errors
• wpmu_active_signup (MS) passes $active_signup
• wpmu_validate_user_signup (MS) passes $result
• subdirectory_reserved_names (MS) passes array of banned names
• newblogname (MS) passes $blogname
• wpmu_validate_blog_signup (MS) passes $result
• wpmu_signup_user_notification_email (MS) passes email text, $user, $user_email, $key, $meta
• wpmu_signup_user_notification_subject (MS) passes subject text, $user, $user_email, $key, $meta
• wpmu_signup_user_notification (MS) passes $user, $user_email, $key, $meta

[wpdavis]

My primary goal is to standardize the signup process between single-site and MS. A few things to consider:

The registration process for MS and single-site are different. In MS, you must activate your email address, in single-site you don't have to. I propose getting rid of the activation email and instead activating the user on first login. Also, I think the default text for the registration email can be finessed a bit and standardized across MS and single-site — right now on single-site it doesn't say anything.

I think the username restrictions should be standardized across both as well. More lenient by default seems better. Maybe a filter (on both) to allow people to define illegal characters?

The filters and actions between adding fields to MS and single-site registration pages should definitely be standardized. What's going to be harder is standardizing the filters and actions when validating and inserting a signup, because MS stores those signups in a different table until they're validated.

Q: Is that really necessary? Can we put all signups in the user table and purge unactivated ones on a semiregular basis? Seems like a lot of extra steps to have two tables devoted to this. And it would go a long way to standardizing that process.

[wpdavis]

Templatized login screen in TwentyTen

[wpdavis]

Templatized login screen in TwentyEleven

[wpdavis]

I'm working through some of these changes. Attached are how the templatized login page would look in TwentyTen and TwentyEleven by default.

[SergeyBiryukov]

Related: #18225

[johnbillion]

Replying to wpdavis:

I'm working through some of these changes. Attached are how the templatized login page would look in TwentyTen and TwentyEleven by default.

Out of interest (and I know you're still working on it, but...) will your proposed changes templatize the login screen by default? Will it be optional via filter?

I ask because as nice as a templatized login screen is, there are plenty of scenarios when I won't want the login screen templatized.

[wpdavis]

John,
What sort of scenarios are you thinking of?

[SergeyBiryukov]

Related: #18550

[SergeyBiryukov]

Related: #15384

[jane]

I dunno... I can think of a few scenarios where dropping the login box into a main content area would not look very good. It also kind of looks like you got logged out of your site while reading it. Might rather leave the templating for a plugin?

If this moves forward, I'm happy to write new email text, but it should probably be on a separate ticket (one per issue so we can close them independently).

[wpdavis]

@Jane Can I recommend, then, a plugin to return the old login screen? If the login and registration screens are fully templatized then it's a simple matter to style it any way you'd like, including how it previously was styled, but right now everyone's hands are tied to do anything. The login and registration screens need significant work anyway, so this seems like an apt time to go all-out.

[jane]

At this point, it's missed 3.3, so if you want to work on a plugin you won't be tied to a release schedule, and could request any necessary hooks in 3.4.

[SergeyBiryukov]

Duplicates: #18278, #20823

[johnbillion]

#23197 was marked as a duplicate.

[DrewAPicture]

#21662 was marked as a duplicate.

[Ipstenu]

Replying to jane:

I dunno... I can think of a few scenarios where dropping the login box into a main content area would not look very good. It also kind of looks like you got logged out of your site while reading it. Might rather leave the templating for a plugin?

I think that with the advent of the toolbar, it's pretty obvious if you're logged in or not. In fact it would be nicer than now, where if I go to wp-login.php, logged in or not, it always prompts me to log back in. Which is related to #14949 and a different issue.

Making the signup page filterable would help a lot of plugins, including ones that limit how many sites you can create.

[c3mdigital]

#18550 was marked as a duplicate.

[johnbillion]

#12393 was marked as a duplicate.

[SergeyBiryukov]

#27227 was marked as a duplicate.

[SergeyBiryukov]

Related: #20075, #28351, #28352.