Install bean 7.x-1.0-beta8 and the admin admin ui module. Create a new bean type. Try and add fields to it. Clicking on the edit, manage fields, and manage display links all and up presenting the same form to the user (the main edit form) which only allows you to edit the title.
1. http://dev.example.com/admin/structure/block/types/manage/optics-banner-...
2. http://dev.example.com/admin/structure/block/types/manage/optics-banner-...
3. http://dev.example.com/admin/structure/block/types/manage/optics-banner-...
The links look correct, the form that gets displayed is incorrect in all cases except for 1.
Clearing the cache twice resolved the problem.
Comment | File | Size | Author |
---|---|---|---|
#35 | 1354824_35.patch | 702 bytes | Mile23 |
#32 | bean-n1354824-32.patch | 597 bytes | DamienMcKenna |
#30 | bean-n1354824-25.patch | 721 bytes | DamienMcKenna |
#25 | bean-n1354824-25.patch | 721 bytes | DamienMcKenna |
#13 | unable_to_add_fields_to_new_bean-1354824-13.patch | 673 bytes | willvincent |
Comments
Comment #1
mrfelton CreditAttribution: mrfelton commentedLinks didn't come out well in that post. Should have read.
Comment #2
indytechcook CreditAttribution: indytechcook commentedI'm not sure I follow. Can you elaborate on "the form that gets displayed is incorrect in all cases except for 1" Maybe screenshots.
Comment #3
mrfelton CreditAttribution: mrfelton commentedAll pages show what /admin/structure/block/types/manage/optics-banner-content/edit is supposed to show (a form that allows editing the name of the bean type only)
Comment #4
Maciej Lukianski CreditAttribution: Maciej Lukianski commentedHi, I can add to that.
When on a new install I installe a module with custom bean plugin, I could not edit the bean type it provided. A message is displayed "This block cannot be edited". And I could not add fields to the bean type (the whole manage fields form was missing)
Only when You create at least one bean type via the UI, you are able to add fields to beans wich come from code.
Comment #5
indytechcook CreditAttribution: indytechcook commentedYeah, I saw that also. awesome.
Comment #6
indytechcook CreditAttribution: indytechcook commentedAdding release blocker tag
Comment #7
PJnes CreditAttribution: PJnes commentedClearing cache sorted the problem for me as well.
Comment #8
willvincent CreditAttribution: willvincent commentedI suspect the reason for this has to do with the call to block_flush_caches() in the save method of bean.core.inc.
On save block caches are flushed, but on module enable they're probably not being flushed.
There are a couple ways this could be addressed:
1) Modules that provide custom beans implement a hook_enable() to clear cache.
or better
2) Bean implements a hook_modules_enabled() that checks if the just enabled module(s) provide beans, and if so flushes the block cache. or just flushes the block cache regardless whenever the hook is fired.
I think the second approach is better as it doesn't require implementing another hook in modules that provide custom beans, since bean itself would handle clearing the cache.
Comment #9
indytechcook CreditAttribution: indytechcook commentedI like the 2nd options. Great idea and great catch!
Comment #10
willvincent CreditAttribution: willvincent commentedI've tried several variations of option 2, ultimately the most heavy handed approach:
And still no joy.. While I think we're probably on the right track here, there's got to be something else we're missing. The majority of what drupal_flush_all_chaches() does is already done during module enabling anyway, so this really shouldn't be necessary though.
Comment #11
willvincent CreditAttribution: willvincent commentedAlright, I've got this sorted out.
It's a bit heavy handed, in that it calls drupal_flush_all_caches() and drupal_static_reset(), but it only does so if a module has just been enabled that provides at least one bean type.
I also moved it into the bean_admin_ui module as it's only relevant to the UI, not Beans created entirely in code.
Comment #12
willvincent CreditAttribution: willvincent commentedComment #13
willvincent CreditAttribution: willvincent commentedBetter approach, simply calls bean_reset().
Comment #14
indytechcook CreditAttribution: indytechcook commented@willvincent, This looks good. When the tests run I'll commit it.
In the mean time can you add a test to make sure this doesn't occur again?
Comment #15
willvincent CreditAttribution: willvincent commentedHmm.. I have no idea how to write a test for this
Comment #16
indytechcook CreditAttribution: indytechcook commented@willvincent. See the original description.
Just do all that in the simple test and make sure the links to go the correct place. I just want to make sure this doesn't get rebroken in the future.
Comment #17
indytechcook CreditAttribution: indytechcook commentedThanks!
http://drupal.org/commitlog/commit/22232/03d1141aa74b3e1b011638847ac4cb4...
Comment #18
barraponto CreditAttribution: barraponto commentedI'm using rc3 and have been bitten by this bug. I'm using only bean and bean_admin_ui.
Comment #19
willvincent CreditAttribution: willvincent commentedTry the dev version.
Comment #20
indytechcook CreditAttribution: indytechcook commented@barraponto, did you try the dev version?
Comment #21
barraponto CreditAttribution: barraponto commentednot yet, i'll assign this to myself and test it.
Comment #22
alexweber CreditAttribution: alexweber commentedWorks for me! :)
Comment #24
lilbebel CreditAttribution: lilbebel commentedAwesome. Thank you!
Comment #25
DamienMcKennaSorry to have to re-open this issue, but the patch in #13 has nothing to do with the problem, which still persists in 1.0. To be clear, this is a problem when creating new block types in the Bean Admin UI module pages, it has nothing to do with enabling that module.
Scenario:
What should happen is that the bean_admin_ui_type_form_submit() function should clear the appropriate caches so that the two new pages work.
This patch uses drupal_flush_all_caches() simply because neither running menu_rebuild() nor running bean_reset() was enough to make the new pages load.
Comment #27
DamienMcKennaComment #28
DamienMcKenna#25: bean-n1354824-25.patch queued for re-testing.
Comment #30
DamienMcKennaTry again.
Comment #32
DamienMcKenna*facepalm*. I created that patch from my local D7 install, not my checkout of Bean. This one should work.
Comment #33
barraponto CreditAttribution: barraponto commentedJust tested the patch and the steps to reproduce. Works ok.
Comment #34
indytechcook CreditAttribution: indytechcook commentedI was really trying to avoid a full cache flush. Oh well.
I'd still rather see the specific caches that need clearing in bean_admin_ui_bean_cache_clear() then we can still call bean_reset.
I've committed this for now but keeping the issue open to see if we can find a better way.
EDIT:
Commit: http://drupal.org/commitlog/commit/22232/29ca8eefc61bca990acca820f1941b9...
Comment #35
Mile23I noticed that #32 is in 1.11, updated to 1.13 and it's in there, like #34 mentions.
It's important to update the caches, but it might be better to use a targeted approach more like
bean_reset(TRUE, FALSE);
I say this because I'm working on a site with ~37k beans and ~380k nodes.
drupal_flush_all_caches()
means that all of these pieces of content have to be cached on the redirect back to the types listing page because of another caching issue withmenu_rebuild()
. Rebuilding the page takes an hour or so.In an ideal world, we'd have
hook_bean_clear_cache_for_type($type)
andhook_clear_cache_for_bean($bean)
, and then other modules could adapt to the use-case.