Search API token field processor

Thanks for suggesting this new feature!
However, there is a lot missing before I can commit this:

• Most importantly, I’m not convinced this will be useful for enough users to warrant adding this to the module. I’ll therefore wait until several more people have expressed interest/support or are following this issue.
• The issue summary isn’t very helpful like this. Please elaborate a bit, to enable others to find/understand your proposal.
• Like all new processors, this would need test coverage.
• Please do not use MRs in this project, as testing doesn’t work for them – see #3190024: Problem with test dependencies when testing issue forks. Please upload patches instead.

Thanks for adding the tests!
As mentioned, however, I’ll wait until more people express support for this before working further on this.

I'd like to see this feature. When using search API via headless Drupal, we can only get the URL to a media field with the normal image right now. This is useful for a search teaser image.

There's no clear way to get a URL for an image style from search results data which would be useful for a headless frontend so we don't have to fetch the large uncompressed image.

I would also be interested in this feature. Having image-styles out of the box would be very useful for all headless app using Drupal as a CMS. This wold negate the usage and integration of additional 3rd party image generation services. I've been using the media style patch for a few years now for this feature.

Thanks for all the work.

@naveenvalecha I am not sure what the process it or requirements to "review" and "test", but if you can let me know on here I'll see if I can help. thanks.

Working fine for me, looking good.

OK, especially when put together with #2962569: Index image style URLs it does seem like there is enough interest for this to go forward.
Attached is a suggested revision, where I more clearly describe the processor and field. In effect, it’s a processor/field that lets users index custom values, potentially containing tokens. However, I don’t think the previous description really made that clear enough to users not familiar with this ticket.

Still, I expect some confusion amongst users who just spot this field in the “Add fields” dialog, so any suggestions how to make the functionality clearer are welcome.

Finally, I amended the processor and expanded the tests to make sure this also works properly when multiple different types are indexed in the same index.

Please test/review!

Thanks for the test fix!

Nitpick: custom_value is a generic name. The custom value represents any string value that could be accepted, but we only allow tokenized text.

That was exactly my point: we don’t only allow tokenized text, entering a text with tokens in it (for whatever reason) would be completely fine as well.
If we later add options to specify different values per datasource or bundle, this could even become pretty useful completely without tokens.

Anyways, I’m open for other suggestions, but I don’t think we should focus on the tokens this much. First priority is to give users, especially inexperienced ones, a clear idea of what the field will do.
Does anyone else have an opinion on this?

#27 looks good
Thank you

Good to hear. Merged.
Thanks again, everyone!