Skip to:

Opened 8 years ago

Closed 7 years ago

#5357 closed defect (bug) (fixed)

404 when clicking "Request Membership" within single group page

Reported by: mgibbs189 Owned by: boonebgorges
Milestone: 2.0 Priority: low
Severity: minor Version: 1.9.1
Component: Groups Keywords: has-patch 2nd-opinion


The "Request Membership" button works properly on the Groups landing page, but not on single group pages.


Attachments (5)

buddypress.js.patch (170 bytes) - added by mgibbs189 8 years ago.
5357.option1.diff (6.6 KB) - added by imath 8 years ago.
5357.option2.diff (5.9 KB) - added by imath 8 years ago.
5357.option2.02.diff (6.2 KB) - added by imath 7 years ago.
5357.03.patch (1.3 KB) - added by boonebgorges 7 years ago.

Download all attachments as: .zip

Change History (15)

#1 @mgibbs189
8 years ago

  • Keywords has-patch added

#2 @imath
8 years ago

  • Component changed from Core to Groups
  • Keywords needs-testing added
  • Milestone changed from Awaiting Review to 2.0
  • Priority changed from normal to low
  • Severity changed from normal to minor

Thanks for your feedback and patch @mgibbs189

As i've said here #5140 i've managed to reproduce the trouble.

1/ When on a single group, the group button (item's header) click is not managed with Ajax but displays the request-membership screen
2/ While regular users are reaching the site.url/groups/groupslug/request-membership/, a superadmin gets a 404.

Trouble starts in bp-groups/bp-groups-loader.php because the screen function is not available as there's this check ! bp_current_user_can( 'bp_moderate' ) around line 422

I'll check @mgibbs189's patch and i think we should also do something for part 2 of the bug to avoid the 404 in case the loggedin user is a superadmin.

As superadmins can see all groups content, they don't need to be part of the group, but i agree it should be fixed.

Last edited 8 years ago by imath (previous) (diff)

#3 @imath
8 years ago

  • Keywords 2nd-opinion added; needs-testing removed

So i've explored a bit more the issue. And i came to the conclusion that fixing it using javascript was not the best move.

The main reason is that the mechanism that loads the group template is also acting as a fallback if javascript is disabled. So the fix will not completely solve the trouble.

When on a single group, the "Request membership" button in group header acts like the subnav item having the same name. It loads the bp-template/bp-legacy/buddypress/groups/request-membership.php. With a regular user, there is no issue.

Issue only occurs when a site Administrator is clicking on the button while the group is private. As, for this particular type of user the subnav is not set in group loader, the screen function is not run and finally the function bp_core_load_template() doesn't load the group's home template resulting in a 404.

So i've built 2 patches :

  • Option 1 first adds a query arg into the button, when clicked a function is hooking bp_actions to process the membership requests.
  • Option 2 , that seemed the simple way at first.. is not so simple :) It consists in first removing ! bp_current_user_can( 'bp_moderate' ) check in the groups loader class to allow the request-membership subnav. Then, as each group is visible for a site administrator, it needs the bp-template/bp-legacy/buddypress/groups/home.php to be edited in order to include a new conditional statement to eventually load the request membership template. Then, having the request membership subnav is a bit annoying in this case so i've edited bp_get_options_nav() to remove it.

Then, as i've played with the group members subnav of the group edit screen, i've noticed that a group Administrator was able to "kick & ban" a site Administrator. If we leave it this way, then a banned site Administrator will have a request membership button although he's already member.. So i think, we shouldn't let a group admin ban a site Administrator.. I've included a way to do so in both patches.

I've chosed 2.0 milestone as it's not a regression from 1.9, it was already there in 1.8, and this is really a very particular case. On the other hand, the thread in the forum began 5 months ago, so it can be interesting, if you think one of the 2 patches is ok, to add this in 1.9.2.

What is your opinion ?

8 years ago

8 years ago

This ticket was mentioned in IRC in #buddypress-dev by imathfromparis. View the logs.

7 years ago

#5 follow-up: @DJPaul
7 years ago

Does option2 have backpat for people who've customised those templates in their theme?

#6 in reply to: ↑ 5 @imath
7 years ago

Replying to DJPaul:

Does option2 have backpat for people who've customised those templates in their theme?

Thanks a lot DJPaul for your question. I've modified the patch for option 2 (see 5357.option2.02.diff) to reply to it.

In this diff, i'm no more modifying the 'groups/single/home' to instead hook to an action of the 'groups/single/plugins' template, this way it should maximize backpat.
About the modifications i've added in the 'groups/single/admin' template, i've left them as anyway, even if a template don't have them, i'm also checking in bp-groups/bp-groups-screens.php if the user to ban is not a site administrator.

Last edited 7 years ago by imath (previous) (diff)

This ticket was mentioned in IRC in #buddypress-dev by imathfromparis. View the logs.

7 years ago

#8 follow-up: @boonebgorges
7 years ago

The don't-ban-administrators issue seems separate, and the patch seems to add a lot of complexity for an edge case. Let's think about it in a separate ticket.

My suggestion is to go with your original option 2. See 5357.03.patch. Yes, it does not provide support for themes that have customized groups/single/home.php. But this will be a small number of installations; and we won't be breaking anything for them worse than it's already broken; and in any case, people who make template-level changes should be prepared to update their templates for new fixes. So let's keep our routing logic centralized. Objections?

#9 in reply to: ↑ 8 @imath
7 years ago

Replying to boonebgorges:


5357.03.patch looks good to me :)

#10 @boonebgorges
7 years ago

  • Owner set to boonebgorges
  • Resolution set to fixed
  • Status changed from new to closed

In 8159:

Allow site admins to visit the Request Membership page of a private group

Fixes #5357

Props imath

Note: See TracTickets for help on using tickets.