Bug in check for content type

whoops- this bug is actually fixed by this commit to the cvs, but I neglected to post a proper issue to reflect it. I'll plan to roll up a new release for this module shortly. In the meantime, changing the one line above fixes this bug.

looking at this more closely, I realized that this is not actually a duplicate, but rather the *reverse* of this bug, and is thus already fixed.

the node_get_types() call returns an array keyed by node *type*, which is the same type value stored in the $node->type object field. the array_key_exists() call is therefore appropriate, and when I switched it back to an in_array() call on my test site, the related_links block disappeared.

@nath: can you confirm that you either reported this backwards, is not really a bug, or is perhaps some eccentricity with your particular installation?

ok this is very bizarre- when I print out the $types array by adding lines like this, just after the call to node_get_types():

ob_start(); print_r($types);
drupal_set_message("node_get_types(names): ".ob_get_contents()); ob_end_clean();
drupal_set_message("node->type: ".$node->type);

I see the following:

    * node_get_types(names): Array ( [page] => Page [story] => Story [weblink] => weblink )
    * node->type: page

I've also checked this to see if the result is the same when there is no "related_block_types" variable set- the array looks basically the same either way. Is it possible we have a version mismatch somewhere, perhaps?

ah-ha! now we're onto something- I did indeed have a contrib content type 'weblink' enabled, by virtue of having installed the links package. when I disabled that module, and then added "page" and "story" to the related_block_types variable (from the /admin/build/block/configure/related_block/0 page), a node view with (a slight variation of) my previous debug code reproduced your "version" of this bug:

    * types: Array ( [0] => page [1] => story )
    * node_get_types(names): Array ( [page] => Page [story] => Story )
    * node->type: page

it appears the real bug here is hidden in the variable_get() call's arguments, which do not return the same type of value (thus causing the if statement to fail in some cases, pass in others). so we need to normalize the arguments here, so that the testing condition will yield the correct result for all cases. i see two options:

1) fix the return value of the node_get_types() call, so that it matches the format of the array stored in the 'related_block_types' variable
2) fix the 'save' subhook in hook_block, so that it stores an array similar to the return value of the node_get_types() core function.

the second seems simpler and wiser since there are multiple calls to variable_get that would need to "normalize" to a core function's return value. i'll try to whip up a patch later on, but if anyone else wants to throw one out, feel free! :)

ok i've done a fairly major overhaul of hook_block here, and everything appears to be working for me, whether i have set the related_block_types variable or not. the one significant change here is that i've made the default behaviour to show the related_block for *no* node types at all, in order to be consistent across the board.

previously, the block would use *all* node types by default, but if you saved the block configuration with no types selected, it would change to using *no* node types. this means that users will need to explicitly go to the block configuration page to select which node types they want to be used. this was a slightly easier way to go than making the default be all node types, but if people feel strongly this is a better default, we can rework this a bit.

@nath: let me know how the patch works for you :)

Subscribing.

I'd be happy to test a beta version of a new release of this module.

-- Doug

Been committed. Sorry about the delay.