Opened 10 years ago
Closed 8 years ago
#6001 closed enhancement (wontfix)
BP_MEMBERS_SLUG should be used in the groups/groupname/members slug
| Reported by: |
|
Owned by: | |
|---|---|---|---|
| Milestone: | Priority: | low | |
| Severity: | normal | Version: | |
| Component: | Groups | Keywords: | |
| Cc: |
Description
Currently defining this slug does nothing. It should at least change the slug of "Groups -> [Any Group] -> Members" page.
Change History (3)
#1
@
10 years ago
- Summary changed from BP_MEMBERS_SLUG should be used in groups too to BP_MEMBERS_SLUG should be used in groups
#2
@
10 years ago
- Milestone changed from Awaiting Review to Future Release
- Priority changed from normal to low
- Summary changed from BP_MEMBERS_SLUG should be used in groups to BP_MEMBERS_SLUG should be used in the groups/groupname/members slug
- Type changed from defect (bug) to enhancement
#3
@
8 years ago
- Milestone Future Release deleted
- Resolution set to wontfix
- Status changed from new to closed
After come consideration (well, yeah, 2 years long) I think we should not customize this slug as it's self-explanatory and seems to be relevant.
When (if) custom WordPress routing will be implemented, all the URL API will be completely rewritten, so nothing to do for this particular task right now.
Note: See
TracTickets for help on using
tickets.
The "members" part of this slug is inside what we call a component's sub-navigation. Visually, it's displayed in a separate block from a component's main navigation.
I am pretty sure that no part of any component's sub-navigation items are currently able to have its slug customised without hacking core in multiple places. The fact that "members" also happens to be the slug of another BP component is an unforunate and confusing coincidence.
I don't think we plan to address this until, in some future release, we use WP rewrite rules to handle URL routing for this, and update/change everything in one go.