WordPress.org

Make WordPress Core

Opened 20 months ago

Closed 7 weeks ago

#34084 closed enhancement (maybelater)

Automatically log user in after installation

Reported by: johnbillion Owned by: johnbillion
Milestone: Priority: normal
Severity: normal Version:
Component: Upgrade/Install Keywords: has-ux-feedback needs-testing needs-patch
Focuses: Cc:

Description

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?

Attachments (1)

34084.patch (2.4 KB) - added by johnbillion 9 months ago.

Download all attachments as: .zip

Change History (14)

#1 @tyxla
20 months ago

+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.

#2 @swissspidy
20 months ago

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.

#3 @johnbillion
9 months ago

  • Keywords 2nd-opinion removed
  • Milestone changed from Awaiting Review to 4.7

@johnbillion
9 months ago

#4 @johnbillion
9 months ago

  • Keywords has-patch ux-feedback needs-testing added
  • Owner set to johnbillion
  • Status changed from new to assigned

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.

#5 @curdin
9 months ago

@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

#6 @karmatosed
9 months ago

  • Keywords has-ux-feedback added; ux-feedback removed

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

#7 @jorbin
8 months ago

  • Keywords commit added

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

#8 @johnbillion
8 months ago

  • Resolution set to fixed
  • Status changed from assigned to closed

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

This ticket was mentioned in Slack in #core by johnbillion. View the logs.


6 months ago

#10 @johnbillion
2 months ago

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

#11 @johnbillion
2 months ago

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.

#12 @SergeyBiryukov
2 months ago

  • Keywords needs-patch added; has-patch commit removed
  • Milestone changed from 4.7 to Future Release
  • Resolution fixed deleted
  • Status changed from closed to reopened

#13 @johnbillion
7 weeks ago

  • Milestone Future Release deleted
  • Resolution set to maybelater
  • Status changed from reopened to closed
Note: See TracTickets for help on using tickets.