Fatal error: Call to a member function get_handlers() on a non-object
in /Users/gordon/Sites/dev6/sites/all/modules/views/handlers/views_handler_field.inc on line 252

I get this error when I am getting a new field. It is because the display_handler property has not been set. The problem only occurs when adding fields that are in the ec_transaction table. The tables are laid out as so.

node --- join --> ec_transaction_product --- relationship ---> ec_transaction.

Adding fields from ec_transaction_product works fine, but adding fields from ec_transaction I get the error in the ajax which stops the add. However the field as been added, and the settings form isn't past back.

The funny thing is that even with this error the field is added fine, and the query works.

Since I have not been able to work out exactly what the problem is, I am having problems what I need to do to repecate the issue is some test code.

The steps to replicate this issue.

1. Create a new view using the node as the base table.
2. Create a relationship with the Transaction table.
3. Finally add the transaction id field and the error will happen.

This is actually holding up a screen cast that I would like to get done fairly soon.

Let me know if you need any more information.

Gordon.

CommentFileSizeAuthor
#7 admin.inc-380560-7_HEAD.patch840 bytesDarren Oh
Support from Acquia helps fund testing for Drupal Acquia logo

Comments

chrissearle’s picture

Seeing this too - with a user view and a relationship to content profile.

Am only seeing this on views with relationships when adding a field that will use that relationship.

An existing view with a relationship has lost all but one relationship field from its output (the others are there just empty). The SQL generated makes no request for the missing fields. As to why the one field works - no idea.

Just noticed that 1) a difference from the OP - my fields are _NOT_ created and 2) If I try to edit a field that has this problem on an existing view I get the same error and cannot edit.

gordon’s picture

I have tryed to track it down. All I can figure out that init_display() or set_display() is not called.

Maybe the first thing to do is to check that I have set up ec views correctly see http://cvs.drupal.org/viewvc.py/drupal/contributions/modules/ecommerce/e...

Also when I add the fields it gives me the error, but the display of the fields works correctly.

chrissearle’s picture

I wonder. Mine isn't an EC_ view - its a user view with a relationship to a content profile node type. It is exactly the same error - which is why I commented here rather than starting a new one. I could check - but I'm not sure how you're testing - how do you test for these _display() methods - is it as simple as debug printing from them or is there an easier way?

gordon’s picture

If you can replicate this with standard views please let me know how you do this.

Thanks.

Mark Theunissen’s picture

Hi gordon, I ran into this error with standard views, I opened an issue because I didn't find this one in my searches. Anyway it's now marked as duplicate but check it out for simple steps to reproduce: http://drupal.org/node/384630

gordon’s picture

Category: support » bug
Priority: Normal » Critical

With more information and being able to replicate this in a clean version of views I am setting this as a critical but report.

Darren Oh’s picture

Status: Active » Needs review
FileSize
840 bytes

This happened because the view was being cached if the field came from a relationship. Caching unset all handlers.

cdale’s picture

Commenting out line 2295 of admin.inc (the views_ui_cache_set($view); line in above patch) fixes this issue immediately for me. Didn't even have to reload the page, the ajax just kicked in. :) From my use so far, it does not seem to have affected anything else. Although from looking at the comments it seems like that line might have been there for a reason? Was this a data integrity/sanity kind of thing?

Darren Oh’s picture

It was supposed to keep track of changes. Merlin says it's not that important.

cdale’s picture

Status: Needs review » Reviewed & tested by the community

Well if it's not that important, I'd say this change is RTBC as it is a really annoying bug and I've seen no other side effects of running with this patch.

djalloway’s picture

Can also verify that no other side-effects are experienced when using this patch.
Let's see a commit!

mikeryan’s picture

+1 - I was seeing this problem when joining tables in an external database via a relationship, the patch cleared it right up.

Thanks!

quicksketch’s picture

This issue also affects FileField when adding a relationship to the files table, then trying to add any File data such as path or fid. See #412850: Cannot edit "File: Path" settings in Views for a description of the problem and how to reproduce that particular situation. I'm not sure about changes the patch makes, but I can confirm it solves the described problem.

joachim’s picture

This happens when you add a field that can't apply to the views base table, but that the UI lets you add because it DOES apply to a relationship.
Example: create a comment view, add a comment->node relationship, try to add a node field.

Here's a test case:

$view = new view;
$view->name = 'comment_broken';
$view->description = 'Try adding a node field -- you get an error.';
$view->tag = '';
$view->view_php = '';
$view->base_table = 'comments';
$view->is_cacheable = FALSE;
$view->api_version = 2;
$view->disabled = FALSE; /* Edit this to true to make a default view disabled initially */
$handler = $view->new_display('default', 'Defaults', 'default');
$handler->override_option('relationships', array(
  'nid' => array(
    'label' => 'Node',
    'required' => 0,
    'id' => 'nid',
    'table' => 'comments',
    'field' => 'nid',
    'relationship' => 'none',
  ),
));
$handler->override_option('fields', array(
  'cid' => array(
    'id' => 'cid',
    'table' => 'comments',
    'field' => 'cid',
  ),
));
$handler->override_option('access', array(
  'type' => 'none',
));

I can confirm the patch makes the error go away, but like comments above, I've no idea why!

Leeteq’s picture

Subscribing.

attheshow’s picture

Subscribing.

merlinofchaos’s picture

Status: Reviewed & tested by the community » Fixed

I committed a patch that stores a clone of the $view which will allow the previous functionality to continue as well as not disturbing the handlers on the view. Win + win.

quicksketch’s picture

Thanks merlin!

Status: Fixed » Closed (fixed)

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

Teebo’s picture

Hello,

I am recurrently having this error:
PHP Fatal error: Call to a member function get_handlers() on a non-object in /sites/all/modules/views/includes/view.inc on line 372

I was getting it with the 6.2.8 Views module. So I updated to the 6.3.0a2 and I'm still having this error.
By recurrent I mean every 10min. The only thing that "fixes" (very temporarily) this issue is flushing the cache. So I have a CRON flushing the cache every 5min. Which is not an option.

It occurs on the homepage. I have 4 blocs of content. Nothing special. All cached to speedup the page loading.

Thanks in advance for your help.

yan’s picture