Select Text Format in Views Field for textual content with values from search index

The patch in #35 works as expected, but I'm a bit reluctant to render HTML content with the xss_admin filter (should be safe, but could still allow huge images, etc, that break layouts...)

I didn't dig too deeply, but is it possible to instead simply use the format that is stored with the text field value? This presumably gets indexed, but perhaps not?

Somewhat related here, what's particularly odd about this behavior is that correct formatting is used if a highlighted search term is in play (the associated filter format), but when no highlighting occurs, the default xss filter is used, stripping tags such as <p>...

Possibly related, the issue I found yesterday was that our results would show the HTML formatting, and would show highlighted search terms, but it would lose the spaces on both sides. So "this is bold text in the middle of a sentence" would become "this isbold textin the middle of a sentence."

What I discovered is that it did that if the setting on the field in the view for "use entity field rendering" was unchecked, I got this behaviour with losing spaces. If I checked "use entity field rendering", the spaces would be maintained, but I lost the search term highlighting. For now I've opted to maintain spaces at the cost of highlighting, but it would be ideal if we could have both.

I figured out why when text fields are highlighted that this isn't an issue. It turns out that xss_admin is being used anyway for highlighted fields. In SearchApiFieldTrait::combineHighlightedValues:

    // Pre-sanitize the highlighted values with a very permissive setting to
    // make sure the highlighting HTML won't be escaped later.
    foreach ($highlighted_values as $i => $value) {
      if (!($value instanceof MarkupInterface)) {
        $highlighted_values[$i] = $this->sanitizeValue($value, 'xss_admin');
      }
    }

This would be a great enhancement of Search API and Views integration, thanks to everyone here for working on it. It works well, and here's a re-roll. I guess we're still waiting for tests?

@ressa, thanks for the re-roll. The patch works for my needs and I agree this is a great feature to have for a fast and interactive search experience.

Let's finally add this cool feature to the module. It is really helpfull. Used patches from this issue in a lot of projects :)

Also, I like descriptions to the options this is very informative.

Works well for me - lets add this! +1!!! :)

This patch really is essential for nearly all my systems and I am really tired to apply it every time. Can we please add it? it works great!

I guess we already have a test, so we're no longer waiting for that, we should make this into a merge request to see if the test actually passes.

This patch really is essential for nearly all my systems and I am really tired to apply it every time. Can we please add it? it works great!

@knurg, this issue is in the "needs work" status, for it to be committed, it should at least get to the "Reviewed and Tested by the Community" status.

A comment like the ones in #42, #43 and #44 could also put this into rtbc, if you feel safe enough that this will not break any other installations of the module.

So in this case the next steps are:

• Make the patch into a merge Request
• Get a code review on the code and tests
• Get this into RTBC state

I've done my best :)

Thanks @knurg!

Looks like the latest merge request broke all tests, because of a missing ".ignored-deprecations.txt", I don't think this is because of this MR though. I wonder if this is something more general that's going on. I asked in #gitlab on Slack.

Pipelines now pass again, thanks!
I just added return type hints to the new methods.
If a few people could give this a try and tell us whether it still works for them I can merge it.