Support #20267


user's site defaults to home page

Added by Marilyn Weber about 2 months ago. Updated 28 days ago.

Priority name:
Category name:
Target version:
Start date:
Due date:
% Done:


Estimated time:
Deployment actions:


From Keeping:

"I'm writing because two of my course sites for the current semester are automatically redirecting all visitors (students as well as myself) to When I type the url in with /wp-admin at the end, I can still access the dashboard, and everything looks normal there. The sites in question are:

Is there anything I can do to resolve this issue? Any advice would be much appreciated."

Same thing is happening for me.

Actions #2

Updated by Boone Gorges about 2 months ago

The immediate cause is bp_redirect_canonical(). For some reason, when loads, BP is determining that $bp->current_component is 'groups'. So bp_redirect_canonical() is getting confused and is bouncing back to the home page.

I don't have a clear idea of why BP would do this. It probably has something to do with the recent upgrade to BP 12, without the use of BP Classic. I checked rewrite rules on the site in question, and I don't think think that it's directly related to rewrites.

It's not entirely clear to me why BP should be doing its URL parsing at all when not on the root blog. So, as a temporary workaround while we dig into the issue, I've added a file at wp-content/mu-plugins/20267-disable-bp-redirect-canonical-for-secondary-sites.php that (as the filename suggests) unhooks bp_redirect_canonical() while on non-root-blogs.

Ray, I don't have time to diagnose this today, so if you're putting it some weekend hours, please have a look. Otherwise I'll circle back tomorrow and see if I can figure out the root cause.

Actions #3

Updated by Boone Gorges about 2 months ago

As I pressed submit I realized that my fix was not really working - the site was loading, but BP was injecting the groups directory on the home page. So, to my temporary workaround, I've added a manual resetting of $bp->current_component.

Actions #4

Updated by Raymond Hoh about 2 months ago

The issue is due to the check for bp_is_directory_homepage() in the group component's parse_query() method:

This check is intended to see if the group directory page ID matches the front page's ID on the root site. If so, BP will manually set the BP current component to groups. However, as you mentioned, Boone, this check should be omitted from sub-sites altogether since this isn't intended behavior as this ticket brought up what happens if there is a page ID conflict between the root site's group directory page ID and a sub-site's front page ID. In the meantime, your hotfix should address the issue for now. I'll write up a ticket for BP about limiting the usage of bp_is_directory_homepage() to the root site. Update: I've created the BP ticket.

Actions #5

Updated by Boone Gorges about 2 months ago

Thanks for opening the ticket! I think we can probably leave my workaround in place for now, and we'll revisit once there's an upstream fix.

Actions #6

Updated by Marilyn Weber about 2 months ago

So far this works -

But this doesn't - That goes to home page.

The other ticket is about the seemed to be pointing to a Groups page which doesn't exist. I've asked the user to clarify what the home page should be

Actions #7

Updated by Boone Gorges about 2 months ago

All three sites are, for me, loading in a way that appears to be correct:

Marilyn, if you're seeing something different, it could be that your browser is caching a redirect. Try an incognito or private window.

It could be that the qcap.commons problem no longer exists after my temporary workaround, as their home page looks correct to me.

Actions #8

Updated by Marilyn Weber about 2 months ago

You're correct, sorry. will follow up with the users

Actions #9

Updated by Boone Gorges 28 days ago

  • Status changed from New to Resolved

I'm going to mark this ticket as complete, since the upstream BP fix has been merged.


Also available in: Atom PDF