Block reference not picking up bean module blocks

I've used blockreference very extensively with bean on several projects. Could you please elaborate on "bean blocks do not show up as options"?

I can confirm that this is an existing issue or regression. I just updated the bean module from 1.0-rc6 to 1.0 and entity from 1.0-rc3 to 1.0. Before the update, newly created beans would appear in blockreference fields. After the update, they don't appear until I clear the cache.

I noticed that after the creation of a bean with the updated modules, the new bean does not appear in the blocks table, which is what block reference uses as its source. When I create a new bean with the older version of the modules, the new bean does appear in the blocks table immediately upon creation.

I'm also not sure why a cache clear would populate the blocks table, but that's what seems to happen.

To reproduce the issue outside of my existing site, I did the following:

• clean standard install of drupal 7.20
• download entity 1.0, bean 1.0, blockreference 1.15, and their dependencies
• enabled bean_admin_ui, entity, blockreference, and requirements of those modules
• created a test block type
• added a blockreference field to the page content type
• created a test bean of the test block type
• created a test page and did not see the new bean in the blockreference list
• cleared the cache (via drush, in my case)
• reloaded the new page form page
• saw the test bean in the blockreference list

I'll keep digging around, but I wanted to put this out there in the hope that the module devs will notice something simple and obvious.

Just to confirm that this wasn't an issue with the update to entity, I ran the same test as above but with bean 1.0-rc6 and entity 1.0. With that combo, the new beans appear in the blocks table immediately upon save and are therefore available to blockreference fields.

Then I updated to bean 1.0-rc7 and the issue appeared. New beans no longer appear immediately in the blocks table. Odd, since that release was way back in December, and I'd think the issue would've been noticed by now. I can't help but wonder if something else is going on.

Found it. In rc7 block_flush_caches() was removed from Bean::save(). Here's a patch that puts it back.

What's the overhead of calling block_flush_caches() every time a bean is saved? Just trying to figure out why this was removed to begin with...

What's the overhead of calling block_flush_caches() every time a bean is saved?

I can't imagine that it's much. Beans are saved a lot less often than they are viewed. I'm using the patch on several sites that use the bean/blockreference combo, and there is no apparent delay when beans are created or edited.

And without this patch, there can be real problems using beans with blockreference fields - new beans just don't show up in the list of available blocks.

Cache ttl is usually like 5 min anyway. I doubt many sites are rebuilding block configurations that much. I'm ok with committing this if we can get an RTBC on it. I've not used blockreference before so perhaps someone with some experience using the module can test this?

Tested with Block Reference, was able to put beans within beans, and put beans into other node types using block reference field.

I think you meant RTBC, right? :) (Maintainers use 'fixed' after the patch is committed.)

I very wary of adding the rehash at this step as I feel it will cause a significant performance issue but I see no way around it.

What's interesting is that block_flush_caches() was actually in the code but was removed somewhere, probably during the cache clear refactor.

I committed the concept but a little different implementation.

For people looking for the committed patch: http://drupalcode.org/project/bean.git/commitdiff_plain/bd5b498