#47287 closed defect (bug) (duplicate)
New User Activation Page Links are Misleading
Reported by: | pkarjala | Owned by: | |
---|---|---|---|
Milestone: | Priority: | normal | |
Severity: | normal | Version: | 5.2 |
Component: | Login and Registration | Keywords: | |
Focuses: | multisite | Cc: |
Description (last modified by )
This is related to #39311 but I am filing it as a separate ticket, as that one seems to have gone stale.
This issue is related to how the new user workflow is processed with the user activation emails, and the links provided on the new user activation page in WordPress.
Our site for purposes of this experiment is http://domain.com
which is the main site, and a sub-site located at http://domain.com/test1
. This is an unmodified WordPress 5.1 install, no plugins, default theme, set up as a network install, running on a local virtual machine.
- Create a new user in domain.com/test1/wp-admin/user-new.php
- User receives email with text as follows:
Hi, You've been invited to join 'TEST 1' at http://domain.com/test1 with the role of Subscriber. If you do not want to join this site please ignore this email. This invitation will expire in a few days. Please click the following link to activate your user account: http://domain.com/test1/wp-activate.php?key=somerandomkey
This is fine and is expected behavior.
- User clicks on the link and is redirected to
http://domain.com/test1/wp-activate.php
after the activation key is validated and the user's account is activated. The text on this page reads:
[Test 1] Your account is now active! Username: mynewuser Password: somerandompassword Your account is now activated. [Log in] or go back to the [homepage]. Test1 is proudly powered by [WordPress]
With the following links:
- [Test 1] linking to
http://domain.com/test1/
- [Log in] linking to
http://domain.com/wp-login.php
- [homepage] linking to
http://domain.com/
- [WordPress] linking to
https://wordpress.org/
The problems are the [Log in] and [homepage] links, which I see having a few issues.
- The [Log in] URL may be confusing for users who are expecting to login at
http://domain.com/test1/wp-login.php
. While most users won't care, some do, and we've had enough complaints about this that I'm writing this. Yes, the login will still work from the main sitewp-login.php
page, but the typical end user does not know this, and the "magic" of it "just working" is obtuse. - If specific styling or modifications are applied to
http://domain.com/test1/wp-login.php
through a theme, plugin, or other tool, it will look different than the login page athttp://domain.com/wp-login.php
. Alternatively, if we have styled or modifiedhttp://domain.com/wp-login.php
to look different than the rest of the sub-sites, it will be confusing to the end user. This is a presentational problem that we cannot currently overcome when users click on the [Log in] link as it is currently generated. - We are currently developing content for
http://domain.com/
and have only exposedhttp://domain.com/test1/
to the outside world. Because of this,http://domain.com/
is not available to the end user, so a 404 error is shown when the user tries to click on the [Log in] link tohttp://domain.com/wp-login.php
or the [homepage] link. This is entirely a cause of our current environment, and not a WordPress issue, but I am including it here as a case where the [Log in] link is not terribly useful as it is currently generated if the multisite creator for some reason doesn't want access to the main site. - Users who click on the [homepage] link are confused that they are taken to a different homepage than the link at the top of this section, [Test 1]. It is heavily implied that [homepage] in this case is the homepage of
http://domain.com/test1/
due to the title header of the page itself, [Test 1]. This is confusing for end users, and in our current environment, doesn't work anyway due tohttp://domain.com/
not currently being world available. - The workflow for all sub-sites if a user wants to log into on of those sites is to go directly to the sub-site's login page, in this example,
http://domain.com/test1/wp-login.php
. The user will almost always go through this workflow when they visit the sub-site to log in. Otherwise all sub-sites would just redirect the user to the main site login page. The links onwp-activate.php
are counter to this established workflow standard throughout the rest of the WordPress code base and goes against expectations.
The issue, in the end, is that the links on http://domain.com/test1/wp-activate.php
should all have http://domain.com/test1/
as the base URL to avoid confusion and misrepresentation of where the new user will be logging in or visiting after they reach http://domain.com/test1/wp-activate.php
. Explicit links to the site of the main header [Test 1] being on the rest of the page is more logically consistent, more accessible, and a better workflow for the end user.
Here is a proposed fix:
In wp-activate.php
on lines 149-152 (https://core.trac.wordpress.org/browser/trunk/src/wp-activate.php#L149), the code would need to be adjusted to correctly provide the correct blog based on the user associated with the provided key; the same issue exists with lines 158-161 (https://core.trac.wordpress.org/browser/trunk/src/wp-activate.php#L158). wp_lostpassword_url()
is not cognizant of sub-sites when generating the URL; it would need to be replaced with a call to network_site_url
. Speaking of, network_site_url
could be modified to include the path to the current site by doing a call to get_blog_details()
just after line 140 as follows:
if ( is_wp_error( $result ) && in_array( $result->get_error_code(), $valid_error_codes ) ) { $signup = $result->get_error_data(); + $details = get_blog_details(); ?> <h2><?php _e( 'Your account is now active!' ); ?></h2> <?php echo '<p class="lead-in">'; if ( $signup->domain . $signup->path == '' ) { printf( /* translators: 1: login URL, 2: username, 3: user email, 4: lost password URL */ __( 'Your account has been activated. You may now <a href="%1$s">log in</a> to the site using your chosen username of “%2$s”. Please check your email inbox at %3$s for your password and login instructions. If you do not receive an email, please check your junk or spam folder. If you still do not receive an email within an hour, you can <a href="%4$s">reset your password</a>.' ), + network_site_url( $details->path . 'wp-login.php', 'login' ), $signup->user_login, $signup->user_email, + network_site_url( $details->path . 'wp-login.php?action=lostpassword', 'login' ) ); } else { printf( /* translators: 1: site URL, 2: username, 3: user email, 4: lost password URL */ __( 'Your site at %1$s is active. You may now log in to your site using your chosen username of “%2$s”. Please check your email inbox at %3$s for your password and login instructions. If you do not receive an email, please check your junk or spam folder. If you still do not receive an email within an hour, you can <a href="%4$s">reset your password</a>.' ), + sprintf( '<a href="http://%1$s">%1$s</a>', $signup->domain . $details->path ), $signup->user_login, $signup->user_email, + network_site_url( $details->path . 'wp-login.php?action=lostpassword', 'login' ) ); }
The second section is at line 173 (https://core.trac.wordpress.org/browser/trunk/src/wp-activate.php#L173), where we would need to perform a similar action to provide a correct path to the sub-site after the base URL.
$url = isset( $result['blog_id'] ) ? get_home_url( (int) $result['blog_id'] ) : ''; $user = get_userdata( (int) $result['user_id'] ); + $details = get_blog_details(); ?> <h2><?php _e( 'Your account is now active!' ); ?></h2> <div id="signup-welcome"> <p><span class="h3"><?php _e( 'Username:' ); ?></span> <?php echo $user->user_login; ?></p> <p><span class="h3"><?php _e( 'Password:' ); ?></span> <?php echo $result['password']; ?></p> </div> <?php if ( $url && $url != network_home_url( '', 'http' ) ) : switch_to_blog( (int) $result['blog_id'] ); $login_url = wp_login_url(); restore_current_blog(); ?> <p class="view"> <?php /* translators: 1: site URL, 2: login URL */ + printf( __( 'Your account is now activated. <a href="%1$s">View your site</a> or <a href="%2$s">Log in</a>' ), $url, esc_url( $login_url ) ); ?> </p> <?php else : ?> <p class="view"> <?php /* translators: 1: login URL, 2: network home URL */ + printf( __( 'Your account is now activated. <a href="%1$s">Log in</a> or go back to the <a href="%2$s">homepage</a>.' ), network_site_url( $details->path . 'wp-login.php', 'login' ), network_home_url($details->path) ); ?> </p>
Please note that these suggestions have not tested sub-domain setups, so there is likely additional complexity involved that wouldn't work with the path-based solution I have provided, as I do not have a sub-domain setup to test against.
Thank you for reading and taking these suggestions into consideration against the current version of WordPress. I think that this is a straightforward modification that will offer clarity and improve usability of WordPress for the new user activation workflow on network installs.
Hi @pkarjala, welcome to WordPress Trac! Thanks for the ticket.
There's no need to do that, it's better to keep the discussion in one place. As far as I can see, this appears to be the same issue, so I'm closing this one as a duplicate.