The rich_snippets_default_preprocessor function assumes its getting passed node entity data, which isn't always the case.

There is probably a better way to do this, but for now, I've added a return if the node object isn't present inside the resultset.

Files: 
CommentFileSizeAuthor
#3 1923904-3.patch2.24 KBNick_vh
#1 1923904-search-nodes-only.patch731 bytesjaperry

Comments

Assigned:Unassigned» japerry
Status:Active» Needs review
StatusFileSize
new731 bytes

Below is a patch to check for the node object before printing node specific variables.

Good catch. Thanks for posting a patch, and I definitely want to explore ways to be non-node friendly. Would love to hear some ideas on how to proceed.

Chris

StatusFileSize
new2.24 KB

I don't think we should block on only node centric code. For example : http://nickveenhof.be/search/site/thesis
The first result is a file, and it still can benefit from some of the rich snippets markup if support is added to it.

Attached is a patch I'm using

I like this approach.

What happens when the apachesolr_get_index_key_map() returns FALSE? I want to make sure that use case is handled gracefully.

Thanks for the contribution,
Chris

since you have isset() in all the code that relies on the output of apachesolr_get_index_key_map, it is safe to return false.

Nick_vh's approach and patch looks good. Our use case with commons suffers from issues with Rich Snippets and Tika file search results. The patch provided by Nich_vh eliminates the assumption of node based result sets.

Status:Needs review» Reviewed & tested by the community

Excellent. Thanks for testing! Marking as RTBC.

Status:Reviewed & tested by the community» Fixed

Status:Fixed» Closed (fixed)

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