Drupal Association members fund grants that make connections all over the world.
Users have an expectation that when they go to Manage Displays for a content type, if they customize the "Search Results" view mode, it would behave similarly to what would happen on other Manage Displays view modes: i.e., it would customize how search results items are displayed. But it doesn't. (See the Original Report section below for a narrative illustrating this expectation.)
What happens instead currently (in D8 and D7) is that the Search Results node view mode is used to decide what is rendered from the node that is found as a search result. That rendered content is then passed to the search_excerpt() function to derive a highlighted snippet for the node. And that snippet is the main body of what is passed to the search-result.html.twig template (or search-result.tpl.php in D7), and displayed on the search results page.
Rename the Search Results view mode "Search Result Highlighting Snippet Input" or something like that (more concise!), to be less confusing.
Another thing that was discussed was exposing the snippet to Views as a "field" so that people can better manage the display of search results by making a Views-based search page instead of using the default. We can do this in a follow-up issue:
And while it would be great to actually let people add fields to the search results, that is also a follow-up issue.
A rejected resolution
a) There is actually not a strong need to have different content rendered into the search index and used to generate the highlighted result snippet (and you could make an argument that it's much better if they're the same). So, we can/should use the Search Index view mode to generate the snippet instead of having a separate Search Results view mode.Actually there is, see comment #117
b) We can then get rid of the Search Results view mode completely. (In Drupal 8, this definition is in core/modules/search/config/entity.view_mode.node_search_result.yml)
c) We need to expose the highlighted search snippet to Views. This will allow people who want full control over how search results are displayed to either:
- Use Display Suite (which apparently has this functionality) to govern how search results are displayed.
- Use Views to make their own search page with results formatted however they want with whatever fields they want.
- Do some programming in theme preprocess functions in a contrib module so that additional fields are added to the 'snippet' theme variable, and hence displayed in the output.
Other rejected resolutions
Ideally, it would be nice if the display of node search results was governed by a Manage Displays setting, so you could display fields with your search results (such as a thumbnail image). However, this might be difficult to accomplish, because much of what is currently being displayed by the result template file (or at least has the potential to be displayed) is not node fields at all, but "pseudo-fields" like the excerpt with keywords highlighted, the URL, the formatted user name of the author, the displayed name of the content type, the search score, etc. So there are a couple of ways this might be resolved:
1. The "pseudo-fields" could be added somehow to the Manage Display configuration screen. This doesn't seem all that feasible though. The way Manage Display works is that for each entity type (e.g., "node" in this case), you can define "extra fields" using hook_field_extra_fields(). But they apply to all display types -- there doesn't seem to be any way to define extra fields that are specific to one particular display type, and also the keys of the returned "extra fields" have to correspond to things that are present in the render array for the entity. So if we did this, we would I think lose the ability to have the existing search results stuff.
2. There could be a checkbox somewhere that gives you a choice, when a search result is being displayed, of either displaying the keyword-highlighted excerpt or the node rendered with your choice of display type. This output would then be passed to the search-result.tpl.php in the "snippet" field, as it was before.
3. There could be a way to use a display setting to add additional fields to the search output, which would be passed to and displayed by the search-result.tpl.php file in addition to what is there now. This is probably the most feasible option, but it seems like if we have good Views integration, we can just have people use Views if they want more customization and leave it at that.
Make a patch that renames the Search Results view mode so it is less confusing.
User interface changes
- The Search Results view mode will be renamed to something less confusing.
Original report by RobLoach
There is a "Manage Displays" setting page to customize the Search Results page to show which fields will be shown on your content when someone searches for them. Unfortunately, it does not actually reflect what is displayed to the user.
Steps to reproduce
- User wants to customize the search results page for their node "Test #3":
- They visit the Manage Displays page for their article, use a custom display settings page for the Search Results at admin/structure/types/manage/article/display/search_result, and set up their Articles to have the needed fields on the search results page:
- Satisfied with their changes, they make a search, and see that managing the display of the Search Results doesn't actually manage the display of the search results:
Am I missing something in this workflow, or does this seem like an oversight for the search results page? Is theming search-result.tpl.php still the only way to do this?
PASSED: [[SimpleTest]]: [MySQL] 40,911 pass(es). View
|#135||drupal8-rename_view_mode-1166114-135.patch||508 bytes||Rajendar Reddy|
PASSED: [[SimpleTest]]: [PHP 5.4 MySQL] 68,359 pass(es). View
|#134||1166114-rename-view-mode-134.patch||496 bytes||Rajendar Reddy|
PASSED: [[SimpleTest]]: [PHP 5.4 MySQL] 67,978 pass(es). View
FAILED: [[SimpleTest]]: [PHP 5.4 MySQL] Unable to apply patch 1166114-rename-view-mode-128.patch. Unable to apply patch. See the log in the details link for more information. View