Default user profile tab and duplicate content

[henrywright]

When the default user profile tab is changed from activity to profile, both members/username/ and members/username/profile will lead to the exact same content. Could this be seen as duplicate content by search engines? Imagine a website which has 1000s of members and makes use of many xprofile fields.

[henrywright]

Apologies, should have written: members/username/profile/public

[boonebgorges]

Can you be more specific what you mean by "will lead to the exact same content"? By design, when you've set the default tab to 'profile', visiting members/username/profile/public should result in a 301 redirect to members/username/. See #1741 and the bp_redirect_canonical() logic.

If it's not happening this way, and members/username/profile/public is resolving, then there's a bug. If that's the case, can you share more details about your setup? How have you changed the profile tab, etc, exactly what behavior you're seeing, etc.

[henrywright]

Will lead to the exact same content could have been written better as both links will take the user to the exact same content. In fact, when using define( 'BP_DEFAULT_COMPONENT', 'profile' ); all of the following URLs resolve: members/username, members/username/profile and members/username/profile/public

Is this expected behaviour?

Further to that and perhaps nothing to do with changing the default component, I noticed on buddypress.org both of the following take the user to same content. There seems to be no rolling up (as Nacin puts it) taking place

http://buddypress.org/community/members/henrywright-1/profile/
http://buddypress.org/community/members/henrywright-1/profile/public

[boonebgorges]

Oy. Thanks for the additional details, henrywright.

It looks like BP's canonical redirects have been broken since r6285, when the redirecting function was unhooked from WP. I'm assuming this was done by accident, but I'd like confirmation from johnjamesjacoby before reintroducing. Patch attached.

[johnjamesjacoby]

Replying to boonebgorges:

Oy. Thanks for the additional details, henrywright.

It looks like BP's canonical redirects have been broken since r6285, when the redirecting function was unhooked from WP. I'm assuming this was done by accident, but I'd like confirmation from johnjamesjacoby before reintroducing. Patch attached.

This was not removed on purpose, and I don't remember the circumstance that led me to remove it in the first place. Because of this, I'd advise testing Theme Compatibility & Canonical Redirects together to make sure they're working as intended with this patch attached.

[boonebgorges]

In 7380:

Reinstates bp_redirect_canonical functionality

This was mistakenly removed when introducing theme compatibility.

Fixes #5171

[boonebgorges]

In 7381:

Reinstates bp_redirect_canonical functionality

This was mistakenly removed when introducing theme compatibility.

Fixes #5171

[johnjamesjacoby]

Milestone 1.8.2 deleted