[D7] Undefined property: stdClass::$nid in node_tokens()

This is an interesting one as from my understanding we shouldn't get to node_tokens if the node does not yet exist. Could this be caused from imported content or updated node data which somehow loses it's nid :S?

I have the same notifications when creating nodes via migrate module.

Have we had any further info about what change triggered this to start happening?

If anyone else experiences this problem then please provide steps to reproduce the error on a clean install of Drupal 7. If you can't, then enable contributed modules until the problem occurs.

It sounds like this is a problem with a contrib module that is using the function incorrectly. I suppose node_tokens() could handle this problem by checking for the nid as in #1, but I think that would just serve to mask bugs with other modules.

I have also such an issue. In my case it comes from the following configuration. (Not testet on a clean enviroment)

1. Content type FOO with Automatic Entity Label and using "FOO [node:nid]" as token.
2. Rule which creates a content of type FOO. In Rules we have to set a temporary title because the field is required. I use "FOO [random:number]".
3. I also use the "Force saving immediately" option in Rules but this does not change anything.
4. Every time the rule creates such a content i get the error, so it seams that when Automatic Entity Label tries to use [node:nid] it does not exist. If i use a other token it works.

Ok i have debuged this a little bit. The problem is that the rules create new entity action triggers Automatic Entity Label. But this early created entity has no id at this time. When i do the Save entity action with the force methode, it will again trigger the Automatic Entity Label, but now the entity has an id.
This is the reason why the token works but the error will be triggerd. Because the first run it triggers the error and on the second run the title could be created.
I have found this because i have used the following PHP instead of the Token:

<?php
dpm($entity);
?>

which returns two objects. The short entity object and the full entity object.

This happening when [node:field_name][node:nid] is used as default value for other textfield using https://www.drupal.org/project/field_default_token. When only [node:field_name] is used, then warning is not showing.

I can confirm this. We use [node:nid] as default.
This only happens on the first save.

We also use module https://www.drupal.org/project/auto_entitylabel

That has/had a similar issue : https://www.drupal.org/node/1445124
They solve this by automatically re-saving the entity after creating new content.
This makes the token substitution being passed twice, the second time the node exists and has a valid node id, or all available tokens for that matter.

You still get the notice warning, but the functionality works.

Same problem here when using https://www.drupal.org/project/auto_entitylabel. So in our specific case this seems to be a duplicate of: #1445124: Add support for entity id tokens during creation

Hm, after all, the patch from #1 is simple enough to let it in, doesn't it?

Or are there any performance concerns? I actually don't think so, because this routine is only running when node content gets altered or created. +1 for this simple additional if check from here. Especially because it can solve/prevent many of such little issues/scenarios.

While I don't care enough about "Undefinded" Notice messages to risk altering core code for that in a risky way, it still feels uncomplicated here to do that and "cleaner" not to have this Notices. So maybe some more "Needs review" ?

Hi there,
I've got the same problem importing content type fields. I deleted them in order to get rid of those warnings but they are never gone.

Is there any clean way to fix it?

Notice: Undefined offset: 1 in drupal_settings_initialize() (line 774 of /var/www/mysite/includes/bootstrap.inc).
Notice: Undefined property: stdClass::$nid in node_tokens() (line 112 of /var/www/mysite/modules/node/node.tokens.inc).
Notice: Array to string conversion in views_bulk_operations_modify_action() (line 31 of /var/www/mysite/sites/all/modules/contrib/views_bulk_operations/actions/modify.action.inc).
Notice: Undefined index: entity_type in views_bulk_operations_modify_action() (line 32 of /var/www/mysite/sites/all/modules/contrib/views_bulk_operations/actions/modify.action.inc).
Notice: Undefined index: entity keys in entity_extract_ids() (line 7874 of /var/www/mysite/includes/common.inc).
Notice: Undefined index: entity keys in entity_extract_ids() (line 7875 of /var/www/mysite/includes/common.inc).

The fix from #1 is insufficient, because $data['node'] can exist before the node exists.

e.g. When attempting to create a new node, but validation fails, $data['node'] is at:

array(
  'uid' => 'my_user_id',
  'name' => 'my_user',
  'type' => 'my_content_type',
  'language ' => 'und'
)

However the fix from OP, i.e. !empty($data['node']->nid) works fine.

This is essentially the D7 backport, as mentioned in #14 isset() isn't sufficient and we should use !empty() as done in #2685963: Undefined property: stdClass::$nid in node_tokens().

@MustangGB I am not sure about that approach either. Do we really want to skip all node tokens if NID is not present? It can easily happen while creating a new node programtically, because you do not need to fill NID there. It will be handled automatically:

function node_save($node)

// Determine if we will be inserting a new node.
if (!isset($node->is_new)) {
  $node->is_new = empty($node->nid);
}

I think the better approach will be just sanitize the NID token (if the NID is not present), not remove all tokens in this case (something similar is used in user_tokens()).

Also in the parent issue there was a suggestion that tests should be added, so updating the tags.

Uploading the patch with a different approach which only handles the problem with node:nid (and also node:url and node:edit-url) tokens. Also adding a test. Please test if this approach will work.

The test reproduces the original issue and proves the fix.

+1 thanks!

Thank everyone who contributed!

Added also credits from the parent issue.