What is the best way to create a view to search indexes with search api supported options? I'm using views to search indexes but running into some issues. I'm not sure if it's because of my lack of understanding, a bad configuration or bugs so I'll explain what I'm doing and what's happening.

I've created two different views to compare functionality.

The first view is created by first selecting the index (Cluster (index:articles)) (see Screen_1). Upon creating this view I have the options to select ES and global fields/filters but not "search api" fields/filters (see Screen_2). For instance, I can't see a Entity HTML output (indexed) field. I also cannot see the spellcheck option in the header section nor do I see any query settings. So I use ES: Search (AND ) as the searchable exposed filter.

The second view is created by selecting "Multi_index search" (via its respective module). Upon creating this view I see various Search API Views fields/filters that I didn't before. In this view I can see an Entity HTML output (indexed) field. I also can select spellcheck in the header (although that returns an emtpy 500 error) and when clicking query settings I get an empty 500 error. So I use Search: Fulltext search (exposed) as the searchable exposed filter.

Please excuse my mention of the bugs I'm experiencing but I'm trying to simply ascertain what I may be doing wrong or where things might be going wrong elsewhere (in code) and then move on from there.

Thanks for any help!

CommentFileSizeAuthor
#2 Screen_2.png133.54 KBpribeh
#2 Screen_1.png134.03 KBpribeh

Comments

pribeh created an issue. See original summary.

pribeh’s picture

StatusFileSize
new134.03 KB
new133.54 KB
mparker17’s picture

Component: Elasticsearch Connector Views » Code
Assigned: pribeh » Unassigned
Status: Active » Fixed

@pribeh, I apologize for the time it has taken for this support request to be answered.

The currently-supported versions of Elasticsearch Connector (8.x-7.x, 8.0.x, and 9.0.x) all use the Search API module as a backend, so you can use it to define what gets stored in the index (i.e.: what search queries match against), and also what gets displayed on the in the search results page.

When you're adding fields to be indexed, you should see an "Expand" button next to rich text fields (like the Body field for example). If you click that button, you can see some sub-fields to index the Processed summary, the [raw] Summary, the Processed text, etc. For example, on my test site, nodes have a "body" rich text field so the "Processed text" sub-field has the machine name body:processed). If you click the "Add" button for that sub-field, then the data in that sub-field is stored in Elasticsearch's index (i.e.: and search queries can match against it).

If you're using views to set up a search results page, and you've indexed the Processed text sub-field as described in the previous paragraph, look for fields that end with "(indexed field)" in the "Content datasource" category (on my test site, the field had the full name "Body » Processed text").

If you need something more sophisticated, and you're willing to write and maintain custom code, Search API and Elasticsearch Connector allow you to alter search results before they're displayed - for example Search API's ProcessingResultsEvent and/or Search API Processor plugins are able to modify search results returned by the index.

***

Unfortunately, the elasticsearch_connector-7.x-1.x release series is no longer maintained (and, at time-of-writing, only 46 sites report using it). Also, this support request hasn't been updated in ~10 years. And, Drupal 7 core is no longer supported.

So I'm going to close this issue and assign credit. If you have further questions about supported versions of this module, please create new support requests!

Thank you for your understanding and patience as I try to make the issue queue for this module more maintainable!

Now that this issue is closed, review the contribution record.

As a contributor, attribute any organization that helped you, or if you volunteered your own time.

Maintainers, credit people who helped resolve this issue.