Add improved UI help for determining which fields are available for sorting

I don't think this is possible, at least not without some custom code. You can't mix the entities listed in a Search API view – when you have a taxonomy term index, there will always only be taxonomy terms listed.
While you can show the nodes related to a taxonomy term (at least if it's a reference with correct metadata), there is no way to order them. This would have to be done in custom code, I guess.

If you do this in a custom way, you should wait for #1231512: Use real Relationships instead of level magic in Views integration, though, because this will change some of the internals (and also some options, etc.).

@colle901 - You client amy not need this, but mine does! In my view, I only seem to be able to add sorting criteria for relevance, but I need to be able to sort on other indexed fields too. For example, I'm indexing Commerce Product display nodes, and have indexed the price field on the Commerce Product, but in my View, I am unable to select this as a sorting option. Could it be because the price fired is on a related entity rather than the node entity that is actually being indeed? I've added the relationship in my View, and the related field is being indexed by search_api.

It might be because either the price field or the relation to the product is multi-valued, in which case sorting is not possible. You could get around that by using the „Aggregated fields“ data alteration with (e.g.) a „Min“ aggregation on the price.

@ colle901: Please don't mark issues as „closed (fixed)“ directly, just as „fixed“.

Using an aggregate field on the Commerce PRice worked for me. Thanks.

I'm looking for this as well, cant get any alphabetical sorting to work, just node id. I want to sort by indexed taxonomy terms on the a node but maybe its not possible?

From what I can see, in order for an indexed field to be available as a sort option is must not be of type "Full Text". For example, I can set the core node "title" to be indexed as "string" instead of the default "Full Text" and then it appears as a sort option.

Is this by design?

It also seems that this issue may be closely related to #1372794: How to sort result with table headers, which discusses sorting limitations for view tables. I'm guessing the same mechanics are at play there too in terms of various indexed field types and their availability as sort options.

Is this by design?

Yes, it is. Internally, fulltext fields are tokenized to make fulltext searches on them possible. That means, the way they are stored resembles a multi-valued field – and sorting on multi-valued fields is conceptually impossible (or, at least, arbitrary).

I have added this question to the official FAQs, hopefully this will answer all questions.

However, I realized I currently actually don't mention this anywhere in the UI or the documentation, at least as far as I can see. That's of course a major shortcoming, how are users then supposed to know?
Also, there currently isn't really a way to tell whether a field is multi-valued directly in the Search API.
The attached patch is an attempt to fix both of these shortcomings at once. Please test/review, especially whether you think the UI is clear here. (And whether you think themers will want to kill me for this.)

(I'll just have to remember to update the FAQ page if this gets committed.)

Thanks, this is a great UI enhancement. The patch looks good and the changes seem to work fine... it even detected several multi-value custom backreference properties that I have setup in my test environment.

Even with these text additions I suppose you may still get questions about this popping up in the issue queues (as people may not be confronted with the sorting limitation until after they leave the search API fields configuration page and are in the views UI), but there's really only so much you can do about that.

OK, great to hear. Thanks for testing!
Committed.