Make WordPress Core

Opened 14 years ago

Closed 14 years ago

#11271 closed defect (bug) (fixed)

User Edit page only displays info for current logged in user

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


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 14 years ago.
11271.diff (4.7 KB) - added by westi 14 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)

#1 @nacin
14 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.

#2 @westi
14 years ago

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

#3 @cnorris23
14 years ago

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

#4 @westi
14 years ago

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

#5 follow-up: @westi
14 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.

14 years ago

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

#6 @westi
14 years ago

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

#7 @westi
14 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.

#8 in reply to: ↑ 5 @nacin
14 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.)

#9 @azaozz
14 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.

#10 @ryan
14 years ago

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

#11 @azaozz
14 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.