Running dpm on global $user object logs the user in as user 1.

This happened on a recent project with us as well. When running dpm on any user object the user came back with a uid = 1.
If we cast the user object as an array uid didn't get set as 1.
If we get the global $user object and then clone the $user object the new cloned object has a uid of 1 if we dpm it.

If you dpm the global $user object, it sets the uid to 1 and you are logged in as user 1.

We are still working on why this might be causing this. This isn't happening on live and the only other change was an update to Drupal core.

One more, visiting the /user/uid/devel path causes the same thing to happen.

While I don't have time to check right now, your issues may be related to a very annoying krumo bug.

The krumong module was made to fix that (among other things) - https://www.drupal.org/project/krumong

Hey folks,

I got this critical error as well, so I explain the strange behaviour that occurs:

When I use the PHP-Form under /devel/php and enter

global $user;
dpm($user->uid);

it outputs the correct integer of the current user id.
If I want to output the user-object

global $user;
dpm($user);

the user gets always changed to the admin account (uid = 1).

When I use

dpm($node);

for example in hook_preprocess_node() the output shows always $node->uid == 1. But if I use

dpm($node->uid)

I get the correct user id.

This error is very critical and a security issue because every user can become administrator.

I'm marking this as a dupe of #1855468: Krumo side effect: Object vars become references so we can have the discussion in one place

Not sure how much of a security hazard this is, you should NOT have dpm() calls in the wild.

I don't think these are related. I can reproduce this with

$node = node_load(8);
dpm($node->uid);
dpm($node);
dpm($node->uid);

in the Execute PHP block under PHP 5.5.15 — it seems to be a PHP misbehavior under doubtful circumstances.

Here's a fix for this one.

Hmm, bash broke my comment. Was supposed to be

Running dpm()/krumo() on $obj changes $obj->user to 1.

Hi everyone.
I have Drupal 7.36 and Devel 7.x-1.5.
My user name has administrator rights.
And if i do

var_dump($user->uid); // i see my uid is correct
dpm($user); // i see uid == 1 ! Not correct
var_dump($user->uid); //ofcource it is == 1

going to /user make all my user info of admin account

Devel permissions are allowed only to Administrator. It is not about anon user

Other tested func

this is also true for kpr()
particularly dargs()
not true (working correctly) for dvm(), dpr(), dvr()

Hello nop1984,

Have you tried testing this against the dev branch of devel? While this was committed, I do not think it is in 1.5. The 1.5 release is over a year old and this was just committed 8 months ago.

Hi, frob. No i didnot. Wasted more than 5 hours checking all while i understood that is just about dpm().
Now working with client in hurry, no time for experiments.

Always use the -dev version of Devel, and always update to the latest when you think that something is not working right.

@nop1984,

One more thing. It is best to never run dpm in production code.

I don't think this is fixed. I am having exactly this problem with my dev environment. When I do something like:

var_dump($myobject->uid); // i see my uid is correct
dpm($myobject); // i see uid == 1 ! Not correct
var_dump($myobject->uid); //it is now == 1

This is very difficult to work with.

I've tried it with both 7.x-1.x.dev and 7.x-1.5 both with the same problem.

The version of PHP in my dev environment is PHP/5.5.18

Much time has been wasted trying to figure out why variables are not being set correctly only to determine that it was the debugging that was causing the problem.

If anyone has any ideas how to fix this problem I would appreciate it. In the meantime I have to switch to using dvm() as that does not seem to have the problem.

I have Drupal 7.44 and Devel 7.x-1.5.and i am facing same type issues.

There needs to be a new stable release. Right now dev is what has the fix. @amit.drupal notice the release date for 1.5, it was released in 2014 The latest dev is from 2016 and the code that fixed this was committed in 2015. This is fixed in dev.

Everyone please stop reopening old issues. If you have a problem create a new issue and reference the old one.