[wp-trac] [WordPress Trac] #47287: New User Activation Page Links are Misleading
WordPress Trac
noreply at wordpress.org
Thu May 16 01:23:23 UTC 2019
#47287: New User Activation Page Links are Misleading
------------------------------------+-----------------------------
Reporter: pkarjala | Owner: (none)
Type: defect (bug) | Status: new
Priority: normal | Milestone: Awaiting Review
Component: Login and Registration | Version: 5.2
Severity: normal | Keywords:
Focuses: |
------------------------------------+-----------------------------
This is related to https://core.trac.wordpress.org/ticket/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.
1. Create a new user in domain.com/test1/wp-admin/user-new.php
2. 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.
3. 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.
1. 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 site `wp-login.php` page, but
the typical end user does not know this, and the "magic" of it "just
working" is obtuse.
2. 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 at `http://domain.com/wp-
login.php`. Alternatively, if we have styled or modified
`http://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.
3. We are currently developing content for `http://domain.com/` and have
only exposed `http://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 to
`http://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.
4. 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 to `http://domain.com/` not currently
being world available.
5. 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 on `wp-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:
{{{#!php
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.
{{{#!php
$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.
--
Ticket URL: <https://core.trac.wordpress.org/ticket/47287>
WordPress Trac <https://core.trac.wordpress.org/>
WordPress publishing platform
More information about the wp-trac
mailing list