[wp-trac] [WordPress Trac] #39311: New user activation welcome page links to the wrong site

WordPress Trac noreply at wordpress.org
Tue Mar 5 21:26:07 UTC 2019


#39311: New user activation welcome page links to the wrong site
-------------------------------------+------------------------------
 Reporter:  tmoore41                 |       Owner:  (none)
     Type:  defect (bug)             |      Status:  new
 Priority:  normal                   |   Milestone:  Awaiting Review
Component:  Login and Registration   |     Version:  4.7
 Severity:  normal                   |  Resolution:
 Keywords:  has-patch needs-testing  |     Focuses:  multisite
-------------------------------------+------------------------------

Comment (by pkarjala):

 Chiming in on this, as it has recently affected us as well, and we are
 using a directory structure for sub-sites in our network install.  I found
 this existing discussion and didn't want to make a new thread, even though
 this one is a few years old at this point; I apologize for the discussion
 necro if this is not an appropriate place to post.

 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 issue is 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.

-- 
Ticket URL: <https://core.trac.wordpress.org/ticket/39311#comment:20>
WordPress Trac <https://core.trac.wordpress.org/>
WordPress publishing platform


More information about the wp-trac mailing list