Skip to:

Opened 12 years ago

Closed 11 years ago

Last modified 11 years ago

#3902 closed enhancement (no action required)

Settings and Messages

Reported by: chrisclayton's profile chrisclayton Owned by: chrisclayton's profile chrisclayton
Milestone: Priority: normal
Severity: minor Version:
Component: Messages Keywords:


I'd like to propose that we consider moving the settings and messages components out of the members profile component and into their own directory.

Both of them (especially messages) are top-level functionality (like the activity stream) that should be front and center in a social community and not hiding behind a users profile nav. Also unlike other components such as the users activity, profile and groups they have joined those two aren't public-facing and do not represent who the user is and why they are on the site.

Change History (8)

#1 @DJPaul
12 years ago

  • Component changed from Core to Theme
  • Milestone Awaiting Review deleted
  • Resolution set to wontfix
  • Status changed from new to closed

Settings and Private Messaging are separate components; what I think you're talking about is making a change to a default theme. This is not something we're likely to do to BP-Default for backwards-compatibility reasons with people using the theme and/or child themes. Nothing stopping a custom theme building built for this, of course :)

#2 @chrisclayton
12 years ago

  • Component changed from Theme to Messaging

Sorry, should have wrote it better, what i meant was the URL structure of messages, and allowing users to enable messages to be in the root of the site (like of hidden away under their user profile. (currently it's

possibly something like a define ('BP_ENABLE_ROOT_MESSAGES', true);

Same with settings ( instead of /members/username/settings)
Anyways, might leave this closed and write a plugin for it instead.

Last edited 12 years ago by chrisclayton (previous) (diff)

#3 @boonebgorges
12 years ago

I've seen this request with clients before.

chrisclayton - I don't think we'd consider moving the whole shebang for everyone, but a flag like the one you suggest is not the worst idea. It will probably involve some funny business in the catch_uri function, where the current_component and other low-level globals get set. If you'd like to work up a patch, and it turns out to be relatively easy, I think we could consider it. (Otherwise, like you suggest, this should be pretty doable with a plugin.)

#4 @chrisclayton
12 years ago

  • Resolution wontfix deleted
  • Status changed from closed to reopened

Deal. reopening (for now) and assigning to myself.
We'll re-discuss the status of this ticket once a patch is done.

#5 @chrisclayton
12 years ago

  • Owner set to chrisclayton
  • Status changed from reopened to assigned

#6 @boonebgorges
12 years ago

  • Milestone set to Future Release

#7 @chrisclayton
11 years ago

  • Resolution set to invalid
  • Status changed from assigned to closed

I'm closing this and releasing this as a plugin. This is plugin territory, rather than core as I imagine cores implementation is OK for the majority.

#8 @johnjamesjacoby
11 years ago

  • Milestone Future Release deleted
Note: See TracTickets for help on using tickets.