Remove "Profile" from Member page title

[sooskriszta]

The title tag of member profile page says Name's profile.

The ";s profile" seems extraneous. Perhaps we can say, quite simply, Name.

[DJPaul]

I am not sure which page you are referring to and cannot easily find one that does this on my local install. Can you share a sample link, please?

[sooskriszta]

http://buddypress.org/members/djpaul/

Paul Gibbs . Activity Streams . BuddyPress.org

http://buddypress.org/members/djpaul/profile/

Paul Gibbs . Extended Profiles . BuddyPress.org

I am talking about the title tag,

<title></title>

While for site developers and admins, or "extended profile" has a meaning, I feel that it does not add value and deteriorates the experience by adding noise.

The title of http://buddypress.org/members/djpaul/ should be simply

Paul Gibbs - BuddyPress.org

I don't think
http://buddypress.org/members/djpaul/profile/
http://buddypress.org/members/djpaul/activity/
http://buddypress.org/members/djpaul/forums/
should have titles different from the title for http://buddypress.org/members/djpaul/

But if they have to be, then we should consider changing them to:
http://buddypress.org/members/djpaul/profile/

Paul Gibbs - Profile - BuddyPress.org

http://buddypress.org/members/djpaul/activity/

Paul Gibbs - Activity - BuddyPress.org

http://buddypress.org/members/djpaul/forums/

Paul Gibbs - Forum Posts - BuddyPress.org

In fact, semantically, it's hard to explain why forum posts are now "activities", and how is it that other people's actions (e.g. calls) are posted on the Activities page for DJPaul. Perhaps we should consider renaming the "Activity" page. But I suppose that's for another ticket.

P.S. If you agree that this ticket is something we want, then I am happy to add a patch - seems pretty trivial.

[boonebgorges]

+1 to these changes. sooskrizta, I'm not sure how trivial the changes will be (I think there's some funkiness in the way these page titles are built) but please do feel free to have a go at a patch.

[sooskriszta]

I am sure I am missing something, but here goes

[sooskriszta]

I am pretty sure I am missing something crucial in the patch. Would appreciate feedback.

[DJPaul]

There is so much bad code in bp_modify_page_title it is making my brain hurt.

[djpaul]

In 9103:

Core: Page title: use correct i18n function when generating member page titles.

See #5838

[djpaul]

In 9104:

Core: Page title: code standards improvements.

See #5838

[djpaul]

In 9105:

Core: Page title: remove component name from members component item pages. Additional screens introduced by other plugins have been similarily changes.

This simplifies the <title> for the member profile screens; the longer the title, the less likely it will fit in the narrow space afforded by modern web browsers. I expect most people will only have one tab open for a one member (for example); it's an edge case to have multiple tabs open on different parts of the same user's profile for most/general use.

See #5838, props sooskriszta for the initial patch.

[djpaul]

In 9106:

Core: Page title: don't hardcode the word separator for some of our page titles.

Fixes #5838

[r-a-y]

The problem with r9105 is we get the same duplicate title tag across all pages for a user.

I'm not a fan of SEO, but we definitely should not have duplicate title tags.

Was the intent of r9105 to only have the displayed user's name for the <title> tag on the landing page for a user (eg. /members/USERNAME/)? If so, this makes more sense to me.

[DJPaul]

No, the intent was:

I don't think 
http://buddypress.org/members/djpaul/profile/
http://buddypress.org/members/djpaul/activity/
http://buddypress.org/members/djpaul/forums/
should have titles different from the title for http://buddypress.org/members/djpaul/

we definitely should not have duplicate title tags.

Can you explain more?

[r-a-y]

Google doesn't recommend having duplicate title tags across different pages:
​https://support.google.com/webmasters/answer/80407

ray.patch does a couple of things:

• When on a user's landing page (eg. example.com/members/admin/), the page title will be admin | {SITE NAME}.

• Uses the BP nav name for the page title instead of the admin title used on the "Settings > BuddyPress > Components" page. For example, when on example.com/members/admin/activity/, the page title will be admin | Activity | {SITE NAME}.

• Added subnav title when on a member component sub-page. For example, when on example.com/members/admin/activity/mentions/, the page title will be admin | Activity | Mentions | {SITE NAME}.

This is similar to what sooskriszta proposed in the latter part of comment:2.

Let me know what you think.

[DJPaul]

• $span = strpos( $bp->bp_nav[$component_id]['name'], '<span' ); What items have a span? Is this to cover components with item counts in their names?
• I think the // translators comment needs to be directly above the line of code it refers to.
• The construction in Append action name if we're on a member component sub-page looks a bit dubious from a translation POV (e.g. in case you need to re-order the position of the seperator)`

[r-a-y]

Thanks for the feedback!

$span = strpos( $bp->bp_nav[$component_id]name?, '<span' ); What items have a span? Is this to cover components with item counts in their names?

Yup! You got it. The default BP components that add counts to the nav name are - Friends, Groups, Notifications, Messages. This isn't counting plugins. If the language file is using a different element, then the <span> search doesn't work. Could use regex or strip_tags and remove all numbers?

I think the translators comment needs to be directly above the line of code it refers to.

Thanks for that tidbit. This should be fixed in the updated patch.

The construction in Append action name if we're on a member component sub-page looks a bit dubious from a translation POV (e.g. in case you need to re-order the position of the seperator)

Right. The updated patch uses the sprintf() argument syntax used to construct the current page title, which I kinda hate, but I guess there's no other way.

Let me know what you think.

[DJPaul]

I have not tested this latest patch but I have spotted something I missed the first time I looked at it; I'm not 100% confident that ucwords is multi-byte safe. See ​https://stackoverflow.com/questions/4528119/best-function-for-title-capitlization for the best result I could find in Google. I think it'll be simpler just leaving the case as-is, unless you're familiar with any multibyte changes in order to test this.

[DJPaul]

To be clear, other than getting your opinion on the ucwords call, I think the patch looks good.

[r-a-y]

ucwords() was taken from the older title implementation. Just did a copypasta :)

But, you do have a legit point about ucwords() being utf-8-compatible.

In the current patch, I think if we change:

$component_name = $bp->{$component_id}->id;

to:

$component_name = ucwords( $bp->{$component_id}->id );

And remove the other ucwords() calls, we should be safe. It's very rare that the BP nav will not have a name attached to it.

[DJPaul]

Agree

[r-a-y]

In 9249:

Core: Make page title on member pages unique.

This commit partially reverts r9105, which made the <title> element the
same across all member pages, which goes against SEO conventions.

This commit does the following:

• When on a member's landing page (eg. example.com/members/admin/), the page title will be admin | {SITE NAME}.

• Uses the profile navigation name in the page title instead of the component's admin title. For example, when on example.com/members/admin/profile/, the page title will be 'admin | Profile | {SITE NAME}' instead of 'admin | Extended Profiles | {SITE NAME}'.

• Adds the profile subnav name in the page title when on a member component sub-page. For example, when on example.com/members/admin/activity/mentions/, the page title will be admin | Activity | Mentions | {SITE NAME}.

Fixes #5838.