CCK Blocks breaks $node->build_mode in page.tpl.php

Hi Einkahumor,

This part of the cck_blocks code is from before my time with the module, but I did some investigation and it looks like cck_blocks is properly using build_mode like it's intended. The reason you are seeing it as 0 sometimes is because core uses 0 for BUILD_MODE_NORMAL. See http://lists.drupal.org/pipermail/development/2009-May/032955.html for a discussion of why this is not a good thing.. the main reason being that an empty string in PHP will also evaluate to 0 if you use "==" rather than "===" for your comparisons.

In hindsight, BUILD_MODE_NORMAL should have been defined as a string or something that doesn't == 0. Most contrib modules use a string for their build modes, and you declare which ones you're going to assign in hook_content_build_modes(). Cck blocks only defines one build mode, cck_blocks:

/**
 * Implementation of hook_content_build_modes().
 */
function cck_blocks_content_build_modes() {
  return array(
    'cck_blocks' => array(
      'title' => t('CCK Blocks'),
      'build modes' => array(
        'cck_blocks' => array(
          'title' => t('CCK Blocks'),
          'views style' => FALSE,
        ),
      ),
    ),
  );
}

This hook comes from contrib CCK in Drupal 6, and is not documented anywhere that I can really find other than here in some of the Display Suite community docs: http://drupal.org/node/697320#hook_content_build_modes

In any case though, it appears CCK blocks is using it correctly. I'm not sure why your $node object in Garland is showing you the build_mode of the cck_block. I would explore what else is in that $node object (maybe enable devel module and dpm($node); where you are doing your printing) and see if you can figure out why it's not what you're expecting to find. You may have to dig deeper into how Garland theme is providing $variables['node'] to your page.tpl.php, or find a different way to do what you are trying to do (ie. branch your logic off something other than $node->build_mode if that property will always show the last block built, which is likely what's happening I think).

I've set this to closed (works as designed) for now, but feel free to reopen if you can spot something cck_blocks is doing incorrectly or can identify a bug we can fix on this end.

Yes, I think that is supposed to be what happens.. cck_blocks only runs when outputting its block and it builds the node view in the cck_blocks build mode so that you can set the display settings differently for how a field shows in a cck_block vs. in the main content region. I'm no expert on this unfortunately, I would guess that you are just seeing the last $node that Drupal processed in page.tpl.php. If the last block that was built was a cck_blocks block, then that is maybe why build_mode == 'cck_blocks' is what is left behind.

$node itself in page.tpl.php can be set/overridden using your theme (or the base theme's) theme_preprocess_page I think. Each of your theme_preprocess functions gets a $variables passed in as an array, and then each element in that array gets set as a $variable in the template. (e.g. $variables['node'] becomes $node in page.tpl.php).

Zen's page.tpl.php says this about $node:

 * - $node: The node object, if there is an automatically-loaded node
 *   associated with the page, and the node ID is the second argument
 *   in the page's path (e.g. node/12345 and node/12345/revisions, but not
 *   comment/reply/12345).

So that to me sort of sounds like it's saying that is "whatever $node object is lying around associated with this page". Looking at the cck_bloocks source, I'm guessing the culprit is one of these three lines, though looking at those functions in the API I don't see any of them setting a build_mode, but they do call child functions:

  // Get the currently viewed node.
  $node = menu_get_object();
  // [ ... ]
   // build the node in cck_blocks mode if that hasn't been done yet
    if (!isset($built_nodes[$nid])) {
      field_attach_prepare_view('node', array($node->nid => $node), 'cck_blocks');
      entity_prepare_view('node', array($node->nid => $node));
      $built_nodes[$nid] = field_attach_view('node', $node, 'cck_blocks', $node->language);
    }

I don't see why any of those functions would be changing $node, but why don't you try the following two hacks to see if one of them fixes things for you. We should try setting that $node to a copy of $node that isn't the main one being used. (the downside to this is it's inefficient.. if this fixes it for you we should try and figure out how to not make it happen rather than use this approach).

So, try changing line 72 ($node = menu_get_object()) to:

  // Get the currently viewed node.
  $orig_node = menu_get_object();
  $node = node_load($orig_node->nid);

That should give you a totally separate $node from the one going through the theme system.. so then it would stand to reason it would no longer have a $build_mode == 'cck_blocks'. But anyway, I'm not really sure what cck_blocks could do differently to avoid that, while still having its own build mode. Is there some other logic you could use to determine you are on a node view page? Like checking the path, or maybe doing a $node = menu_get_object() of your own and looking at that $node?

Just some ideas.. let me know what happens when you try that node_load trick!