UI improvements for the "View" tabs

Oops, didn't know there was a "Referenced by" list, too. Nice.

Attached is a first patch, revamping the server's "View" tab. The data is now (by default) formatted as a table and a new method, getExtraInformation(), provided for service classes to add information to that table.

One open question regards theming: there is currently a theme function for the server which renders the whole information (including the additional information from the service class). Therefore, the information can't really use table-specific formats but has to be generic, up to a point. I only added a new variable and changed the default implementation to now disregard some variables and display the rest in a table instead of a definition list.
The question is whether it wouldn't be better to just get rid of the theme function? I already did that for indexes in #2100199: Consider merging view, edit, settings (although I should probably have discussed this beforehand, too), since it gives us a significantly better control over how this should be styled, without having to be compatible with (maybe even existing) theme overrides. On the other hand, there might be some out there overriding this, who would miss that option. I'm no themer (by far), so can't really judge how useful those theme functions are.

In any case, work on the index's "View" tab is still missing – but the result will probably look a lot like the one for servers, with the data now displayed in a table.

Another open question is whether/how to display the service class description? Is that useful? I currently have a tag-stripped version in the mouseover for the service class, but that's a rather poor solution. I also experimented with making it hidden with CSS and only appear when hovering over the service class row, but that was ugly, buggy and on the whole too much effort for such a little detail.

So I think we should either rip it out completely (making it hard to get quick information on the service class used) or maybe let it be a footnote to the table. Or maybe some other option? A help page, maybe, which we could link from the service class?

Screenshots attached.

The first draft is now complete, with the index's "View" tab also overhauled, and some additional improvements to the server's view.

This is the normal view page:

When all items have been indexed, the "Index now" form becomes disabled:

An additional check was added whether the items actually available on the server match the our tracking data. If not, an additional row gets displayed:

There are several problems with this, though:

• Our tracking data only shows the number of items indexed in their latest state, while the server of course doesn't know which items are up to date. We can therefore only check whether a) there are less items on the serer than those that should be up to date, or b) there are more items on the server than there should exist in total. Otherwise, no error is shown.
• With Apache Solr, the warning could be displayed falsely, when the indexed items aren't up to date because of Solr's commit delay.

So this will likely need some enhancement before it can be committed.

The server tab now looks like this:

With the form at the bottom expanded:

One issue with this, as well as the index's similar buttons, is that they currently have no confirm form but execute the action right away. I guess there should be a confirm form?

The "Solr service" in the "Service class" row now links to a new help page I created for the Search API, which is automatically filled with the descriptions of all available service classes (a fragment is included in the link to point directly to the service class in question):

New patch, and accompanying screenshot.

This adds confirmation forms for all clear/re-index actions, and always displays the "Server index status" row (normally in green).

Oops, forgot to update the "clear index" test.

Thanks a lot for your input! Great that you took the time!
The option to have a "primary" button for a form was only introduced for D8 in #1238484: Ability to mark the form buttons to be of a specific type (so that they can be styled differently), so it's not available for us in D7. (Good to hear of it, though.)
I have implemented your other two suggestions, though, they do make a lot of sense. Especially the progress bar looks very nice (though I had to override the default style, since that has the moving background that is also used by the Batch API, which would have been extremely confusing here). I'm just uncertain whether we should duplicate the information like this. On the other hand, the "Server index status" would look rather out of place without the "Indexed items" row above it, so I'm leaving it there for now, unless someone else has a better suggestion. It's no big problem in any case.

So the blue button, was a regression https://drupal.org/node/2003908 - the CSS is still there, or rather should be. If not, you can indeed not use it. It is a bit weird we have a regression that is not fixed in D7 core.

That regression was only regarding an earlier D8 version – there is no concept of a "primary button" at all in D7, as far as I can tell. So, we indeed cannot use it, and I don't think we should add the CSS for that manually – since this concept is nowhere else in D7, it would probably confuse users more than it helps.
We already have confirm forms for the other two buttons, that should be enough to prevent accidents, I'd say.

1) I don't think we need to duplicate the index info can't you just remove Indexed items table row?

Of course I could. But as said, then the "Server index status" row would seem a bit out of context, in my opinion.
What we want to make clear here to the user is that the one count is the items that have been indexed in its latest state according to our information (tracking system), and the other is the count of items that can be found on the search server for this index (no matter whether in the latest state or not, as the server doesn't know that).
Do you maybe have some suggestion on how to make this clearer? And don't you think that removing the "Indexed items" row would make this more confusing to the user?

2) It feels a bit weird that there is a progress bar in between a table and a fieldset. Is it possible to just merge it with the fieldset?

Hm, yes, it does look a bit off. However, I'm not sure whether having the progress in the form would really be a better solution. The indexing status doesn't really belong under the "Index now" heading conceptually. Would maybe removing the fieldset wrapper from the "Index now" form help, to make it look more like your suggestion?
Or – a completely different idea – maybe moving the progress bar to the top of the page, right under the description (if any)? It could be considered the primary content of the site, the status of how far indexing has progressed. It also might alleviate the confusion of having it duplicated in the "Indexed items" rowm, since that's then separated from the bar by some other information.

3) For the progress bar you should probably use #0074bd and not the lighter blue.

That's of course easy to fix. Done. Thanks for the suggestion!

1) What about hiding Server index status, when nothing special is going on?

That was my initial plan – see the screenshots in #5. However, Nick Veenhof reviewed and thought displaying this always is clearer.
In the attached patch, this is now changed back to only show when the number is something other than the total item count. (This includes the case when not all items have been indexed, though. Or should it be only shown in the two error states?)
See screenshots:

2) Could you try both options? I think the "on top" works best but I am not sure.

The attached patch contains the "on top" variant (also depicted above, as you can see), the other would look like this:

(Why wasn't this set back to "Needs work"?!?)

Oops, forgot to update the tests checking for the index status. While at it, I also added tests for the server index status. Patch attached, should pass now.

Oh, and another question, just wondering about that now: is it really correct that we also display "View" in the operations in the Search API Overview? You can already go to that tab by clicking the server/index name, and I think usually "Edit" is the first option (and "View" not included). Should we still keep it or rather remove it?

We should probably skip it,

OK, good, was my feeling, too. Attached is a revised patch also fixing this.

What about the rest, is now everything OK for you? Would you still go with the progress bar above the table?

OK, great to hear!
Committed.
Thanks a lot again for all your valuable help!