Problem/Motivation
Search API already offers a possibility to use formatted text when indexing, namely through the "Processed text" (text:processed) field element. However, the formatting is "fixed" to the formatter assigned to that element and can't be configured on a search index basis.
Proposed resolution
Add a processor TextFormatter that allows the user to select any of the existing entities of FilterFormat (including custom ones) and apply it using check_markup().
Remaining tasks
- The patch is ready for review.
- Unit tests need to be written.
User interface changes
Processor configuration pages have a new processor entry available with an option to select the filter format to be applied to the element at index or search time.
API changes
None
Data model changes
None
Comment | File | Size | Author |
---|---|---|---|
#2 | 2943295-2.patch | 1.95 KB | davidum |
|
Comments
Comment #2
davidum CreditAttribution: davidum commentedPatch attached
Comment #3
drunken monkeyApart from a few code style issues, this looks pretty good, thanks!
However, what's the use case for this? I wouldn't think there's much demand for this feature.
I think for now I'll leave this issue open and see whether more people express interest. I generally like to make sure new features will actually be used, otherwise we end up with huge swathes of code that almost no-one really needs.
Also, as you say, this still needs some test coverage (both a Unit test and in
ProcessorIntegrationTest
). But as long as it's unclear whether the patch will be committed, you might as well hold off on that for now.Anyways, thanks again for posting this!
Comment #4
borisson_I also fail to see the usecase for this particular processor, I guess it can't hurt to be more strict in the html formatting being inserted into the search index and using a filter format processor to do this. However, that's why we have the html filter already.
If we can find a good reason to add this code, (and thus the "burden" of maintaining it for the upcoming future), I also have some nits to pick over the code.
But as @drunken monkey monkey said, let's get a good usecase first.
Comment #5
borisson_Setting this to Postponed until we find a good reason to do this.
Comment #6
drunken monkeyClosed due to long time without response.
Please re-open with the requested information if still relevant.