multisite system messages: {{ link }} not only for primary domain, but for all

[monchito]

Description

The siteId of the primary site is explicitly passed in when generating {{ link }} urls (e.g. as password reset link, account activation, etc. in a system message). The code is here:

https://github.com/craftcms/cms/blob/develop/src/services/Users.php#L1079-L1081

This is because all users are 'global' within the same craft install.

Makes sense, from a developers' point of view. But less for users imho

This creates unwanted behaviour when applied to a multisite setup like mine (and hopefully others as well :p), that currently has 3 domains and 4 'sites' (1 domain has two languages). The 3 domains have different looks and feels.

And in particular: 1 domain (which is not the primary domain) does something for a specific usergroup that doesn't do anything with the other domains.

Steps to reproduce

1. So when a user signs up on my custom registration form
2. they are added to this specific user group
3. receive the email activation link, but are thus sent to another domain with (slightly) another look and feel
4. complete the activation process there
5. and are then redirected to the homepage of the primary domain. In short: they are lost.

They should:

1. receive an activation email with a {{ link }} that points to the domain where they signed up
2. and upon activation
3. they should be redirected to a page on that domain, not a completely other (in their point of view, they don't know or care about the way my database is structured)

So I think it would be a nice feature if system messages optionally become multisite-aware. By default the primary domain is used, unless for a specific site I don't want to

Additional info

• Craft version: pro 3.0.12
• PHP version: 7.1
• Database driver & version: mysql
• Plugins & versions: for the signup / registration process: a custom plugin that hooks into craftcms default behaviour

[gioppe]

I think it would be a better experience for the users. Also, it would be nice to have better / more explicit control over system messages' language: they follow the current admin language preferences (or so it seems), while in my opinion they should stick to the originating domain language, as well as the {{link}} target.

[timkelty]

This is pretty big issue for us, especially if you sites are on different domains and all together unique (not just languages).

Users end up getting an email with a link sending them to a site they've never been to, which can feel like a phishing attempt.

[brandonkelly]

The behavior stems from Craft 2, but I guess with multi-site there is more of a case for having the links take you to the same site you registered on.

[Anubarak]

We are facing the same issue, a quick fix might be to include a siteId in such functions like

craft\services\Users

    /**
     * Sets a new verification code on a user, and returns their new Password Reset URL.
     *
     * @param User $user The user that should get the new Password Reset URL
     * @return string The new Password Reset URL.
     */
    public function getPasswordResetUrl(User $user): string  (( <--- pass siteId
    {
        return $this->_getUserUrl($user, 'set-password');
    }

Or here in the private function _getUserUrl(User $user, string $action) - there is already a Todo

        // todo: should we factor in the user's preferred language (as we did in v2)?
        $siteId = Craft::$app->getSites()->getPrimarySite()->id;
        return UrlHelper::siteUrl($path, $params, $scheme, $siteId);

@brandonkelly We are going to launch the project within 1-2 months, can you eventually tell us within the next few weeks if we need to overwrite the Users service via service locator in order to gain the ability to change the site? Because this feature is an absolute must have for us since the sites are totally different and have sometimes nothing in common.

[thisisjamessmith]

Just coming back to this... for me there's still an unresolved issue here:

When an admin user triggers the "Send password reset email" action from the CP for a non-admin (front-end) user (Users > [select a user] > select 'send password reset email' from top right cog)... The link in the email received by the user points to the primary domain rather than the domain they registered on/have access to.

[brandonkelly]

Craft doesn’t keep track of which site a user registered from, so it’s not possible for Craft to know which site the password-reset link should point to from the Control Panel. It will only work for users who trigger a password-reset email themselves via a forgot password form.

[thisisjamessmith]

Yep, understood.

Still, from the client's point of view, it's a bit annoying to have a function available in the CP which they must remember to never use! I've instructed them to use the front end form instead, but at some point, someone will forget, or new staff members without The Knowledge will come on board.

I've partly worked around the issue by adding a redirect template on the primary domain to the secondary domain's 'success' page, so at least they go to the 'right' site after submitting a new password, but the initial screen that asks for the password is still on the wrong domain and has the Craft styling. Fortunately this is only a 2-site installation as clearly this workaround can't scale beyond that.

Perhaps if there are multiple sites, the function could ask the admin user which site to use for the link, or at least warn them that the email will contain a link to {{ primaryDomain }}.

[brandonkelly]

Have you considered switching your primary site to the other one?

[thisisjamessmith]

yes, considered that, but a little afraid of unforeseen consequences. The secondary site is indeed considered "secondary" semantically speaking...

[Anubarak]

My current workaround is to track the "primary" site of each user and replace the given link from Craft via Twig filter with the users primary site URL in the template

[thisisjamessmith]

Thanks Robin, that's a good plan for now :-)

[thisisjamessmith]

During testing I've found that switching the secondary site to be the primary site breaks the search in the Users list... it just returns nothing for every search. Switching the sites back restores the search functionality. Have added as a new issue #5281