Notice: Undefined property: stdClass::$timestamp in _drupal_session_write()

Does your code do something like this?

global $user;
$user = user_load($user->uid);

If so, you are loading a plain user (i.e. account) object as the global $user which is mixing apples and oranges even if the uid is the same. The global $user object has session information. The plain user entity object is just a database select of a user, which you might need to load into a new variable in order to get Field API fields, etc. for the current user. However, if you overwrite the global $user object, you will erroneously remove session information, giving you that error. Simple design solution though, try this instead:

global $user;
$current_user = user_load($user->uid);

Take a look at http://api.drupal.org/api/drupal/modules--user--user.module/function/use... for specifics.

I'm still getting this error in the db on many logins, and all I'm doing is calling global $user; in my own login form submit callback...

/**
 * Login form - submit callback.
 */
function custom_user_login_submit($form, &$form_state) {
  // Redirect user to profile after login.
  global $user;
  $form_state['redirect'] = 'user/' . $user->uid;
}

I can't tell if anything else could be causing this, though... it's just annoying that my logs include a $timestamp error every time a user logs in.

Does the error persist when you comment out everything in your custom submit callback function?

I'll continue looking into the problem.

I removed that hook entirely, and flushed all caches, and I'm still getting the error. Funny thing, though - I don't seem to get the error on my local MAMP environment, but the live server is showing the error. I have the databases synced via drush sql-sync, and the data structure is all the same.

Maybe a PHP version discrepancy or something strange going on?

subscribe

sub, same issue

I'm getting Notice: Undefined property: stdClass::$timestamp in _drupal_session_write() (line 175 when adding an Article. I am not even looking at the user object.

7.10
PHP 5.2.11
MySql 5.5.8-log

same here - Notice: Undefined property: stdClass::$timestamp in _drupal_session_write() (line 175 of....

This notice message is freaking me out !

I'm seeing this same error in the 7.x branch when users login. This is definitely a bug in session.inc. The simple fix seems to be a check to make sure that $user->timestamp is set before attempting to use it. Here's a 7.x patch that eliminates the login-related error on my site. It's a one-line change that should also work with the 8.x version of session.inc.

tested - patch is working for D7.12

I have the same problem in my logs. Patch looks good.

Patch re-roll with Unix-style line endings...

The patch is failing testing because of a directory name problem caused by my ignorance of how the patch file system should be set up. If someone with more experience in patch development can fix it, please do.

I checked out drupal core with git, then made the change in session.inc, and cd'ed to the drupal root directory (the directory with the core directory in it), then said 'git diff > patch-name-here-[issue]-[comment].patch. This should work for any core patch. Of course, YMMV on Windows...

Issue #1410130: Notice: Undefined property: stdClass::$timestamp in _drupal_session_write() is a duplicate of this one, but some useful discussion about this patch was there.

seanburlington argued that the underlying problem should be resolved and not just hidden by suppressing the warning.

For me, this patch is good since this warning is unnecessary, but the underlying problem should also be identified & perhaps a more relevant/helpful warning thrown instead.

So, when should $user->timestamp be set? It looks to come from the $_SESSION rather than the original account object but I don't fully understand how that gets merged into the user object.

global $user;
$user = user_load($user->uid);

This was my error, I assumed the global $user was the user_load() return.

This fixed for me:

global $user;
$user = (object)array_merge((array)$user, (array)user_load($user->uid));

This preserves everything in the global $user object, whilst appending into it the extra details I wanted to add, requiring the user_load().

Seems like this issue may be a duplicate now as this issue got fixed as part of #1050746: HTTPS sessions not working in all cases I think?

Confirmed that #1050746 fixed this bit.