Skip to:
Content

BuddyPress.org

Opened 7 years ago

Closed 7 years ago

Last modified 7 years ago

#5764 closed defect (bug) (fixed)

Incorrect way of setting the displayed user "fullname" in bp-members-loader.php

Reported by: imath Owned by: djpaul
Milestone: 2.1 Priority: high
Severity: normal Version:
Component: Members Keywords:
Cc:

Description

In r8610, commit message is saying :

In bp-members, use only WP core data to set up the loggedin_user and displayed_user global objects. Previously, these objects were configured by referenced to xprofile, which required that xprofile be loaded before members. Now, users' display names are first loaded from wp_users, and are overridden by the xprofile

The problem is, since this commit, the $bp->displayed_user->fullname is never set causing various troubles in single member <title> html tag, in the post_title of the single member, in the title of the friends widget.. Actually, anywhere the bp_get_displayed_user_fullname() function is used.

It's never set because the "fullname" attribute is not a wp_users field and bp_core_get_core_userdata() is only getting wp_users fields. Using WP Core get_userdata() wouldn't get the "fullname" neither as it's not one of the user_meta returned by WordPress.

I suggest to use the display_name attribute instead to avoid these troubles.

Attachments (1)

5764.patch (814 bytes) - added by imath 7 years ago.

Download all attachments as: .zip

Change History (5)

@imath
7 years ago

#1 @djpaul
7 years ago

  • Owner set to djpaul
  • Resolution set to fixed
  • Status changed from new to closed

In 8660:

Members: set the displayed user's fullname to their display name

This was broken in r8610 because it was trying to access a property in the WP_User object that doesn't exist.

Fixes #5764, props imath

#2 @DJPaul
7 years ago

  • Keywords has-patch 2nd-opinion removed
  • Resolution fixed deleted
  • Status changed from closed to reopened

This has caused the tests to fail when running against WordPress core trunk (on travis; it seems to work OK when tested locally).

https://travis-ci.org/buddypress/BuddyPress/builds/30577776

#3 @boonebgorges
7 years ago

  • Resolution set to fixed
  • Status changed from reopened to closed

The timing here was coincidentaly. It's not r8660 that was causing the failures, it was an upstream change (https://core.trac.wordpress.org/changeset/29267) that was causing the loggedin_user not to be reinitiated between tests. The upstream change has been reverted (https://core.trac.wordpress.org/changeset/29274). See https://core.trac.wordpress.org/ticket/28986 for more discussion.

Our builds are now passing: https://travis-ci.org/buddypress/BuddyPress/builds

#4 @DJPaul
7 years ago

Nice, thanks

Note: See TracTickets for help on using tickets.