Notice: Undefined property: stdClass::$timestamp in _drupal_session_write() [#1410130]

This notice appears when logging in via HTTPS. The fix for this issue is part of #1050746: HTTPS sessions not working in all cases which has unfortunately stalled.

Here is a patch for Drupal 7 that fixes the notice until #1050746: HTTPS sessions not working in all cases is committed. Useful for sites that are not interested in HTTP/HTTPS mixed mode, but still encounter this issue.

Comment	File	Size	Author
	write-session-notice.patch	725 bytes	klausi

Support from Acquia helps fund testing for Drupal Acquia logo

Comments

Comment #1

seanburlington CreditAttribution: seanburlington commented 24 February 2012 at 10:27

Status:

Active

» Needs work

It looks to me like this patch just suppresses the warning

But the $user->timestamp value is not set and as well as any other issues this degrades performance - by failing to restrict saves to the session table as the comment indicates should happen

I think that applying the patch individually to avoid clogging logs may be OK but I wouldn't want this patch in core - the underlying problem needs to be resolved.

Comment #2

james.williams CreditAttribution: james.williams commented 5 March 2012 at 12:13

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.
To be honest, whether there is an underlying issue or not, I think it is correct to add a check for $user->timestamp, since if this function is abstracted away from the rest of core, it shouldn't matter if the timestamp is not set - the session should always get updated if this is the case whatever the reason, and a PHP notice is unnecessary.
Wherever the underlying cause is though, that probably does also need identifying and a perhaps a more descriptive notice/warning thrown up there.

For reference, this issue is also being covered here: #1078614: Notice: Undefined property: stdClass::$timestamp in _drupal_session_write(). One of these issues should be marked as a duplicate.