Check if bean type class exists when loading bean.

is your issue fixed with the dev version? I think this is solved in http://drupal.org/commitlog/commit/22232/561492f6ca4c09a3da3b17efe26a732...

If so, then I"ll roll a new release.

Same issue for me on the latest -dev.

I believe I'm up and running. I traced the code to ctools_get_plugins() which was calling bean_admin_ui. As it turns out (after talking with inytechcook in IRC), if you've built your bean type from within the UI, then bean_admin_ui is required and cannot be disabled. Simply turning on the UI module fixed my issue.

I guess I'll keep the issue active and let persand close it if this also fixes his problem.

Also try truncating the cache tables, then running update.php on beta9.

I am getting a similar error to this - but not on every page.

Recoverable fatal error: Argument 1 passed to Bean::loadUp() must implement interface bean_type_plugin_interface, boolean given, called in /Users/brantwynn/Sites/sandboxes/d7/sites/all/modules/bean/includes/bean.core.inc on line 152 and defined in Bean->loadUp() (line 160 of /Users/brantwynn/Sites/sandboxes/d7/sites/all/modules/bean/includes/bean.core.inc).

This happens when I disable a bean plugin module and orphaned block entities from the module are left behind.

I imagine they are looking for the block type reference and failing?

If I delete those entities before disabling there are no errors.

Strangely enough, when I see this error, the bean module also gets disabled even though I did not uncheck it from the modules list.

This does seem to occur when the plugin has been disabled/deleted.

Let's add some checking on this issue.

I've created another issue to deal with remove blocks on uninstall #1376368: Clean up Beans on uninstall

Patch attached to test

New error when disabling a bean plugin module after applying the patch.

Fatal error: Cannot instantiate abstract class bean_plugin in /sites/all/modules/bean/bean.module on line 304

Try this patch. Be sure to run update.php to catch a new class for the code registry

Also, if a patch doesn't work, change the issue status to "needs work"

Cheers

Excellent!

check_plugin-1351694-13.patch tested and working.

The addition of a default plugin bean "Block" is a good idea.

This should be committed to development release.

I got this problem immediately after installing the Data module. I updated to the latest dev code, no change. I applied the patch from #13 and ran updatedb. Now, my site is completely unaccessible with the following error in the webserver logs:

[28-Dec-2011 03:41:21] PHP Fatal error:  Call to a member function view() on a non-object in /Users/tom/workspace/sac2/sites/all/modules/contrib/bean/includes/bean.core.inc on line 279
[28-Dec-2011 03:41:21] PHP Stack trace:
[28-Dec-2011 03:41:21] PHP   1. {main}() /Users/tom/workspace/sac2/index.php:0
[28-Dec-2011 03:41:21] PHP   2. menu_execute_active_handler() /Users/tom/workspace/sac2/index.php:21
[28-Dec-2011 03:41:21] PHP   3. drupal_deliver_page() /Users/tom/workspace/sac2/includes/menu.inc:518
[28-Dec-2011 03:41:21] PHP   4. drupal_deliver_html_page() /Users/tom/workspace/sac2/includes/common.inc:2438
[28-Dec-2011 03:41:21] PHP   5. drupal_render_page() /Users/tom/workspace/sac2/includes/common.inc:2503
[28-Dec-2011 03:41:21] PHP   6. context_page_build() /Users/tom/workspace/sac2/includes/common.inc:5502
[28-Dec-2011 03:41:21] PHP   7. context_reaction_block->execute() /Users/tom/workspace/sac2/sites/all/modules/contrib/context/context.core.inc:248
[28-Dec-2011 03:41:21] PHP   8. context_reaction_block->block_get_blocks_by_region() /Users/tom/workspace/sac2/sites/all/modules/contrib/context/plugins/context_reaction_block.inc:222
[28-Dec-2011 03:41:21] PHP   9. context_reaction_block->block_list() /Users/tom/workspace/sac2/sites/all/modules/contrib/context/plugins/context_reaction_block.inc:316
[28-Dec-2011 03:41:21] PHP  10. _block_render_blocks() /Users/tom/workspace/sac2/sites/all/modules/contrib/context/plugins/context_reaction_block.inc:352
[28-Dec-2011 03:41:21] PHP  11. module_invoke() /Users/tom/workspace/sac2/modules/block/block.module:834
[28-Dec-2011 03:41:21] PHP  12. call_user_func_array() /Users/tom/workspace/sac2/includes/module.inc:794
[28-Dec-2011 03:41:21] PHP  13. bean_block_view() /Users/tom/workspace/sac2/includes/module.inc:0
[28-Dec-2011 03:41:21] PHP  14. Bean->view() /Users/tom/workspace/sac2/sites/all/modules/contrib/bean/bean.module:642

I then ran drush rr to clear ythe registry, followed by drush cc all to clear out all of the caches. At that point my site became accessible again, although about 90% of my Feature modules were disabled, as well as random moduls like Devel. I reenabled them all, and my site seems to be functioning normally again now.

Thanks @mrfelton. sorry for the troubles. Hopefully we are getting these odd cache/code registry issues ironed out.

http://drupal.org/commitlog/commit/22232/8af1ab44eb63c7edb144b9610e5d240...