search_index isn't an option for content preview

Should be a simple fix in the merge request

Here are some tickets where this appears to have been tweaked/altered

#2322503: getDisplayModeOptions() returns only full or teaser regardless of the status of the entity display →
Added in #1510544: Allow to preview content in an actual live environment →

From what I can tell search_index was mentioned twice but not really discussed. Personally don't see a reason not, it's 100% front-end view.
Change also seems small enough that probably doesn't warrant test coverage. Also we never hid search_result so not sure why to hide this one.

I applied the MR and confirmed search_index now appears.

Search index isn't a front end view, it's what the search module sees when it indexes content. You could have a 'search result' view mode for use with search_api module or similar but that wouldn't be the same as the one for indexing.

I don't have a strong opinion on showing it or not, but I think we could use a product or UX review here given that was the original reason for hiding it.

I agree with catch, this is not simply for frontend usage. However it might be useful to help figure out why some entity is not indexed into search api correctly.
It doesn't look like there's an easy way for search api to reenable this for those purposes?

Yeah I don't disagree with classifying search_index as not strictly a frontend view.

I think what I was trying to convey in the summary was that while Drupal we called the preview interface "Preview in live environment" in the original issue, but that is in no way conveyed to the site user. To a developer and content editor its just "Preview" so seeing how something will be pushed into a search index can provide a lot of valuable information.

So limiting the interface to strictly frontend displays doesn't always meet user expectations. At least it didn't meet mine.

I wonder if we could hide this behind "Administer search" permission so that this wouldn't be visible to people who can't actually make changes to search?

I think that's a good compromise

I'm not sure about this. Administer Search is from the core search module. Search API doesn't have that permission, but it does have a Search index view mode as well.

How would we, as search API maintainers, allow this to work without asking people to enable core search, just to get that permission.

Oh I didn't think about search API...

Not sure a good middle ground now.

Need to understand what an acceptable solution here would be, or close as won't fix.

ugh, fighting with this again this week. Have to mock up a search indexing operation and xdebug to figure out why something wasn't going into the index correctly rather then just previewing and seeing what template was getting picked up. That's annoying for me, but we're going to have content editors working with the changes we're making and I have to explain it to people that "sorry, you can't preview how your content is going to be seen by search" which is going to be very unsatisfying for them.

Hope we can come up with a solution.

</rant>

borisson_ obviously is the expert on SearchAPI but I'm not sure if this _actually_ affects the module. Writing this I realized core just might be providing a trap for SearchAPI users and this is a bit of a problem of my own making. I used the out of the box `search_index` mode because it just made sense, but when choosing the rendered option in SearchAPI I can actually chose any display mode. So I could make `sapi_index` and label it "Search Index" and this whole problem probably goes away for me at least in the context of SearchAPI.

So I wonder what the point of the permission even is. Maybe there _should_ be some sort of generalized permission for display mode previews but are we concerned something might be leaked that's going into a search index specifically? Conceptually its information that's going in a publicly searchable location so you wouldn't put privileged information in it except for in very rare situation of internal or gated searches but even then the publisher's going to have access to the fields.