The reason for this is to protect site content from broken links. All activity is hard coded. So those links get broken.
@modemlooper,
Thanks for the feedback. Given that restriction, the outcome makes sense. I assume the “hardcoding” decision was made some time ago and there are valid reasons for taking that approach. Do you know if it is still valid today? Is the evolution of a “group” within a community not of value? Its name, and all that’s tagged to it: its admins, its mods, its members, its events, etc over time?
An example would be Steve Jobs. Let’s say that, in my community, he had created a group called Apple Computer Inc (way back in the day). Then, to reflect, the evolution of the company and its commensurate change in name, he wants to change the name of his group to Apple Inc. BuddyPress allows the change in name but the slug still reflects the old company vision. The ancestry/lineage should be handled automatically. I’ll add it to my wish list.
There really isn’t a similar issue with “member” since the slug is the username.
Thanks again, for responding.
It’s to preserve database calls etc. it’s been suggested before to save an array of info instead. But there was some mention if speed
@modemlooper,
Hhhmmm… okay. My site is not yet production yet but has been operational for about 1 year. I have created many dummy members, and groups. A few months ago, I changed the “members” and “groups” slug to more appropriately reflect the site’s intent per instructions in the Codex. The redirects work fine… or so I thought. All member and group activity created prior to the slug name change redirect to a 404 page when any of them are selected. So, the “hardcoding” you mentioned above applies in this case as well?