I can create a field from view reference and can be shown correctly and the node can be edited as well. But one day I have the following error in a sudden and I can not figure the reason out but have to disable the module.

Fatal error: Call to a member function preview() on a non-object in C:\xampp\htdocs\drupal\sites\all\modules\viewreference\viewreference.module on line 225

Anyone gets some idea on it? Thanks!

Comments

danielb’s picture

Category: bug » support

no idea

ycwjjjj’s picture

Version: 6.x-2.9 » 6.x-2.23

I get this problem again after using the import function from node export module. It's successful to import the pasted code which was exported from a node having the view reference field and with the same content type. However, the new created node can't be displayed and edited with the following errors.

For view the new created node, it gets the following error.
Fatal error: Call to a member function get_title() on a non-object in C:\xampp\htdocs\drupal\sites\all\modules\viewreference\viewreference.module on line 239

For edit the new created node, it gets the following error.
Fatal error: Call to a member function preview() on a non-object in C:\xampp\htdocs\drupal\sites\all\modules\viewreference\viewreference.module on line 225

The existing nodes with the same content type were displayed normally.

danielb’s picture

Did you edit the content type or view around the time it started screwing up? I wonder if there is something I haven't thought of there.

You might just have to resave the node and confirm the field is set correctly.

A way to remove those errors would be to add if statements around the outputs in the theme functions that cause those errors, for example the error from line 225 can be fixed like so:

This function:

<?php
/**
 * Theme function for 'default' viewreference field formatter.
 */
function theme_viewreference_formatter_default($element) {
  $output = '';
  if (!empty($element['#item']['view_id']) && is_numeric($element['#item']['view_id'])) {
    $view = db_fetch_object(db_query("SELECT name, position FROM {viewreference} WHERE view_id = '%d'", $element['#item']['view_id']));
    $args = viewreference_get_element_args($element);
    $view_object = views_get_view($view->name);
    $output .= $view_object->preview($view->position, $args);
  }
  return $output;
}
?>

Would become this:

<?php
/**
 * Theme function for 'default' viewreference field formatter.
 */
function theme_viewreference_formatter_default($element) {
  $output = '';
  if (!empty($element['#item']['view_id']) && is_numeric($element['#item']['view_id'])) {
    $view = db_fetch_object(db_query("SELECT name, position FROM {viewreference} WHERE view_id = '%d'", $element['#item']['view_id']));
    $args = viewreference_get_element_args($element);
    $view_object = views_get_view($view->name);
    if (is_object($view_object)) {
      $output .= $view_object->preview($view->position, $args);
    }
  }
  return $output;
}
?>

However it would be best to find the source of the error to make a more informed decision on what to do :/

Alan D.’s picture

This simply looks like an import for a view id that doesn't exist in the new system. But does the module hook into the view delete operations? If not I would use a if statement to prevent this error natively [The results are NULL or Object, so there should be no need for is_object()].

Eg:

<?php
    if ($view_object = views_get_view($view->name)) {
      $output .= $view_object->preview($view->position, $args);
    }
?>

I was just investigating the issue queue before trying it out for the first time. This is looking like a useful module, nice work.

Cheers

danielb’s picture

Yeah I gave is_object because I wasn't sure what actual value $view_object would have in his case, all the error said was that it was not an object and I don't know what views_get_view() returns in that situation.

But does the module hook into the view delete operations?

And then do what with that information? In the end you've ruined your viewreference no matter what happens. No, you would have to reconfigure the viewreference field after removing the view. One would think you would be clever enough not delete a view that you are relying on for a viewreference.

But yeah, the error sucks, might supress it in the theme functions with those if statements.

danielb’s picture

Status: Active » Fixed

Status: Fixed » Closed (fixed)

Automatically closed -- issue fixed for 2 weeks with no activity.