Support #20267
closeduser's site defaults to home page
0%
Description
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 commons.gc.cuny.edu. 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:
ling350spr2024.commons.gc.cuny.edu
ling201spr2024.commons.gc.cuny.edu
Is there anything I can do to resolve this issue? Any advice would be much appreciated."
Same thing is happening for me.
Updated by Marilyn Weber 3 months ago
This ticket is https://app.keeping.com/view/s/d28eb752-b8b1-4d2f-9070-e54e457de6e3/
I'm just realizing there's probably the same problem on this ticket - https://app.keeping.com/view/s/559c3b90-13d9-426b-b4ab-5a510895bea3/
Updated by Boone Gorges 3 months ago
The immediate cause is bp_redirect_canonical()
. For some reason, when https://ling350spr2024.commons.gc.cuny.edu/ 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.
Updated by Boone Gorges 3 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
.
Updated by Raymond Hoh 3 months ago
bp_is_directory_homepage()
in the group component's parse_query()
method:
- https://github.com/buddypress/buddypress/blob/9df9764d33b34bf3cf2f48368741875b43250201/src/bp-groups/classes/class-bp-groups-component.php#L1067-L1074
- https://github.com/buddypress/buddypress/blob/9df9764d33b34bf3cf2f48368741875b43250201/src/bp-core/bp-core-functions.php#L1022-L1024
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.
Updated by Boone Gorges 3 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.
Updated by Marilyn Weber 3 months ago
So far this works - https://ling201spr2024.commons.gc.cuny.edu/
But this doesn't - ling350spr2024.commons.gc.cuny.edu. That goes to home page.
The other ticket is about qcap.commons.gc.cuny.edu. 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
Updated by Boone Gorges 3 months ago
All three sites are, for me, loading in a way that appears to be correct:
https://qcap.commons.gc.cuny.edu/
https://ling350spr2024.commons.gc.cuny.edu/
https://ling201spr2024.commons.gc.cuny.edu/
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.
Updated by Marilyn Weber 3 months ago
You're correct, sorry. will follow up with the users
Updated by Boone Gorges about 2 months ago
- Status changed from New to Resolved
I'm going to mark this ticket as complete, since the upstream BP fix has been merged.