Opened 14 years ago
Closed 14 years ago
#3182 closed defect (bug) (fixed)
default_component set to invalid component slug if activity component disabled
| Reported by: |
|
Owned by: | |
|---|---|---|---|
| Milestone: | 1.5 | Priority: | critical |
| Severity: | Version: | 1.5 | |
| Component: | Extended Profile | Keywords: | needs-testing |
| Cc: |
Description (last modified by )
When the activity component has been disabled, http://example.com/members/admin/ 404s.
Attachments (1)
Change History (5)
Note: See
TracTickets for help on using
tickets.
So, this one took ages to track down and I'd like some feedback on whether a) the patch works and b) whether it's fixed in the best way before we put it in.
To recreate the issue, on trunk, deactivate all BuddyPress components. Then go to http://example.com/members/admin/. Without the patch, it should 404, and with the patch, it should load the WordPress Profile fallbacks. Then test again with each of the BuddyPress components enabled (only one at a time); the two I found trouble with were Activity and Extended Profiles, everything else worked fine for me without any patch.
The issue is caused by the current_component in some situations being set to 'xprofile' (bp->activity->id). In branch it was set to 'profile' but in trunk it is 'xprofile'. It's not possible to change the bp->activity->id as it breaks the includes in the new class component.