After creating a new bean, you get forwarded straight to the View URL - which results in a whitescreen of death. The error in the logs is:

[24-May-2011 20:05:35] PHP Fatal error:  Call to a member function values() on a non-object in /Users/tom/workspace/alumni/profiles/alumni/modules/contrib/bean/includes/bean.core.inc on line 37
[24-May-2011 20:05:35] PHP Stack trace:
[24-May-2011 20:05:35] PHP   1. {main}() /Users/tom/workspace/alumni/index.php:0
[24-May-2011 20:05:35] PHP   2. drupal_bootstrap() /Users/tom/workspace/alumni/index.php:21
[24-May-2011 20:05:35] PHP   3. _drupal_bootstrap_full() /Users/tom/workspace/alumni/includes/bootstrap.inc:2056
[24-May-2011 20:05:35] PHP   4. menu_set_custom_theme() /Users/tom/workspace/alumni/includes/common.inc:4935
[24-May-2011 20:05:35] PHP   5. menu_get_custom_theme() /Users/tom/workspace/alumni/includes/menu.inc:1689
[24-May-2011 20:05:35] PHP   6. menu_get_item() /Users/tom/workspace/alumni/includes/menu.inc:1674
[24-May-2011 20:05:35] PHP   7. _menu_translate() /Users/tom/workspace/alumni/includes/menu.inc:451
[24-May-2011 20:05:35] PHP   8. _menu_load_objects() /Users/tom/workspace/alumni/includes/menu.inc:744
[24-May-2011 20:05:35] PHP   9. bean_load() /Users/tom/workspace/alumni/includes/menu.inc:577
[24-May-2011 20:05:35] PHP  10. bean_load_multiple() /Users/tom/workspace/alumni/profiles/alumni/modules/contrib/bean/bean.module:263
[24-May-2011 20:05:35] PHP  11. entity_load() /Users/tom/workspace/alumni/profiles/alumni/modules/contrib/bean/bean.module:283
[24-May-2011 20:05:35] PHP  12. EntityAPIController->load() /Users/tom/workspace/alumni/includes/common.inc:7362
[24-May-2011 20:05:35] PHP  13. Bean->__construct() /Users/tom/workspace/alumni/profiles/alumni/modules/contrib/bean/includes/bean.core.inc:0
[24-May-2011 20:05:35] PHP  14. Bean->setFields() /Users/tom/workspace/alumni/profiles/alumni/modules/contrib/bean/includes/bean.core.inc:29

It seems that bean_load() isn't pulling back a complete bean object. I'm not up enough on my Entity API to know why not, or even what is expected to be returned from entity_load().

Comments

indytechcook’s picture

This this a custom plugin? If so be sure to add the file to the files[] = xxxx.inc in the info file. Currently there is a bug in the ctools plugin system where it doesn't include all of the files correctly if you fetch all of the info before you fetch the actually plugin.

indytechcook’s picture

Also reinstall (not just disable, re-enable) the module so the code registry will be update.

mrfelton’s picture

It's not a custom plugin. This is a bean type that was created through the admin ui.

indytechcook’s picture

Thanks, debugging.

indytechcook’s picture

Appear to still be a cache issues. If you flush caching, the issues is resolved. I'm looking into it.

mrfelton’s picture

This is odd. After uninstalling and reinstalling the module and clearing the caches... I created a block type and got presented with the error described in #1167552: Undefined index: alumni_header in bean_fetch_plugin_info() bean.module line 200

Then, I went to /block/add/my-block-type and I'm not getting the whitescreen of death any more, but instead get a redirect loop and cant load the page at all!

indytechcook’s picture

Status: Active » Fixed

There were some nasty caching and static caching issues caused by my module and by ctools that took me a while to resolve. But all seems to be working now. http://drupal.org/commitlog/commit/22232/48ab1c72a0dcd8720fe76725ae7ed24....

Please test and verify and I will make another alpha release.

mrfelton’s picture

Status: Fixed » Needs work

No, unfortunately I'm still getting the same error. I uninstalled the module and cleared my caches. Then reinstalled and cleared the caches again. I was able to create a bean type without any problem, but as soon as I tried to create a new block, submitting the form at /block/add, I got the whitescreen again, and the same error in my logs (Call to a member function values() on a non-object in bean/includes/bean.core.inc on line 37)

mrfelton’s picture

I've been trying to track this down, but not having too much luck. Basically the problem seems to be that when bean_load_plugin_class() from Bean's __construct method, it isn't being passed the correct type. I don't know why $this->type isn't set when the entity is loaded through entity_load(). If I hardwide my class name into ctools_plugin_load_class() in bean.module:274 then it loads correctly.

So, when entity_load() is called to load the Bean entity, why is it incomplete? ie, why is $this->type not set as it should be?

mrfelton’s picture

I have a patch that gets things working - but I'm sure its the wrong way to go about this.

Basically, the problem is that in bean_load, you can entity_load() to load the bean entity. Entity in turn calls Bean::Construct(), in which bean_load_plugin_class($this->type); is called to set the plugin property. At this point, $this>type is not set, and so the plugin property doesn't get set properly.

I don't know why $this->type isn't getting set. It has something to do with the fact that $values is empty.

If you instantiate the Bean class, and then set the plugin property on it outside of the __construct function, it seems to work. This is basically what the attached patch does. Rather than trying to get and set the plugin in the constructor, I have instead made a public function that is able to set the plugin, and am calling this from bean_load_multiple().

Its a hack, but hopefully this will give you some insights into what is actually going wrong.

mrfelton’s picture

StatusFileSize
new1.53 KB

And the patch...

indytechcook’s picture

Status: Needs work » Postponed (maintainer needs more info)

Very Interesting solution. What version of php are you using? I have a feeling this is related to a php bug in how the PDO library loads the object. One of my coworkers had that same issue, then upgraded php and the issue went away. I can't seem to find the links to the php or the d.o. issues ( I can do some more digging if needed).

I only ask because I can't reproduce the issue locally and it seems like I should be able to very easily.

This patch is an interesting solution though. It might be necessary to get around the php bug.

mrfelton’s picture

I'm using PHP 5.2.13 from MAMP. What about you?

mrfelton’s picture

Status: Postponed (maintainer needs more info) » Active
indytechcook’s picture

between 5.2.17 and 5.3.5 on mamp.

I'm going to try a fresh site install to see if I can reproduce.

mrfelton’s picture

Status: Active » Needs review
StatusFileSize
new2.2 KB

Seems my last patch was a little incomplete, and caused a couple of other warnings, and a WOD on the block add page. Attached patch seems to resolve, and stuff seems to be working ok now. I've also documented it a little better.

mrfelton’s picture

Just to note that this patch is still required for me. I can not use this module at all without it.

indytechcook’s picture

Status: Needs review » Reviewed & tested by the community

My favorite part of this patch are the changes to the entity loading. I noticed last night that it didn't work like I wanted. I'd say commit it. We can add clean up later.

mrfelton’s picture

Status: Reviewed & tested by the community » Closed (fixed)
mrfelton’s picture

Status: Closed (fixed) » Fixed

Status: Fixed » Closed (fixed)

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

mstrelan’s picture

Status: Closed (fixed) » Active
StatusFileSize
new60.39 KB

This seems to be broken again in the latest version on some versions of PHP (5.2.13 in my case). For some reason $this->plugin is not set when the view function is called.

Error message
Fatal error: Call to a member function view() on a non-object in /home/history/public_migration/sites/all/modules/bean/includes/bean.core.inc on line 276

Workaround

<?php
  public function view($view_mode = 'default', $langcode = NULL, $page = NULL) {
    $content = parent::view($view_mode, $langcode);
    if (empty($this->plugin)) {
      dpm($this);
      return $content;
    }
    return $this->plugin->view($this, $content, $view_mode, $langcode);
  }
?>

Screenshot of the dpm output is attached.

indytechcook’s picture

Status: Active » Fixed

Status: Fixed » Closed (fixed)

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