[buddypress-trac] [BuddyPress Trac] #5332: Run the URI catching methods when root profiles are enabled

[buddypress-trac]

#5332: Run the URI catching methods when root profiles are enabled
--------------------------+------------------------------
 Reporter:  stevenkword   |       Owner:
     Type:  defect (bug)  |      Status:  new
 Priority:  normal        |   Milestone:  Awaiting Review
Component:  Core          |     Version:  1.9.1
 Severity:  normal        |  Resolution:
 Keywords:  needs-patch   |
--------------------------+------------------------------

Comment (by imath):

 Replying to [comment:8 stevenkword]:
 > Thank you for taking the time to look at this issue.  Having root
 profiles enabled for subfolders is highly desirable, so I'm in favor of
 the 2nd option.
 So am I, after investigating more, WordPress is already checking for
 existing usernames so unlike what i've said, there's no chance my fear
 would happen.
 > I am hoping for an additional BP global (something like
 `BP_FORCE_USER_BLOGS`) that would remove the registration options for
 creating a new blog, and automatically create a single blog for every user
 account with the username as the blog slug.  If such an option were
 available, it would prevent the problem you've mentioned where I could
 register a site without another user's username.
 I guess this should be formulated as an enhancement in a new ticket. But
 this won't be possible for the config you are using (root profile) as the
 problem is site.url/username == site.url/blogslug.

 > I was also thinking the other day about doing a check during the blog
 registration that would prevent the creation of blogs with slugs that
 match the usernames of other users.  This would be a filter on the
 "banned" words list.  However, I am not sure if this would scale well.
 It's not needed as WordPress is already doing this check.

 I've found a way to prevent the trouble by adding the signup username to
 illegal names in case of subfolder install. I'll check if the trouble was
 there in 1.8. But i  wonder if this problem should be managed directly by
 WordPress...

--
Ticket URL: <https://buddypress.trac.wordpress.org/ticket/5332#comment:9>
BuddyPress Trac <http://buddypress.org/>
BuddyPress Trac