Automatically log user in after installation

[johnbillion]

On my core development installs I run a custom wp-content/install.php file which, among other things, logs me in and redirects me to /wp-admin immediately after installing WordPress. It's really nice to be dumped straight into the admin area after hitting the 'Install WordPress' button.

Opening this ticket up for discussion about whether core should do this by default.

What problems could it cause? Will it increase the likelihood of the admin not remembering their password? Will it avoid cause annoyances for users who use password managers because you're skipping the login form? Anything else to consider?

[tyxla]

+1

I'm running something similar on my development installations. I find it convinient to be redirected to /wp-admin as a logged-in administrator right after installation has completed. I don't recall doing anything else but logging in after installation.

[swissspidy]

Will it increase the likelihood of the admin not remembering their password?

That's what I thought at first, but with stronger passwords introduced in 4.3 that's not that big of a problem anymore IMHO.

+1 from me as well.

[johnbillion]

I've been playing around with this behaviour for a few days and I now have a patch.

34084.patch​ does the following:

• Logs the user in and redirects them to the admin area as soon as WordPress is installed.
• Falls back to displaying the existing "Success!" message if headers have been sent (eg. from a malformed wp-config.php, see #36215) which would otherwise result in a white screen of death.
• Correctly populates the fallback value for COOKIEHASH during bootstrap, which is otherwise an empty string during installation (due to lack of a siteurl option). This allows the correct cookie to be set when logging the user in.

What needs testing:

• Password managers: I've been testing with 1Password. If you save your login when prompted to, then your credentials are correctly presented when subsequently visiting the login screen. One thing to note is that the form field names on the installation screen differ from those on the login screen, so some password managers may not deal with this so well. Installation and subsequent login should be tested with other password managers such as LastPass, KeePass, and Dashlane, and built-in browser password managers (Chrome, Firefox, Edge) on desktop and mobile. The intent here is to ensure that password management works equally well as it does now, given that the form fields have different names. I'm 99% sure it'll be ok.
• Welcome screen: The "Welcome to WordPress!" panel on the dashboard is now the first thing people see after installing WordPress. It takes the place of the "Success!" message. Does this panel need further improvement for UX purposes? (If so, it should probably go into a separate ticket.) See also the focus on NUX.

[curdin]

@johnbillion - not directly related but possibly worth including. The conditional that checks each field in wp-admin/install.php has a comment "TODO: poka-yoke" under each condition. It appears to me that poka-yoke was improved as part of #24982 - can these comments be removed?

Also, the patch works fine for Chrome 52 builtin password manager

[karmatosed]

I think it makes sense and avoids friction. I'd +1 and say you have ux-feedback here so will add that as keyword.

[jorbin]

Patch looks good to me. I think we should get this in and have any welcome panel improvements tracked separately. A welcome panel is still a better experience than a login form.

We can call for testing with multiple password managers on make/core

[johnbillion]

In 38619:

Upgrade/Install: Automatically log users in after installation.

This change means that after entering their site's settings upon installation, users are immediately logged in and redirected to the admin dashboard, instead of being presented with the 'Success!' screen and then being asked to log in. This reduces friction and reduces the number of steps for installation.

Fixes #34084

[johnbillion]

In 40320:

Login and Registration: Avoid a potentially incorrect value for the cookie hash on multisite installations that don't have a value in the siteurl network option.

This reverts [38619].

See #34084

Fixes #39497

[johnbillion]

In 40321:

Login and Registration: Avoid a potentially incorrect value for the cookie hash on multisite installations that don't have a value in the siteurl network option.

This reverts [38619].

See #34084, #39497

Merges [40320] to the 4.7 branch.