Undefined property: stdClass::$nid in calendar_get_node_link()

I am getting this "Notice: Undefined property: stdClass::$id in calendar_build_nodes() (line 663 of /Applications/MAMP/htdocs/sites/all/modules/calendar/calendar.module)."

Anyone know why? I have tried everything I can think of.

fixed it.

@mcmanisd: how?

Check this out. You can use any text editor. Just make sure you get both the @ and //.

http://drupal.org/node/1036332

ok, so that get's rid of the warning, but is there a fix for the actual error?

latest version (7.x-2.x-dev (2011-Mar-24)) has new one error:
Notice: Undefined property: stdClass::$nid in calendar_get_node_link() (line 424 of /var/www/drupal-7.0/sites/all/modules/calendar/calendar.module).

before:
elseif (empty($node->remote) && is_numeric($node->nid)) {
return url("node/$node->nid", array('absolute' => TRUE));

after:
elseif (empty($node->remote) && is_numeric($node->_field_data['nid']['entity']->nid)) {
return url("node/$node->_field_data['nid']['entity']->nid", array('absolute' => TRUE));

I have the same problem, but I have identified the problem to be a result of a different problem altogether.

The error as noted above:
Notice: Undefined property: stdClass::$nid in calendar_get_node_link() (line 427 of sites/all/modules/calendar/calendar.module).

This happens for me with the calendar module when the date field is hidden from display.

It appears that the node id is stored in $node->id and not $node->nid.
This immediately solves the issue above.

The question that follows is, then why is $node->nid working when the date field is not excluded from display.
It appears that $node->nid is being initialized to the output of the date field.
This means some part of the date field is overriding the original value of $node->nid with custom text.

For example, the contents of my $node->nid is:
Friday, April 22, 2011 - 16:30 - Friday, April 29, 2011 - 16:30
That is clearly not the nid.

The function in question begins like the following:

<?php
/**
 * Get the url for a calendar node.
 *
 * @param $node - a calendar node object
 * @param $default - a default url to use when nothing specific is provided.
 */
function calendar_get_node_link($node, $default = NULL) {
. . .
?>

Notice how it is claiming that the $node is supposed to be a calendar node object.

The structure of my calendar node object looks like the following (when the date field is excluded from display):

node = Array ( [0] => node_title [1] => field_data_field_event_date_delta [2] => field_data_field_event_date_language [3] => field_data_field_event_date_bundle [4] => field_data_field_event_date_field_event_date_value [5] => field_data_field_event_date_field_event_date_value2 [6] => field_data_field_event_date_revision_id [7] => field_data_field_event_date_node_entity_type [8] => _field_data [9] => field_data_field_event_date_node_values [10] => raw [11] => calendar_fields [12] => id [13] => title [14] => label [15] => format [16] => format_time )

What appears to be happening here is that the node object is having object variables being written to, thus overriding node object variables.

This is all well and good, but it still does not explain why a date field is being saved as the node id.
There appears to be 3 locations where the each node is being defined:
1) calendar_multiday/theme/theme.inc:176
2) theme/theme.inc:176
3) calendar_ical/calendar_plugin_style_ical.inc:243

Lets look at #1, because thats where the month view seems to be working from:
The following is the problematic section of code:

<?php
  foreach ($result as $num => $row) {
    $copy = clone($row);
    $items[$num] = $row;
    $items[$num]->raw = $copy;
    $items[$num]->calendar_fields = new stdClass();

    $items[$num]->id = !empty($row->$id) ? $row->$id : NULL;

    foreach ($row as $key => $value) {
      if (in_array($key, $calendar_fields)) {
        $items[$num]->calendar_fields->$key = $value;
      }
    }
    foreach ($fields as $name => $field) {
      // Some fields, like the node edit and delete links, have no alias.
      $field_alias = $field->field_alias != 'unknown' ? $field->field_alias : $name;
      if ($field->real_field == 'entity_id' || $field->real_field == 'revision_id') {
        $items[$num]->id = $row->{$field_alias};
        //$col = $field->definition['field_name'] . '_' . $field->options['group_column'];
        //$field_alias = $field->aliases[$col];
      }
      if (!empty($field) && is_object($field)) {
        // Theme the copy instead of the original row so duplicate date
        // fields each get a fresh copy of the original data to theme.
        $items[$num]->{$field_alias} = $field->theme($copy);
      }
      if (!empty($field->options['exclude'])) {
        if (isset($items[$num]->{$field_alias})) unset($items[$num]->{$field_alias});
      }
    }
  }
?>

The mistake here is the assumption that $field_alias is unique and does not overwrite existing fields.
Any part of the node object could potentially be a database column name.

Now what we have is that something is improperly defining their field_alias to be set to nid. (which is a date field)

Getting closer to the culprit, looking at modules/field/views_handler_field_field.inc:115:

<?php
    if (empty($this->definition['is revision'])) {
      $this->field_alias = $this->query->add_field($base_table_alias, $entity_info['entity keys']['id'], '', $params);
    }
?>

If I were to hack this line to see what happens:

<?php
    if (empty($this->definition['is revision']) && FALSE) {
      $this->field_alias = $this->query->add_field($base_table_alias, $entity_info['entity keys']['id'], '', $params);
    }
?>

The above hack produces the desired output.
So the problem is directly related to what happens here: modules/field/views_handler_field_field.inc:115

Unfortunately I have not been able to figure out what needs to be done to properly fix this.
For the time being all I have is a patch that uses the proper nid, thus making the symptom go away.
Attached is the said patch.


To sum up this large post:
1) The variable $node->nid is not actually the nid but a dynamically changeable field row (and therefore cannot be trusted)
- the attached patch fixes this to use $node->id which appears to be the guaranteed node id.

2) The theme functions (calendar_multiday/theme/theme.inc and theme/theme.inc) blindly overwrite $node based of field_alias with the assumption that field_alias can never be a reserved/pre-existing node variable name.
- I have not supplied a solution to this as it may require a major re-write of the logic (such as putting all of the added fields inside of a sub-array so that fields like nid can be used without overwritting $node->nid.

3) There is a bug noticed in modules/field/views_handler_field_field.inc on line 115 where for nid gets improperly replaced with the output of a given field. (in this case, a date field)
- I was unable to find a proper solution to this, it is unclear as to why the field_alias for field_my_custom_date ends up being nid instead of the some name of the field_name (such as field_my_custom_date or field_my_custom_date2)

4) #2 and #3 above are probably issues with the views module (or views and calendar combined) and not the calendar module by itself

subscribing

I have changed the date format from Long to Short and it seems to get rid of the error. I got the idea from looking at the date format for the 'Updated Date' field provided by default. I think the date format may be where the problem exists.

Subscribing - Same error:
Notice: Undefined property: stdClass::$nid in calendar_get_node_link() (line 424 of /var/www/vhosts/mysacrifice.org/httpdocs/sites/all/modules/calendar/calendar.module)..

It happens when I Exclude the date field from display - if the date field is not excluded the error goes away -

I was having the same issue as you just described, I tried solution in #6 and it seemed to do the trick. Good luck.

I deleted all my calendar content, removed and reinstalled unfortunately that was my solution

In continuation from #7: http://drupal.org/node/1087528#comment-4273204

It seems that calendar_plugin_style_ical passed the item parameter to calendar_build_nodes() differently than the rest of the calendar views.

The end result is that the calendar_build_nodes() does not find expected data.

This time around, I removed the calendar_plugin_style_ical code that generates the $item variable and replaced it with the code from template_preprocess_calendar() found inside of calendar/theme/theme.inc.

When this is done, more of the errors vanish.
This also solves the following bug:
- ical only shows only 1 event no matter how many are supposed to show

With the attached patch, the errors go away and the mentioned ical bug goes away.
This patch includes the fix from #7 as well.

I gave thekevinday's patch a try and it got rid of the errors for me in the 2011-04-17 build of calendar-7.x-2.x-dev.

I've rewritten lots of this code to use views->style_plugin->render_fields(), among other things. I don't see any errors in the latest code. You can reopen if you see other problems after updating to today's changes.

Hmm, I missed the big ical patch in here, I'll get this in too.

Hi KarenS, perhaps you committed this patch after the build script ran, but I had to reapply it in the 2011-04-19 dev build.

PS many thanks for the work you've done over the past few days: date/calendar are *much* much more solid now!

There are probably a number of things that haven't made it into the build script yet. I didn't apply this patch as it stands, there were some changes. Everything should be in the next build.