Run the URI catching methods when root profiles are enabled

[stevenkword]

Currently, if you setup a BuddyPress multisite instance with BP_ENABLE_ROOT_PROFILES defined as true, conditionals found early in the method bp_core_set_uri_globals() will cause the URI routing to bail for non root blogs.

Here are the steps to replicate the problem.

1. Fresh multisite BP instance running 'twentytwelve' and subfolders. Root profiles should be enabled.
2. Register a non-super-admin user account and make make sure to check the box requesting a blog as well as an account. ( If you just ask for an account, there is no problem )
3. Navigate to where this new user profile should now exists. e.g.) ​http://example.com/username/.

Following these steps will serve the user's blog front page rather than their profile. Both the primary super-admin account and non-blog-owning users are not affected by this problem.

[stevenkword]

The attached patch aims to resolve this problem by allowing the URI catching code to run whenever root profiles are enabled.

[stevenkword]

UPDATE: This applies to subfolder installs and not subdomain installs.

[boonebgorges]

*groan* I wrote a long comment here yesterday, but I guess I didn't post it correctly. Let's try again...

I'm guessing that the core issue here isn't really a problem with root profiles, but with the way that the BP_ROOT_BLOG is (or is not) set. Looking at the line you've patched, it looks like bp_is_root_blog() ought to return true, and your extra conditional should not be required. This suggests to me that this is a config problem, or maybe a larger problem with the way we auto-sniff the root blog.

A couple questions:

• Is BP network activated, or activated just on a single site in your installation?
• I assume from what you say above that you're testing on a blog other than blog_id = 1. Eg, example.com/foo rather than example.com.
• Have you done any custom definition of BP_ROOT_BLOG, ie in wp-config.php or bp-custom.php?

[stevenkword]

Hi Boone,

I do not explicitly define BP_ROOT_BLOG in my wp-config. However, I do know that my root blog is blog id 1. Here are the relevant bits of my wp-config.php.

/* Multisite */
//define( 'WP_ALLOW_MULTISITE', true );

define('MULTISITE', true);
define('SUBDOMAIN_INSTALL', false);
define('DOMAIN_CURRENT_SITE', 'example.com');
define('PATH_CURRENT_SITE', '/');
define('SITE_ID_CURRENT_SITE', 1);
define('BLOG_ID_CURRENT_SITE', 1);

define('BP_ENABLE_ROOT_PROFILES', true);
define('BP_DEFAULT_COMPONENT', 'profile');

/* That's all, stop editing! Happy blogging. */

• BP is network activated, but BP_ENABLE_MULTIBLOG is false.
• When you network activate BP, each user has the ability to create a blog upon registration. What is happening for users that create a blog, opposed to those who are creating an account, is that the front-page standard loops takes priority over the default member component.
• BP_ROOT_BLOG is not defined.

I have noticed that for each of the blogs created by news users, their profile appears in the theme setup by that user and not the theme of the root blog. This leads me to believe that non-admin user profiles ( e.g. example.com/stevenkword/ ) are not considered to be in the root blog. Only the owner of the root blog and users without blogs have profiles being displayed with root blog's theme.

[imath]

Replying to stevenkword:
Hi @stevenkword, Boone,
I've managed to reproduce. And actually, bug is a little bit more complex than it seems to be.

1/ This only happens if multisite config is set to subfolders, BP_ENABLE_ROOT_PROFILES is set to true and the username === blog slug.

In this very particular case as site.url/slug is the same url for user's profile and user's blog then we have this trouble.

I need to investigate further, but i strongly think that it could be the case with each member's username. For instance if i choose a blog slug different from my username but the same than another username, then there's a strong chance that the corresponding user will allways see my blog instead of his profile !

2/ This also causes a notice error with WP_Query::get_queried_object() as in bp_core_load_template() the members page id is not affected to $object_id around line 357.

From my point of view and only for this particular case (multisite subfolders/root profile):
here are the options :
1/ the simpliest : if multisite is set to subfolders, then neutralize the effect of BP_ENABLE_ROOT_PROFILES to avoid any problems. It means, root profile will only be available for subdomains multisite.
2/ Treat usernames as forbidden blog slugs but requesting all usernames while registering a new blog may be a heavy process !

Thanks for the patch @stevenkword, but i think it's not a good solution as it actually loads the user's profile inside user's blog but completely breaks user's blog as for instance trying to reach the "hello world" post brings you to a 404.

I'm working on it and will suggest an alternative patch tonight.

[stevenkword]

@imath,

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.

This also loosely relates to an issue I'v submitted to Jetpack concerning Single Sign On. ​https://github.com/Automattic/jetpack/issues/71

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 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.

Let'e me know if I can do anything to help.

[imath]

Replying to 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...

[imath]

Good evening,

I've checked, this situation already exists in 1.8.1 and i think WordPress is allowing on purpose signup user to have a blog name similar to his username. The check WordPress is doing about other usernames seems to be there to "book" blog names and avoid "username a" to create a blog with "username b".

So the issue only exists on multisite configs with a subdirectory setting and when BP_ENABLE_ROOT_PROFILES is set to true. I think the best way to handle it is to prevent a user to signup a blog using his username as the blog name, in this particular case only. This way : users can still create blogs and we "maximize" the fact that site.url/username != site.url/blogname

So i suggest the diff "5332-illegal-names" which is adding a filter to subdirectory_reserved_names to include signup username on register page and to check for a username similar to blog name in network admin screen.

I think this can be fixed in 2.0 as it's not a regression from 1.9.

[stevenkword]

Hi imath,

I understand the proposed solution, but unfortunately it doesn't satisfy the reported problem. The goal is to do exactly the opposite. I'd like to create blogname/username pairs, where every user gets one single "blog" with their username.

We should provide this functionality with subdomains as it is a common structure used for niche communities. If you think about GitHub for example, the username is also the home slug for that user. (e.g. ​https://github.com/stevenkword/ ). This sort of structure would be beneficial for multisite networks that don't use the "blog" as it's primary feature/component.

I'd like to make an argument for keeping and supporting username/blogname pairs. Can we continue to think on this a little bit and see if we can find a way to accomplish this? I think it is important.

[boonebgorges]

I'd like to create blogname/username pairs, where every user gets one single "blog" with their username.

This is at odds with the use of root profiles, for the simple reason of URL clashes. With root profiles *disabled*, a user 'boone' can have the following URLs:

profile: ​http://example.com/members/boone
blog: ​http://example.com/boone

With root profiles, the URL becomes ​http://example.com/boone. So I can't also have a blog at the same URL.

Or maybe I'm misunderstanding what you're trying to do, stevenkword?

[imath]

Replying to stevenkword:

@Boone is right. The fix i've attached avoids the "clash" when root profiles is enable.

@stevenkword
You cannot have 2 different things at the same url, this is not possible. I'm afraid you'll have to choose between root profiles and username = blogname (or you can still use subdomains multisite config)
But, in my opinion, your ticket is important (thanks a lot) as it revealed a bug for a particular configuration and the patch only applies when :

• multisite is set to subdirectories
• root profiles is on
• Signup user tried to create a blog with his username

[stevenkword]

It looks like I may have left out the single most important detail! I am trying to leverage BuddyPress components for an application service I am building. However, I have no interest in the native blog functionality that comes with WordPress. So I am looking at this from the perspective of using BP as more of a framework. Since I am not using the native WordPress blog "front-page", this collision is of no concern. The behavior would be similar to setting the homepage to a static page rather than the most recents posts.

What I am looking for is a way to define this intention via a global variable. The standard blog functionality would still work aside from the front-page. I am proposing that we add a global variable, BP_ROOT_PROFILE_DEFAULT , that states whether the root profiles should be set to 'blog' or 'bp_default_component'.

[boonebgorges]

So, if I understand correctly, you want the following:

• ​http://example.com/boone will point to my BuddyPress profile
• ​http://example.com/2014/01/foo will point toward a WP blog post called "foo"
• ​http://example.com/boone/friends and other BP profile slugs will continue to load inside of BuddyPress

Is that right?

I can see the value of this sort of thing, but it's very much a niche setup. Supporting it natively in BP would be complicated. We'd have to hook into WP before it decides which blog is supposed to load. Not to mention that there will be inevitable issues with URL conflicts.

I think it'd be possible to rig this up in a plugin, and I'd be happy for BuddyPress have the right tools to make it possible (like hooks in the right place). It might be something that is best saved for when we've migrated to real WP rewrite rules.

[stevenkword]

Boone,

Close. With my setup, WP is insisting on prefixing the root blog slugs with 'blog'.

• ​​http://example.com/boone will point to your BuddyPress profile
• ​http://example.com/boone/friends and other BP profile slugs will continue to load inside of BuddyPress
• ​http://example.com/boone/2014/01/09/hello-world/ will point toward a WP secondary BLOG post called "hello-world"
• ​http://example.com/blog/2014/01/09/hello-world/ will point toward a WP ROOT BLOG post called "hello-world"

I am okay with this not being a core feature. Please let me know what I can do to help get the necessary hooks into BP.

[boonebgorges]

​​http://example.com/boone/2014/01/09/hello-world/ will point toward a WP secondary BLOG post called "hello-world"

Yup, that's what I meant :) This confirms that your use case is very edge case.

Please let me know what I can do to help get the necessary hooks into BP.

Well, I don't really know off the top of my head what those hooks would be. I guess my suggestion is to start building a plugin that does what you're suggesting, and see where it leads you. You'll probably need a custom sunrise.php file (which is loaded in time for you to do custom logic to set $current_blog - see ​https://core.trac.wordpress.org/browser/tags/3.8/src/wp-includes/ms-settings.php#L17). You'll have to toy with various ways of deciding which blog should be loaded at this point (a regex for bloggish paths like /2014/01/ might work?)

If you run into a place where BuddyPress in particular is getting in your way, please feel free to offer a suggestion.

Let's leave this ticket open to consider imath's ​https://buddypress.trac.wordpress.org/attachment/ticket/5332/5332-illegal-names.diff. At a glance, this looks like a good solution to problem of username/blogname clashes when running root profiles.

[DJPaul]

Would be nice to get imath's last patch refreshed and some small code style improvements (brackets, etc) so we can put this into 2.1.

[imath]

Patch refreshed ;)

[DJPaul]

Looks great

[imath]

In 8684:

Avoid a conflict between member's profile url and member's blog url

When root profiles are enabled on a subdirectory multisite config, we need to make sure the member's profile url is different than the member's blog url. To do so the username needs to be an illegal blog name on this particular config.

fixes #5332