New user activation welcome page links to the wrong site

[tmoore41]

I am having a problem with the welcome page that new users are shown after they have clicked on the link to activate their account.

I am using multisite, and I am adding users from within one of the child sites, not from the network site.

On the welcome page that shows the username and password there are links to go to the site or to login to the site. However, these links go to the network site, not to the child site. New users get confused because they are taken to a login page for a site (the network site) that they don’t have permission to access.

I looked in to the code in wp-activate.php to see what is happening to cause this. It seems that at line 128 there is a check to see what blog to link to:

$url = isset( $result['blog_id'] ) ? get_home_url( (int) $result['blog_id'] ) : '';

$result is what comes back from the wpmu_activate_signup function. If blog_id is not set then there the home url does not get set, and then the network url is used. It looks like in my case the blog_id is not getting set.

I then took a look in wpmu_activate_signup to see why the blog_id was not getting set. That turned up line 1020:

return array( 'user_id' => $user_id, 'password' => $password, 'meta' => $meta );

where as you can see the blog_id isn’t set. However, the blog id is available in $meta['add_to_blog]. So I tried changing this line to

return array( 'user_id' => $user_id, 'password' => $password, 'meta' => $meta, 'blog_id' => $meta['add_to_blog'] );

and now wp-activate.php sets the links correctly and the welcome page works as expected.

Is this behaviour expected (bug or feature)? Can it be fixed so that users do not get links that lead them to blogs that they have no access to?

[createscape]

I am having the same problem.

[Mista-Flo]

I have looked into the code and @tmoore41 said truth, the returned array by wpmu_activate_signup function is a user signup or a site (blog) signup, the main issue is that args from this array are not the same for the both situation, so in this context, blog_id is not an arg of the user signup return array in wpmu_activate_signup.

So at first, to fix this bug, I prefere to edit wp-activate.php file, and let wpmu_activate_signup refactoring for this bigger ticket : https://core.trac.wordpress.org/ticket/38750

[Mista-Flo]

Fix wrong blog id var for login url in wp_activate.php

[Mista-Flo]

Just spoted another similar issue in wp-activate.php on line 100. When the new user account just has been activated, refresh the page, the login URL is still network URL instead of site login URL. With the network login URL, when trying to connect to the network, it crashes like said in the ticket description.

[Mista-Flo]

Fix both wrong login URL

[Mista-Flo]

Second patch fixes previous issue reported on https://core.trac.wordpress.org/ticket/39311#comment:3

I have tested this patch on last trunk version on a multisite install, it works fine for the described bug.

[Mista-Flo]

#33527 was marked as a duplicate. It seems that this ticket point out the same issue, but also with lost password, etc... So maybe we should take a better look to really solve this issue.

[Mista-Flo]

#38885 was marked as a duplicate.

[Mista-Flo]

Steps to reproduce :

Go in the new user form admin page in a site level. Create the user with email confirmation.
Get the activation link : this is the site URL with wp-activate.php.
Then at this page, the user is asked to login to the primary site of the network wp-login.php page, and not the sub site one. When the user tried to enter its new password, there is a wp_die "Sorry you're not allowed to visit this page".
Same thing for the second link of the page wp-activate, it says go back to "Homepage", but it's the home URL of the primary site of the network, not of a the sub site.

[Ipstenu]

I mentioned this in slack as the issue comes up a lot in this ticket - There is no such thing as a "network URL" or "Network Site"

There's a Network admin and a Main/Primary site, but the 'network site' doesn't exist. It makes it harder to debug when you call the Main Site the network site. And this is not anyone's fault: WP for a long time had the main site be the network administration. We don't anymore, and it's very important we're clear on where someone is being redirected to, as those are very different behaviors.

I know I sound pedantic and nit-picky but when reporting bugs, it's really important to use the proper terms once you know them. It helps make sure we're all talking about the same thing.

So to reiterate what's going on:

1. Go to a subsite (ex domain.com/subsite/ or sub.domain.com)
2. Create the user with email confirmation.
3. User gets the activation link

The URL at that point is not the expected subsite URL (ex domain.com/subsite/wp-activate.php or sub.domain.com/wp-activate.php)

Instead it is domain.com/wp-activate.php

I did this:

I went to my subsite (domain.com/test) and added a new user

Hi,
You've been invited to join 'test' at
​http://domain.com/test 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/test/wp-activate.php?key=KEYHERE

That's exactly what I expect to see in my email.

However it's the rederning of the page that's wrong:

Your account is now active!

Username: USER

Password: PASSWORD

Your account is now activated. Log in or go back to the homepage.

The link for login is domain.com/wp-login.php

Now when I'm added to a site, which is what this ticket claims we're doing (go to a subsite to add the user), WordPress properly redirects me on login to domain.com/test/wp-admin (it's supposed to do that)

So I don't see the problem as indicated. I can see it happening if you just add the user to the network at domain.com/wp-admin/network/user-new.php but that isn't what was reported.

I am using multisite, and I am adding users from within one of the child sites, not from the network site.

When I add users from the child site, the login link being the main site is not an issue, as WP redirects on login to 'My' site.

Question for @tmoore41: Are these NEW users or existing users?

[Mista-Flo]

@Ipstenu Ok I got it, I had a plugin installed that set an empty role for the new user, so that's why I had a wp_die error in the login, sorry for the bad test and time consuming.

I have tested without the plugin and all worked like you said, WordPress redirect me to the good admin of the subsite. So no issue with the login. But the homepage link displayed is always the primary website home_url instead of the subsite one, maybe we should handle this no ? And if we look at my patch and the ticket description, there is a var $result['blog_id'] that doesn't exist, we should replace it by $result['meta']['add_to_blog']

So @tmoore41 are you sure your user has a role at the registration ? Check your installed plugins, try to disable all of them and test again if you encounter the same behavior.

[Ipstenu]

But the homepage link displayed is always the primary website home_url instead of the subsite one, maybe we should handle this no ?

If it's not breaking things, and WP is 'smart enough' to redirect you to the right location, I doubt most users will notice. Plus IIRC that is still filterable so we're back to where we usually are with "What's the intent of YOUR network?"

I want everyone to know they're on a network. Not everyone does :)

That is the big question I have no answers for, to be honest. I don't know how we can determine intent without a lot more options in Multisite :(

[Mista-Flo]

Ok I understand, thanks for your help.

Yes, that's hard to know what kind of network it is. Maybe we should let the primary website link, and add the sub site link to be more clear.

Like "Check here the main website, or check the site where you were added".

[tmoore41]

Hi @lpstenu

Thanks for the corrections regarding nomenclature. I'll try to follow your guidelines.

My comments further down....

Replying to Ipstenu:

I mentioned this in slack as the issue comes up a lot in this ticket - There is no such thing as a "network URL" or "Network Site"

There's a Network admin and a Main/Primary site, but the 'network site' doesn't exist. It makes it harder to debug when you call the Main Site the network site. And this is not anyone's fault: WP for a long time had the main site be the network administration. We don't anymore, and it's very important we're clear on where someone is being redirected to, as those are very different behaviors.

I know I sound pedantic and nit-picky but when reporting bugs, it's really important to use the proper terms once you know them. It helps make sure we're all talking about the same thing.

So to reiterate what's going on:

1. Go to a subsite (ex domain.com/subsite/ or sub.domain.com)
2. Create the user with email confirmation.
3. User gets the activation link

The URL at that point is not the expected subsite URL (ex domain.com/subsite/wp-activate.php or sub.domain.com/wp-activate.php)

Instead it is domain.com/wp-activate.php

Yes, this is correct. I am using sub-domains so it looks like your second case of sub.domain.com/wp-activate.php.

I did this:

I went to my subsite (domain.com/test) and added a new user

Hi,
You've been invited to join 'test' at
​http://domain.com/test 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/test/wp-activate.php?key=KEYHERE

That's exactly what I expect to see in my email.

However it's the rederning of the page that's wrong:

Your account is now active!

Username: USER

Password: PASSWORD

Your account is now activated. Log in or go back to the homepage.

The link for login is domain.com/wp-login.php

Now when I'm added to a site, which is what this ticket claims we're doing (go to a subsite to add the user), WordPress properly redirects me on login to domain.com/test/wp-admin (it's supposed to do that)

So I don't see the problem as indicated. I can see it happening if you just add the user to the network at domain.com/wp-admin/network/user-new.php but that isn't what was reported.

The problem is that access to domain.com is restricted to register users of domain.com. When you try to access domain.com (or domain.com/wp-login.php etc) you will be presented with a login form requesting a username and a password. In my case the subscribers of the sub-sites are not subscribers to domain.com, so their username and password will not work.

They get stuck on the login page, and try to do things like reset their password multiple times.

To make it worse, there is very little to indicate that they are at the wrong site. The only clue is the URL in the browser location bar, and I can't expect new users to figure this out.

This is not a situation that new users can figure out.

I am using multisite, and I am adding users from within one of the child sites, not from the network site.

When I add users from the child site, the login link being the main site is not an issue, as WP redirects on login to 'My' site.

Yeah, if only they could get past the login screen on that site it might work.

Question for @tmoore41: Are these NEW users or existing users?

New users. Only having access to the sub-site. Not having access to the main site.

[tmoore41]

Replying to Ipstenu:

But the homepage link displayed is always the primary website home_url instead of the subsite one, maybe we should handle this no ?

If it's not breaking things, and WP is 'smart enough' to redirect you to the right location, I doubt most users will notice.

Maybe I'm missing some detail here. Perhaps for situations where the main site is accessible to all this might be some kind of work around. It does not seem like a process that covers all use cases.

Plus IIRC that is still filterable so we're back to where we usually are with "What's the intent of YOUR network?"

You mention that something is filterable, so maybe all hope is not lost. What exactly was the 'that' in your sentence referring to?

I want everyone to know they're on a network. Not everyone does :)

What's this network thing? I thought we had main sites and sub sites? ;)

That is the big question I have no answers for, to be honest. I don't know how we can determine intent without a lot more options in Multisite :(

Seems easy to me. A user (new or old, doesn't matter) is subscribed to a sub site. The activation process carries the meta data and knows what sub-site they are subscribed to. After they activate the welcome message should direct them to that sub-site. Directing to the main site in order to redirect seems more complicated than required, and in my use case it is broken.

[tmoore41]

Replying to Ipstenu:

So to reiterate what's going on:

1. Go to a subsite (ex domain.com/subsite/ or sub.domain.com)
2. Create the user with email confirmation.
3. User gets the activation link

The URL at that point is not the expected subsite URL (ex domain.com/subsite/wp-activate.php or sub.domain.com/wp-activate.php)

Instead it is domain.com/wp-activate.php

Actually no. The message in the email invitation is

Please click the following link to activate your user account:
​http://sub.domain.com/wp-activate.php?key=1dd86778b57c5147

The invitation link goes to the correct place. It is the welcome links that go to the wrong place.

[Ipstenu]

• The entire install is a network install with a network admin: WP-admin/network
• Each site has a front: example.com and sub,example.com
• And an admin: example.com/WP-admin

But the network does not have a public front facing aspect, hence there is no 'network site' that one is directed to.

Moving on.

By default, the main site doesn't need to be accessible to log in, because WordPress redirects you to YOUR site if you try to log in to it and don't have an account there.

If that's not happening on your install, there's the problem. But I did just build a brand new install to test that on and the results on a clean install were clear. WP properly redirects. This sounds a lot like your configuration broke default behavior so now... what did you do? :)

Try it on a CLEAN install. Then we can start adding min your features to see where this broke and why. Because WP does know your primary site already and should be redirecting you.

[tmoore41]

Replying to Ipstenu:

• The entire install is a network install with a network admin: WP-admin/network
• Each site has a front: example.com and sub,example.com
• And an admin: example.com/WP-admin

But the network does not have a public front facing aspect, hence there is no 'network site' that one is directed to.

Moving on.

By default, the main site doesn't need to be accessible to log in, because WordPress redirects you to YOUR site if you try to log in to it and don't have an account there.

Is this really true? What if I use htaccess rules to prevent access to the 'main site', because that is only there for the network admin to log in to.

If that's not happening on your install, there's the problem. But I did just build a brand new install to test that on and the results on a clean install were clear. WP properly redirects. This sounds a lot like your configuration broke default behavior so now... what did you do? :)

Access to the main site is denied to everyone except the network admin because a) security and b) this is not a public site... there is nothing here for people to see. I have only left a couple of exceptions to this (wp-cron, wp-login, etc).

All I am concerned about here are the links on the welcome page. It seems to be an artificial restriction that I must have have a publicly accessible main site so that magic redirection works, when it is trivially easy to change the welcome page to avoid this. Honestly, what is the principle behind this? Why does magic redirection have to be used in this case, when it is so easy to avoid?

Try it on a CLEAN install. Then we can start adding min your features to see where this broke and why.

I believe it broke in the design phase.

Because WP does know your primary site already and should be redirecting you.

[Ipstenu]

Okay, NOW we're making progress!

You have a heavily customized install :) That's important for us to know to debug.

The main site (example.com) is meant to be a publicly viewable site. Obviously there are ways around it, like WordPress.com (not sure how they did it TBH). But by making it so example.com is NOT accessible at all, that's why this happened. If it was, just as a landing page or what have you, it should properly redirect people where they need to go.

All I am concerned about here are the links on the welcome page. It seems to be an artificial restriction
that I must have have a publicly accessible main site so that magic redirection works, when it is trivially
easy to change the welcome page to avoid this. Honestly, what is the principle behind this? Why does
magic redirection have to be used in this case, when it is so easy to avoid?

You're falling to the original intent of WordPress Multisite, which was to manage a network of related, but not fully interconnected sites. That's why knowing the history of a thing helps us debug and why I was digging into the history of what YOU are doing. :) With the right information, we can understand the real problem based on your real intent.

So!

Why is yours breaking?

Because your main site isn't 'not accessible to login' but 'not accessible AT ALL.' Meaning, as I understand it, if I went to your example.com, I would be blocked.

You can use ​https://developer.wordpress.org/reference/hooks/wpmu_signup_user_notification_email/ to rewrite the email so it links to the per-site :)

[tmoore41]

Replying to Ipstenu:

Okay, NOW we're making progress!

You have a heavily customized install :)

I do not have a heavily customized install. This problem would also occur on a vanilla wordpress install if the htaccess rules blocked access to the main site (not an unreasonable thing to do for some use cases).

That's important for us to know to debug.

No debugging is required. See my original post in this thread. The problem is obvious in the code.

The main site (example.com) is meant to be a publicly viewable site.

This would appear to be a regression from former behaviour because I did not see this happening several releases ago on my same setup.

Obviously there are ways around it, like WordPress.com (not sure how they did it TBH). But by making it so example.com is NOT accessible at all, that's why this happened. If it was, just as a landing page or what have you, it should properly redirect people where they need to go.

All I am concerned about here are the links on the welcome page. It seems to be an artificial restriction
that I must have have a publicly accessible main site so that magic redirection works, when it is trivially
easy to change the welcome page to avoid this. Honestly, what is the principle behind this? Why does
magic redirection have to be used in this case, when it is so easy to avoid?

You're falling to the original intent of WordPress Multisite, which was to manage a network of related, but not fully interconnected sites. That's why knowing the history of a thing helps us debug and why I was digging into the history of what YOU are doing. :) With the right information, we can understand the real problem based on your real intent.

So!

Why is yours breaking?

Because your main site isn't 'not accessible to login' but 'not accessible AT ALL.' Meaning, as I understand it, if I went to your example.com, I would be blocked.

No, if you went to 'example.com' you would be presented with a login page. If you were a registered user and had the correct password then you could access the site.

You can use ​https://developer.wordpress.org/reference/hooks/wpmu_signup_user_notification_email/ to rewrite the email so it links to the per-site :)

You are misunderstanding the problem stated in the original post. The email invitation links to the correct page. It is the welcome message that is sent after the activation that links to the wrong site. This is trivially easy to fix, although I defer to @Mista-Flo and @johnjamesjacoby that the activation process should be fixed in a more thorough manner.

I'm not looking for technical support here. As mentioned in the original post I made a one-line change that fixed the problem for me. I just wanted to report this defect to the core project so that other people were made aware of it. I would be happy to answer any other questions about the issue if it would help to get it resolved.

[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:

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.

[ksoares]

We are having the exact same issue, and the previous post by @pkarjala explains it very clearly and accurately. The only difference between the situation as @pkarjala explains it and our situation, is that we use subdomains instead of subfolders, but the problem is identical, as is the solution.

Given the fact that an extremely simple, minimally invasive, and non-risky solution has been presented, I hope this can be added to WP core asap. Without this change, we will have to manually modify the core each time we update WP, in order to avoid the same situation happening each time we do an update of core.

BTW, this ticket would not let me set the Version higher than 4.7, but we are on WP 5.1.1 and still seeing this problem.

[SergeyBiryukov]

#47287 was marked as a duplicate.

[pkarjala]

Is there any way to get traction or put this issue in front of someone who has some? It's a relatively simple fix, and I believe it would help streamline the login process for new accounts and make it more clear which site in a network install the user has signed up for and is logging into.

[pkarjala]

Because of the change from using network_site_url() to using wp_lostpassword_url() for generating the reset your password text on the wp-activate.php page, I am working on a new solution. However, wp_lostpassword_url() makes a call to network_site_url() to generate the link, so I will be focusing on network_site_url(). This is in WordPress 5.3-alpha-45565.

The fix, instead, may be to correct or amend the functionality of network_site_url() to properly return the current path if the user is on a subdomain or on a subfolder network site. Currently, network_site_url() will properly parse and handle subdomain networks. But it fails to properly process and present subfolder network sites.

Thus, it may be better to check for whether the network install is subdomain or subfolder, and then modify the path accordingly.

One potential suggestion is to modify the $path variable in network_site_url() and network_home_url() as follows

diff --git a/wp-includes/link-template.php b/wp-includes/link-template.php
index 77b18c6fca..7e29cfa82d 100644
--- a/wp-includes/link-template.php
+++ b/wp-includes/link-template.php
@@ -3373,6 +3373,13 @@ function network_site_url( $path = '', $scheme = null ) {
                $url = set_url_scheme( 'http://' . $current_network->domain . $current_network->path, $scheme );
        }

+       if ( SUBDOMAIN_INSTALL === false ) {
+               $current_blog = get_blog_details();
+               if ( $current_blog->path != '/' ) {
+                       $path = $current_blog->path . $path;
+               }
+       }
+
        if ( $path && is_string( $path ) ) {
                $url .= ltrim( $path, '/' );
        }
@@ -3423,6 +3430,13 @@ function network_home_url( $path = '', $scheme = null ) {
                $url = set_url_scheme( 'http://' . $current_network->domain . $current_network->path, $scheme );
        }

+       if ( SUBDOMAIN_INSTALL === false ) {
+               $current_blog = get_blog_details();
+               if ( $current_blog->path != '/' ) {
+                       $path = $current_blog->path . $path;
+               }
+       }
+
        if ( $path && is_string( $path ) ) {
                $url .= ltrim( $path, '/' );
        }

I am still testing, but this does cover the specific use cases where the network setup is subfolder one. Will add a .patch in a bit. My primary concern is other places where network_site_url() and network_home_url() are in use.

[pkarjala]

Add Subfolder check to network_site_url() and network_home_url() calls.

[pkarjala]

New diff uploaded, needs testing and verification, particularly in cases where network_site_url() and network_home_url() are called that would have side effects from the proposed diff.

[davidbaumwald]

This ticket hasn't seen any movement this cycle. With 5.3 RC1 approaching, this is being moved to Future Release. If a committer feels strongly about this one being in 5.3 and has the time to see it through, it can be moved back up.

[mukesh27]

@pkarjala, Can you please update patch fix-multisite.39311.3.diff as per Yoda Conditions - ​https://make.wordpress.org/core/handbook/best-practices/coding-standards/php/#yoda-conditions

EX.

<?php
if ( false === SUBDOMAIN_INSTALL) {
        $current_blog = get_blog_details();
        if ( '/' !== $current_blog->path ) {
                $path = $current_blog->path . $path;
        }
}

[pkarjala]

Just cloned down the dev version, working on generating new diffs.

[pkarjala]

OK, I did find an issue with the proposed fix in the diff, in that it modifies all Network base URLs to include the path of any subsite you are currently on, which breaks the My Sites -> Network Admin menu links. For example, if you are on a subsite mydomain.com/test1/ then the Network Admin menu links become mydomain.com/test1/wp-admin/network/ instead of mydomain.com/wp-admin/network/.

I'm going back to proposing changes directly to the path information being entered in the emails sent from wp-activate.php instead, and will have that diff up a little later today.

[pkarjala]

Updates to wp-activate.php and general-template.php to display correct path for subsites with path.

[pkarjala]

@mukesh27 new diff added, this falls back on adding the blog path in a multisite setup to the URL for the landing page the first time a user activates their account, or after a user attempts to activate an already activated account. It also make sure that the Activate form goes to the correct subsite based on which subsite it was called on.

It may be more prudent to update network_site_url() to be savvy about which subsite it is being called on, but this will suffice to fix this issue.

Changes in the diff are based off of WordPress as of this commit: ​https://github.com/WordPress/WordPress/commit/1cde7d86f9ae687721f712c2cbc7e5b331748e06

[whyisjake]

@pkarjala could you update the diff to use add_query_arg to pass in the lostpassword action param?

I'm not sure we want to be concatenating strings inside of a sprintf function either.

[pkarjala]

@whyisjake Can you please clarify in what manner you'd like add_query_arg to be used in the context of the proposed changes?

As it stands, the $blog_details->path addendum to the URL is not a query argument to wp_lostpassword_url, but a change of the base URL being used, based on which subsite the user is on when they go to reset their password. It may also be the case that we ALSO want it to be part of the redirect path; if this is the case, I will change the code to include it.

I apologize if I am not understanding the request correctly, and appreciate any clarification.

I have cleaned up the sprintf usage to be:

sprintf( '<a href="http://%1$s%2$s">%1$s%2$s</a>', $signup->domain, $blog_details->path ),

which removes the problematic concatenation.

Once I have clarification for the first item, I will upload the refreshed .diff.

[pkarjala]

@whyisjake I think this is what you are asking for? Please confirm!

<?php
/**
 * Returns the URL that allows the user to retrieve the lost password
 *
 * @since 2.8.0
 *
 * @param string $redirect Path to redirect to on login.
 * @return string Lost password URL.
 */
function wp_lostpassword_url( $redirect = '' ) {
        $args = array();
        if ( ! empty( $redirect ) ) {
                $args['redirect_to'] = urlencode( $redirect );
        }
        $args['action'] = "lostpassword";
        
        $blog_details = get_blog_details();

        $lostpassword_url = add_query_arg( $args, network_site_url( $blog_details->path . 'wp-login.php', 'login' ) );

        /**
         * Filters the Lost Password URL.
         *
         * @since 2.8.0
         *
         * @param string $lostpassword_url The lost password page URL.
         * @param string $redirect         The path to redirect to on login.
         */
        return apply_filters( 'lostpassword_url', $lostpassword_url, $redirect );
}

[pkarjala]

Fixes formatting changes requested by whyisjake; tested on 5.5-beta2-48482

[pkarjala]

@whyisjake requested diff has been added based on 5.5-beta2-48482. Please let me know if any additional changes are necessary. Hopefully this one is good to make it into 5.5!

[SergeyBiryukov]

In 48672:

Login and Registration: Link to the correct site after activating a user on a Multisite install in subdirectory mode.

Props pkarjala, Mista-Flo, tmoore41, Ipstenu, ksoares, mukesh27, whyisjake.
Fixes #39311.

[SergeyBiryukov]

In 48673:

Login and Registration: Only call get_blog_details() in wp_lostpassword_url() on Multisite.

The function does not exist on single site.

Follow-up to [48672].

See #39311.

[SergeyBiryukov]

In 48674:

Login and Registration: Correct the logic for determining the path to wp-login.php in wp_lostpassword_url().

Follow-up to [48672], [48673].

See #39311.