I'm using hook_ds_fields_alter() to override a few DS fields. Specifically block fields I created based on Views. I'm using the code http://drupal.org/node/700056 (Override block field through code) to pass the nid of the node to my block view DS field as an argument. (I'm writing article on how to do this ;-D) I'm using the exact same code but with different DS field names in the array keys.

In render_view_block_arguments() I'm programmatically calling my view, yet my view isn't getting displayed. A quick dsm() of $output = $view->execute_display($display_id); shows that $output is NULL.

Weird thing is that I did this before and I got it working without a hassle.

I started digging and I traced the problem down to this issue.

In render_view_block_arguments(), You'll find this piece of code a few lines higher:

 list($module, $delta) = explode('|', $field['properties']['block']);
 list($name, $display_id) = explode('-', $delta);

A dsm() showed me that $field['properties']['block'] can contain these use cases:
1. Nice readable strings like views|nodequeue_2-block or views|frontpage_expositions-block_2.
2. Ugly strings like views|d2ca50b41deedb17b730c91ac6800a06

The second part of the ugly string is actually an MD5 hash generated by Views. The culprit is views_block(). Around line 335 in views.module you'll find this comment:

      // block.module has a delta length limit of 32, but our deltas can
      // unfortunately be longer because view names can be 32 and display IDs
      // can also be 32. So for very long deltas, change to md5 hashes.

So, the solution here is to keep your block name in views as short as possible to avoid the 32 chars limit.


swentel’s picture

Status: Active » Closed (fixed)

haha, had the same thing yesterday, knew immediately that views was the problem here :) I've added a link to this debugging info on the documentation page underneath the Override block field through code section. Thanks! Can't wait for the article :)