WordPress.org

Make WordPress Core

Opened 5 years ago

Closed 5 years ago

#11271 closed defect (bug) (fixed)

User Edit page only displays info for current logged in user

Reported by: cnorris23 Owned by: westi
Milestone: 2.9 Priority: high
Severity: blocker Version: 2.9
Component: Users Keywords: has-patch
Focuses: Cc:

Description

As of revision 12267 [Standardize on user_id instead of user_ID when passing comment data.] and later, when you visit go to edit the profile (through user-edit.php) of anyone other than the username you are logged in as, the data that is displayed is the data of the user you are currently logged in as. No matter what user you are trying to edit, the $user object and $user_id both display as the current logged in user. i.e. - If you are logged in as user #3, and you have the edit_user cap, all that is ever displayed in the user profile screens (through profile.php or user-edit.php) is the data of user #3. As of revision 12266 and earlier, this issue is not present.

Attachments (2)

11271-setup_userdata.patch (1.3 KB) - added by nacin 5 years ago.
11271.diff (4.7 KB) - added by westi 5 years ago.
Change the user editor to use it's own global variable with a more unique name

Download all attachments as: .zip

Change History (13)

nacin5 years ago

comment:1 nacin5 years ago

  • Keywords has-patch added
  • Severity changed from critical to blocker

Confirming that it is a blocker.

With [12267], setup_userdata now sets up $user_id (in addition to $user_ID, as it had before) as the current user. wp_reset_vars in user_edit.php then won't set $user_id to the query var because it is set already.

From what I know, user_ID is used globally as the logged in user, as user_id is used to talk about other users.

Patch reverts changes to setup_userdata made in [12267]. That should should fix it.

comment:2 westi5 years ago

  • Owner set to westi
  • Status changed from new to accepted

comment:3 cnorris235 years ago

I've tested, and we're back in business. Thanks nacin.

comment:4 westi5 years ago

(In [12288]) Restore functionality of setup_userdata() when a user id is supplied. See #11271 and #11222.

comment:5 follow-up: westi5 years ago

The patch above breaks the new functionality introduced by [12267].

I have made a new patch - not going to commit yet as I wonder if this will break any plugins so want some more test/review first.

westi5 years ago

Change the user editor to use it's own global variable with a more unique name

comment:6 westi5 years ago

In my testing that works.. going to check what plugins do with this now.

comment:7 westi5 years ago

Tested attached patch with:

My sample code should not use the global $user_id though it should take the value supplied to the actions and once that is done it works fine.

I guess this change should be safe to make.

comment:8 in reply to: ↑ 5 nacin5 years ago

Replying to westi:

The patch above breaks the new functionality introduced by [12267].

Hrm, I thought I had tested. Perhaps I did after I already reverted to the head revision. (oops.)

With so many global variables, I'm not sure there's a golden solution here. Something will break. It looks like localizing the damage to just user-edit.php is the best route. (Unless there's a better way to fix #11222.)

comment:9 azaozz5 years ago

Think we should leave this for 3.0. We may need both user IDs, the currently logged in user and another user, not only on the Edit User screen and resetting or changing the global $user_id that was used for this until now would likely affect some plugins.

We could also explore setting the currently logged in user's ID as a constant to avoid similar situations in the future and perhaps increase security a bit.

comment:10 ryan5 years ago

(In [12300]) Accept either user_id or user_ID. Remove user_id global. see #11271 #11222

comment:11 azaozz5 years ago

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

[12300] seems to fix it nicely.

Note: See TracTickets for help on using tickets.