Closed (fixed)
Project:
Bean (for Drupal 7)
Version:
7.x-1.x-dev
Component:
Code
Priority:
Normal
Category:
Bug report
Assigned:
Unassigned
Reporter:
Created:
24 May 2011 at 18:07 UTC
Updated:
13 Jan 2012 at 04:00 UTC
Jump to comment: Most recent file
Comments
Comment #1
indytechcook commentedThis 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.
Comment #2
indytechcook commentedAlso reinstall (not just disable, re-enable) the module so the code registry will be update.
Comment #3
mrfelton commentedIt's not a custom plugin. This is a bean type that was created through the admin ui.
Comment #4
indytechcook commentedThanks, debugging.
Comment #5
indytechcook commentedAppear to still be a cache issues. If you flush caching, the issues is resolved. I'm looking into it.
Comment #6
mrfelton commentedThis 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!
Comment #7
indytechcook commentedThere 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.
Comment #9
mrfelton commentedNo, 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)
Comment #10
mrfelton commentedI'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?
Comment #11
mrfelton commentedI 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 canentity_load()to load the bean entity. Entity in turn calls Bean::Construct(), in whichbean_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.
Comment #12
mrfelton commentedAnd the patch...
Comment #13
indytechcook commentedVery 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.
Comment #14
mrfelton commentedI'm using PHP 5.2.13 from MAMP. What about you?
Comment #15
mrfelton commentedComment #16
indytechcook commentedbetween 5.2.17 and 5.3.5 on mamp.
I'm going to try a fresh site install to see if I can reproduce.
Comment #17
mrfelton commentedSeems 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.
Comment #18
mrfelton commentedJust to note that this patch is still required for me. I can not use this module at all without it.
Comment #19
indytechcook commentedMy 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.
Comment #20
mrfelton commentedFixed in http://drupalcode.org/project/bean.git/commitdiff/153a868?hp=80c2bd6931f...
Comment #21
mrfelton commentedComment #23
mstrelan commentedThis 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 276Workaround
Screenshot of the dpm output is attached.
Comment #24
indytechcook commentedIt's like a last resort. Not bad. http://drupal.org/commitlog/commit/22232/bd5c5dec49bcd044b3f20605a9f59a7...