WordPress.org

Make WordPress Core

Opened 7 days ago

Closed 7 days ago

Last modified 7 days ago

#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 SergeyBiryukov)

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.

  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.

  1. 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:

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 &#8220;%2$s&#8221;. 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 &#8220;%2$s&#8221;. 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.

Change History (2)

#1 @SergeyBiryukov
7 days ago

  • Description modified (diff)
  • Focuses multisite added
  • Milestone Awaiting Review deleted
  • Resolution set to duplicate
  • Status changed from new to closed

Hi @pkarjala, welcome to WordPress Trac! Thanks for the ticket.

This is related to #39311 but I am filing it as a separate ticket, as that one seems to have gone stale.

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.

#2 @pkarjala
7 days ago

Thank you @SergeyBiryukov; is there a better way to continue the discussion on this issue and/or bring it to the attention of the core WP team?

Note: See TracTickets for help on using tickets.