Come together with the global Drupal community in Rotterdam, 28 Sept – 1 Oct 2026. Sessions, contribution, connection, and Early Bird savings until 8 June.Search results are displaying html entities in comment author fields rather than the values they represent. apachesolr_commentsearch_node_to_comments() assigns this field after escaping it with htmlspecialchars(), and I'm guessing this escaping occurs again somewhere in the pipeline.
Looking at apachesolr_node_to_document() from apachesolr.index.module, the document->name field is assigned the raw value from node->name. I've included a patch that does the same for apachesolr_commentsearch_node_to_comments().
| Comment | File | Size | Author |
|---|---|---|---|
| solr_comment_name_html_entities.patch | 1.21 KB | kcoop |
Comments
Comment #1
jpmckinney commentedI can reproduce the problem.
You can't compare apachesolr_commentsearch_node_to_comments to apachesolr_node_to_document, as apachesolr_node_to_document uses the author's Drupal username, which we can safely assume contains no HTML special characters (usernames containing such characters are invalid). But a comment author's name isn't validated like a Drupal username.
Anyway, the problem is that
theme('username', $doc)inapachesolr_search_process_responseruns some comment author's names through check_plain, which double encodes the special characters. I'm not sure what is best to do in this case while still maintaining security. pwolanin should have a look.Comment #2
jpmckinney commentedComment #3
jpmckinney commentedComment #4
jpmckinney commentedComment #5
jpmckinney commentedAdd tag
Comment #6
jpmckinney commentedActually, it looks like theme('username') is safe, and it will check plain the user name.
Comment #7
jpmckinney commented