When building a Panels-based display, all of the bean objects are normally grouped under the Miscellaneous category. It would be really useful if they were instead grouped by block type.
| Comment | File | Size | Author |
|---|---|---|---|
| #17 | bean-n1924126-16.patch | 1.18 KB | damienmckenna |
| #14 | bean-n1924126-14.patch | 974 bytes | damienmckenna |
| #1 | bean-n1924126.patch | 745 bytes | damienmckenna |
Comments
Comment #1
damienmckennaThis patch moves each of the beans into a new category based on the block type, in the format "Blocks: [bean_type_label]".
Comment #2
berdyshev commentedIn case of huge list of bean types we will get the numerous block categories, which is not good for UI (ctools dialog).
Comment #3
berdyshev commentedI have installed latest code from branch 7.x-1.x and applyed this patch, activated Node Template for Panels pages. After I've added bean block into panel page sidebar I got list of errors:
Comment #4
damienmckennaI'm also getting the following errors within the Panels UI after a bean block is added to a page:
These happen without the patch being applied, i.e. it is unrelated to this patch, and appears to be because CTools is unable to handle blocks that are returned from hook_block_view as renderable arrays.
Comment #5
indytechcook commentedThat makes me sad.
You might look at using http://drupal.org/project/bean_panels as it creates a bean ctools content type.
Comment #6
damienmckennaI'm going to work on this after some calls this morning, but I'm determined to a) not use Bean_Panels, b) get this to work :)
Comment #7
berdyshev commented@indytechcook, yes, I saw. Can we merge its functionality into Bean module?
Comment #8
berdyshev commented@DamienMcKenna, I'm not understanding your point. why you want to implement panels integration not using Bean Panels module, which was created special for that? ;-)
Comment #9
indytechcook commentedI won't supersede what another contrib module already did. That seems rude IMO. If the maintainer makes a request to fold in that functionality then we can have the discussion.
General, I'm good with adding new features are long as they are passive changes and do not add much to the code that is loaded on every page request.
Comment #10
berdyshev commented@indytechcook, I'm suggesting to merge Bean Panels module into this module (if his maintainer will not be against).
Otherwise, I don't see the way this feature request can be implemented without getting rid of Bean Panels module.
Comment #11
damienmckennaI don't like Beans_Panels because the UX is pretty horrible, see #1890800: Won't handle large numbers of beans.
The point of this patch is that CTools automatically lists all beans anyway, why not improve the UX? Perhaps we should add an option (global or per-entity?) that controls whether the beans are listed as either a) in the Miscellaneous category, b) in one category for all beans, c) in one category per bean group.
Comment #12
damienmckennaI added an issue for the error that's displayed in the Panels admin: #1925008: Errors when displaying beans in Panels
Comment #13
damienmckenna@Berdart: The errors you reported in #3 have nothing to do with this patch and is because of a CTools bug that was fixed last year: #1739718: assign property of non-object in ctools_block_content_type_render Updating to CTools 7.x-1.x-dev will fix that for you.
Comment #14
damienmckennaA small update: a) I changed to using the icon_contrib_block.png icon instead of the other one, b) it does a little checking first to ensure that the bean's type is present before trying to get the bean type's label. Regarding the second part, off-hand I think it shouldn't be possible for this to happen but I haven't delved into the code enough to say for certain, and it's possible that it may be preferable to completely hide the block should this happen anyway ($info = NULL).
Comment #15
berdyshev commentedI have tested this patch on fresh drupal install with dev version of ctools module and it works without errors I have mentioned previously.
But, yes, I got errors from here #1925018: Adding a renderable-array block to a page gives errors in the admin UI
And one more question, which I've already asked but didn't receive answer. When we will have a huge list of block types we will get a big list of categories in ctools Add Content dialog which isn't good. What do you think about such variant: we will group all beans under Beans or Blocks category but we will prefix their title with block type in square brackets - something like this:
[Block type]: bean labelComment #16
damienmckennaHow about this? It provides two variables to control the display, one to control whether the beans are grouped by the bean type, one to control whether they're prefixed by the bean type. I haven't added a settings page as we'd need direction from indytechcook on how to handle that.
Comment #17
damienmckennaOh, a patch would help X-)
Comment #18
berdyshev commenteddon't sure if this is acceptable, because in this case we need also a settings page. I think we need to choose only one, right way.
But yes, I think we need direction from indytechcook
Comment #19
indytechcook commentedI generally ok with not having a global settings page as long as the variable documented. Sensible defaults is probably the best way to go. Though I tend to avoid UI driven development as all costs.
If we were to have an global settings page, I'd say put it at admin/structure/block-types/config. This would keep with all of the other bean config. Thoughts?
Comment #20
saltednutHaving a menu at admin/structure/block-types/config for things like this would be great.
This patch works perfectly!
Comment #21
saltednutSuggestion: commit this, add variables to documentation, and then post a followup for the admin/structure/block-types/config as a new issue.
Comment #22
saltednutCommitted and attributed to Damien: http://drupalcode.org/project/bean.git/commit/efe15b9
Followup: #1993112: Bean admin settings for ctools variables needed