Friend request link returns 404 error if user is not logged into website

[wrowlands]

When a member requests a friendship and the email goes out to the other member, the link returns a 404 error if the member is not logged on. I believe that the code should direct a member to log in if they are not logged in, and then once logged in direct them to the friendship request.

[johnjamesjacoby]

I agree that this behavior is exactly what should happen.

One hiccup for this experience is BuddyPress not having its own Login page. WordPress does have a function for retrieving the login page URL, and we can use it and hope the redirectto is respected, but we are a ways off from providing this type of smart redirect feature, as it would be necessary for basically any type of invitation.

Perhaps it could be looked at in a future iteration of the invitations updates that dcavins is making.

[boonebgorges]

In buddypress-group-email-subscription, @r-a-y handled this problem like this: all URLs in emails are of the form example.com/wp-login.php?redirect_to=foo/bar. If you click the link while not logged in, you get the login screen. If you are already logged in, wp-login.php passes you directly to the redirect_to URL. Maybe we can do this in our own emails?

[wrowlands]

If there were a way to fix this issue, it will be a big help. This kind of functionality is key to a positive user experience. The average person simply does not understand why they get a 404 error by clicking on a link in an email. It makes us look bad.

[johnjamesjacoby]

We understand. And we will improve this. It makes everyone look bad when user experience is compromised. If you're enjoying using BuddyPress otherwise (and if you have the means) since it appears this issue is of relatively high importance, it is possible (and appreciated) to contribute any improvements you've made yourself in the form of patches.

Thanks again for reporting this. We will be sure to prioritize it accordingly.

[wrowlands]

I have done php patches in the past and have passed them along to the great BuddyPress team of which some of them have been integrated. At this moment I do not have the time to go through the code to figure this current matter out. I am sure that the BP team will fix this. Your team is great. The BuddyPress code is the reason that our website is very popular and working GREAT. At our website ​http://rotarymeansbusiness.com/ we now have people from 30 countries connecting with each other. Thank you BuddyPress!

[dcavins]

I agree this is annoying behavior and that we can do better. Will look into it.

Boone's suggestion is immediately actionable, but more generally it seems like BP's groups access logic works well in a case like this where a user clicks into something that requires being logged in and the redirect is handled via bp-no-access. Is that not true at the component level? I'll poke around and see.

[boonebgorges]

dcavins - Right, I forgot that we handled this more elegantly in BP_Group_Extension.

The crux of the issue here is 'user_has_access': ​https://buddypress.trac.wordpress.org/browser/tags/2.2.1/src/bp-friends/bp-friends-loader.php?marks=156#L139 When this is set to false, bp_core_new_nav_item() will simply bail before registering the nav item or the screen callback ​https://buddypress.trac.wordpress.org/browser/tags/2.2.1/src/bp-core/bp-core-buddybar.php?marks=84,85#L79 A more elegant solution may be to detect that this is a page that requires a logged-in user, and to redirect to wp-login.php as appropriate. I'm not sure if this would work generally, though, since 'user_has_access' is used in a number of different ways throughout BP and BP plugins.

This is also closely related to #6301 and the intertwingledness of the way that nav items and screen callbacks are registered. If the two were separate, the puzzle would be easier to solve.

In the meantime, I don't see any harm in going with my suggestion ​https://buddypress.trac.wordpress.org/ticket/6307#comment:2. This is a targeted fix that shouldn't have any broader implications.

[dcavins]

Hmm. When I try to visit the link ​http://bptest.local/members/three/friends/requests/ without being logged in, it bounces me to the login page and properly sets the redirect. Tested with BP 2.1.1 and 2.2.1 and TwentyFifteen for the theme.

(This is the case for the other protected URL that is part of the friend request email, too: ​http://bptest.local/members/three/settings/notifications/)

Can someone else please check the default behavior? Could another plugin be modifying this core behavior?

[dcavins]

A standard BuddyPress installation produces the following behavior:

1. User receives an email containing a link: ​http://bptest.local/members/eighteen/friends/requests/

2. Upon clicking on the link (without being logged in), "bpnoaccess" access protection kicks in, sending the user off to wp-login.php with the redirect included: ​http://bptest.local/wp-login.php?redirect_to=http%3A%2F%2Fbptest.local%2Fmembers%2Feighteen%2Ffriends%2Frequests%2F&action=bpnoaccess

3. Upon successful login, the user is taken to the requested screen.

I'm closing this ticket because BuddyPress appears to be handling access gracefully in this case. @wrowlands, please respond if you can provide more information about how to reproduce the behavior that you're seeing. I'm guessing that the problem could be a URL rewrite issue or another plugin that is changing the login redirect.