$info_split in search results does not have array keys on comments and uploads values

I fixed this by overriding the search.module's hook_preprocess_search_result(&$variables) function. (that is, I copied template_preprocess_search_result() from /search.pages.inc, renamed it "(theme name)_preprocess_search_result()" and placed it in my theme's template.php file)

The comment count seems to be a part of $result['extra'] (the attachment count is there as well), so what I did is just get the comment count and assign it to the right var...

if (isset($result['extra']) && is_array($result['extra'])) {
    // Get the comment count string.  We're assuming it's the first item in the array.
    $info['comment'] = $result['extra'][0];
    // Merge the rest into $info, just in case there's something else in there from a module
    $info = array_merge($info, $result['extra']);
}

...then I didn't have to do anything different in the tpl file.

Not really a very elegant, this is just a temp work around until this is fixed properly.

Bump. Same exact behavior on my end.

subscribing

Subscribe...

$result['extra'][0] ($info_split[0]) may end up being the info from the upload module if the comment module is not enabled.

This looks like a documentation problem to me. The search-result.tpl.php file should not mention $info['comment'] or $info['upload'] in Drupal 6 or Drupal 7. Please fix in Drupal 7 first, then back port to Drupal 6.

Hmmmm...

Looking into this a bit more...

It looks like http://api.drupal.org/api/function/node_search_execute/7 in D7 invokes hook_node_search_result() and adds it as component 'extra' to the search result item. In D6, this is done via http://api.drupal.org/api/function/node_search/6, with $op = 'search', and it invokes hook_nodeapi($op = 'search_result').

Then http://api.drupal.org/api/function/template_preprocess_search_result (D6 or D7) adds the 'extra' stuff to $info, which becomes $info_split.

D6 implementations: http://api.drupal.org/api/function/comment_nodeapi/6 and http://api.drupal.org/api/function/upload_nodeapi/6 -- so if you have these two modules turned on, you should be able to get the information from them in $info_split, as documented.

D7: There's no upload module. http://api.drupal.org/api/function/comment_node_search_result/7 works the same as in D6.

Ahhhhh. I see what the problem is. module_invoke_all() in d7, or http://api.drupal.org/api/function/node_invoke_nodeapi/6 in d6 is not making an associative array. So $info_split doesn't have 'comment' and 'upload' components to it.

This is actually a code bug, which I'm assigning to the node module, because that's where the hooks are defined. The hooks http://api.drupal.org/api/function/hook_nodeapi/6 (op = 'search result') and http://api.drupal.org/api/function/hook_node_search_result/7 need to return an associative array, with the module name and extra information, rather than a string. Or else they need to be invoked differently (i.e. not using module_invoke_all) in order to build an associative array.

Modifying title to explain what's actually happening

Here's a patch. I've verified that it fixes the bug...

I just encountered the same issue with D6. Is this patch against D6 or D7?

The patch is for Drupal 7.

#9: 253725.patch queued for re-testing.

#9: 253725.patch queued for re-testing.

Here is a reroll of the patch in #9, Still needs a review.

#15: 253725-reroll.patch queued for re-testing.

This is a D6 regression in the theming system. I think it qualifies as at least major.

#15: 253725-reroll.patch queued for re-testing.

I'm not sure if this can go into D7 now since some themes mat depend on the current, wrong, variables, but it should be considered and looks rtbc oherwise.

Calling this major is a bit too much of a stretch. Aside from that, I don't really see how this patch could negatively affect existing themes. Thus, ready to fly for me.

It looks like this does present a small API change, but looks to be a necessary one to get the code to actually function. Right now that comment stuff gets added to an index called '0', which is non-sensical.

Committed to 8.x and 7.x.

Sounds like there's still something to do here for 6.x too, though, but not the same thing. Marking 'active'.

.

We'd better leave this as 7.x until we announce this API change.

I think this needs a change notification, which we're de facto using for d6/7 changes as well as going forward (I'm adding a note to the 6/7 update page).

Restoring backport tag and setting active, which seems to be the status we're using now for change notifications.

And setting all the other fields too.

Bathie is working on a change notice for this at:
http://drupal.org/node/1433140

Revised the change notification, the example feels a bit ugly but I'm not sure what to put as a simple example. Edits welcome!

http://drupal.org/node/1433140

Well no one has weighed in with anything that might be missing, so I say this is fixed. Thanks @Cottser!