This excellent blog posts sums it up nicely:
https://world.episerver.com/blogs/Per-Magne-Skuseth/Dates/2016/1/episerver-find-index-blocks-in-xhtmlstring/
Thank you! This seems to work excellent for the pages. I however noticed a complication.
We have a page with a block (block 1) in a contant area. That block also has a xhtmlstring with a block (block 2) in it. Block 1 correctly doesn't index or show the block name for block 2 (after implementing the code from the blog post) however the page's search text still shows the block name from block 2. Any idea of how to fix this edge case?
You could override SearchText for the block, returning an empty string. If it's removing the block name you want to accomplish.
Doesn't help, the page json still indexes block 1 with the name of block 2 in the search text. Although if I look in the json for only block 1 it doesn't contain the name of block 2, but the real content.
Page 1 has a content area with block 1 in it. Block 1 has a tinymce that has some text and also block 2 in the middle of the text.
If I look at the json for Block 1 it's search text correctly contains the content from block 2.
When looking at the json for the page however, block 1's search text contains the name of block 2 instead. Shouldn't this be exactly what is indexed for block 1 separately?
I have a page with a TinyMCE editor, and in the middle of the text is a block. The block doesn't get indexed as blocks in content areas, but only the name of the block is present. This results in a weird unified search excerpt with the block name in the middle of the text, and also makes the blocks content non-searchable. Is this a bug, expected behaviour or have I just missed something obvious to make this work better?
Latest version of all EPiServer packages.