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.

Comments

damienmckenna’s picture

Status: Active » Needs review
StatusFileSize
new745 bytes

This patch moves each of the beans into a new category based on the block type, in the format "Blocks: [bean_type_label]".

berdyshev’s picture

In case of huge list of bean types we will get the numerous block categories, which is not good for UI (ctools dialog).

berdyshev’s picture

Status: Needs review » Needs work

I 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:

Warning: Attempt to assign property of non-object in ctools_block_content_type_render() (line 152 of /home/scbe2c8d373036c1/www/sites/all/modules/ctools/plugins/content_types/block/block.inc).
Warning: Attempt to assign property of non-object in ctools_block_content_type_render() (line 153 of /home/scbe2c8d373036c1/www/sites/all/modules/ctools/plugins/content_types/block/block.inc).
Warning: Attempt to assign property of non-object in ctools_block_content_type_render() (line 162 of /home/scbe2c8d373036c1/www/sites/all/modules/ctools/plugins/content_types/block/block.inc).
Warning: Attempt to assign property of non-object in ctools_block_content_type_render() (line 166 of /home/scbe2c8d373036c1/www/sites/all/modules/ctools/plugins/content_types/block/block.inc).
Warning: Attempt to assign property of non-object in ctools_content_render() (line 289 of /home/scbe2c8d373036c1/www/sites/all/modules/ctools/includes/content.inc).
Warning: Attempt to assign property of non-object in ctools_content_render() (line 293 of /home/scbe2c8d373036c1/www/sites/all/modules/ctools/includes/content.inc).
damienmckenna’s picture

I'm also getting the following errors within the Panels UI after a bean block is added to a page:

Notice: Array to string conversion in drupal_validate_utf8() (line 1576 of includes/bootstrap.inc).
Warning: preg_match() expects parameter 2 to be string, array given in drupal_validate_utf8() (line 1582 of includes/bootstrap.inc).

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.

indytechcook’s picture

CTools is unable to handle blocks that are returned from hook_block_view as renderable arrays.

That makes me sad.

You might look at using http://drupal.org/project/bean_panels as it creates a bean ctools content type.

damienmckenna’s picture

I'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 :)

berdyshev’s picture

@indytechcook, yes, I saw. Can we merge its functionality into Bean module?

berdyshev’s picture

@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? ;-)

indytechcook’s picture

I 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.

berdyshev’s picture

@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.

damienmckenna’s picture

I 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.

damienmckenna’s picture

I added an issue for the error that's displayed in the Panels admin: #1925008: Errors when displaying beans in Panels

damienmckenna’s picture

Status: Needs work » Needs review

@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.

damienmckenna’s picture

StatusFileSize
new974 bytes

A 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).

berdyshev’s picture

I 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 label

damienmckenna’s picture

How 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.

damienmckenna’s picture

StatusFileSize
new1.18 KB

Oh, a patch would help X-)

berdyshev’s picture

don'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

indytechcook’s picture

I 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?

saltednut’s picture

Status: Needs review » Reviewed & tested by the community

Having a menu at admin/structure/block-types/config for things like this would be great.

This patch works perfectly!

saltednut’s picture

Suggestion: commit this, add variables to documentation, and then post a followup for the admin/structure/block-types/config as a new issue.

saltednut’s picture

Status: Reviewed & tested by the community » Fixed

Status: Fixed » Closed (fixed)

Automatically closed -- issue fixed for 2 weeks with no activity.