Skip to:
Content

BuddyPress.org

Opened 14 years ago

Closed 7 years ago

Last modified 3 years ago

#1426 closed defect (bug) (wontfix)

BP_ENABLE_ROOT_PROFILES conflicts with multisite subdirectory slugs

Reported by: xevo's profile xevo Owned by:
Milestone: Priority: major
Severity: normal Version:
Component: Core Keywords:
Cc: onetarek@…, alexander.berthelsen@…

Description

When you make a blog post/page with for example "register" as the permalink, it'll overwrite your buddypress's /register page.

Same thing when using BP_ENABLE_ROOT_PROFILES, if you use a blog name that is already used as a username account, when you go to the user account you get the blog with that name instead.

So the basic buddypress permalinks need to be unoverwriteable by page or blog posts and when using BP_ENABLE_ROOT_PROFILES, the blog name needs to be checked whether it already is being used by a username or the permalink needs to be changed (example: /admin/blog).

Change History (12)

#1 @DJPaul
14 years ago

The BP_ENABLE_ROOT_PROFILES thing would only affect subdirectory installs of WPMU.

#2 @johnjamesjacoby
14 years ago

  • Component set to Core
  • Milestone set to 1.3

There's no way to do slug collision detection at the moment. Probably should run everything through unique_slug at some point.

Moving to 1.3 for review.

#3 @johnjamesjacoby
14 years ago

  • Milestone changed from 1.3 to Future Release

Moving to future release, since this is unlikely to make it into 1.3. This starts off as a WordPress issue with permalink and slug collisions, so until WP handles this better, we're at a stand-still.

#4 @r-a-y
11 years ago

  • Keywords permalink removed
  • Severity set to normal
  • Summary changed from Permalinks get overwritten by others, on multiple places. to BP_ENABLE_ROOT_PROFILES conflicts with multisite subdirectory slugs

When you make a blog post/page with for example "register" as the permalink, it'll overwrite your buddypress's /register page.

Resolved in BP 1.5+ as we now use WP pages for this.

Same thing when using BP_ENABLE_ROOT_PROFILES, if you use a blog name that is already used as a username account, when you go to the user account you get the blog with that name instead.

I'm guessing this is still valid. Changing title of ticket to reflect this.

#5 @onetarek
10 years ago

  • Cc onetarek@… added

I wrote a solution for a similar problem that I am using in my plugins. http://onetarek.com/wordpress/wordpress-filter-hooks-on-creating-slug-check-availability-of-slug/
This solution should be included in wp core. At first WP should fix it then Buddypress.
So all of you should comment on this core ticket https://core.trac.wordpress.org/ticket/24776


#6 @lakrisgubben
8 years ago

This problem also exists on a single-site installation (tried with latest BP and WP). If you for example create a user with username "sample-page" you won't be able to access the page with the slug sample-page when BP_ENABLE_ROOT_PROFILES is set to TRUE.

Suppose there was a check that made sure there where no conflicts between usernames and subdirectory-sites or posts (of any type) if BP_ENABLE_ROOT_PROFILES was TRUE, what would happen if some site switched it off, or turned it on? Or should usernames always be checked for collisions against all post types (since changing the permalinks for posts to 'post_name' could create the problem as well)?

I think there should be a "warning" of sorts on the codex that this problem might happen when using BP_ENABLE_ROOT_PROFILES, so as if someone chooses to use this, they're at least aware of the problems that can come with it. Maybe something like:

"Warning! If you use BP_ENABLE_ROOT_PROFILES there might be a situation where some user profiles get the same url as some posts or pages rendering either of them inaccessible. This might also be true of sub-sites if you're running multisite with subdirectories. See ticket #1426"

The sections of the codex I've found that should reflect this are (I can't edit them):
https://codex.buddypress.org/getting-started/customizing/changing-internal-configuration-settings/
https://codex.buddypress.org/developer/filters-reference/

#7 @lakrisgubben
8 years ago

  • Cc alexander.berthelsen@… added

#8 @DJPaul
8 years ago

@mercime What do you think about if we document this (we can help @lakrisgubben get access) in the Codex only? I'm not convinced it needs an admin UI / note (yet -- we might do a special screen in future to consolidate this sort of note, and then it's harmless to add another one).

#9 @mercime
8 years ago

@djpaul +100 Sent invitation to @lakrisgubben to edit Codex pages.

#11 @mercime
8 years ago

@lakrisgubben Thank you for updating the codex pages so promptly!

@DJPaul close this ticket or keep open?

#12 @lakrisgubben
7 years ago

  • Milestone Future Release deleted
  • Resolution set to wontfix
  • Status changed from new to closed

closing this as wontfix since I don't see a feasible way of doing that. :) If someone disagrees let me know...

Note: See TracTickets for help on using tickets.