Some random bugs

1) If the index is defined in code, it doesn't find any nodes (says 0). Once I edit it and it gets saved to the DB, the node count appears.
2) When exporting an index, it looses the checkboxes of which fields are indexed. The others stay.

As you may have noticed by now, I really have no clue about exporting. The first one sounds like what we talked in the other issue about, $entity->save() being called when an entity is newly added in code. Could that be it? What could be wrong for 2)?
And how do I even test exporting the best way?

3) A number field indexed as decimal. If there is no value for the field (or maybe a node without the field at all?), indexing in solr fails and in the log there is a java exception (numberformatexception) empty string no valid number.

Does the attached patch fix this (and other issues here)?

4) Include "missing" facet option in the block configuration does not save. Should be off by default too?

If it had just been that! On testing this (and looking at the code), I noticed, that not a single custom block option is saved, I completely forgot the necessary code. Yeah … …
But the attached patch should fix this, too, thanks for spotting it!

5) Fulltext: Whether field should be indexed in the fulltext is something different than how it should be indexed at all. Eg. we want to index term-names as "string", but have it in the fulltext too. Ergo, I think fulltext should be a separate checkbox.

As I already said, I'm gonna redo the "Fulltext field" data-alter callback anyways, to no longer use this admittedly ugly behaviour. So this should then be obsolete, if I understand this correctly.

6) When editing the full text views filter: "Search keys – multiple words will be split and the filter will influence relevance. " should be enabled by default I guess.

You're right, that bothered me, too … And now that I have an issue to link to (;)): done, in patch.

7) Some direct links to the index tab in the overview UI would be nice. lots of clicks necessary.... ;)

Same as above – but I don't really know how to do this. Adding all tabs in the "Operations" column probably won't fit – and also, servers would look odd, then.

8) Index just the entity view as fulltext.

What do you mean?

Additionally I think the current approach of initializing 'search_api_item' once the index has been created (on 'insert') doesn't work for exported entities, as hook insert is not called on a system with an index living in code. It get's only called if someone overrides the entity later on.
Indeed, the lifecycle of configuration items isn't ideal yet and needs to be improved in order to for use-cases like yours being possible cleanly. As interim workaround I'd suggest to implement hook_modules_enabled() + determine whether the module provides default configuration for you + if so, initialize it.

That's why I asked in #939482-16: Fix exportables whether save() is called for entities in code – if it isn't, this is indeed a problem … Is there really no other way than this ugly hack, then? And how does a module provide default configuration?
But of course you are right about search_api_entity_update(), missed the direct db query there (and in search_api_entity_insert()).

Regarding the others: Working on it. "tokens" is correct, though, it is a custom type introduced by me (for tokenized fulltext), before you introduced "token". I don't use "token" at all, since it's called "string" in the Search API.

OK, I've lost track a bit, hope I don't forget anything …

ad 1) OK, then I'll try to implement that hack … But first a patch for most other bugs here, if it's OK I'll commit it and then work on 1).

ad 4) Works for me, no idea what's wrong on your side. The attached patch contains a cosmetic change in the logic, but behaviour is identically correct both before and after the patch, for me.

ad 7) Those would a) be really many (6 or 7 links?) and b) there wouldn't be a clean way to add the "Facets" tab as well.
As an alternative I tried adding contextual links, but after some ugly code-crawling I discovered that the module is, in its current state, obviously not fit to be used by anything other than core. Ugliest hardcoded stuff, there …
But what about implementing a similar thing myself? Shouldn't be too hard – then there still would only be three links, but with Javascript enabled, a click on "edit" would open a selection with all tabs (other than "view", of course).

ad 9) As I told you, it should be taken into account (e.g. for user roles it works), it apparently just doesn't work in all cases. I now discovered that this is caused by two seperate bugs – one in my module (not adding the index' property info alter method, therefore fields on bundles weren't even found) and one in yours: #963218: Options list for multi-values custom fields behaves oddly. My bug is fixed in the attached patch – your turn. ;P

ad 10) OK, this is a bit of a mess, there are several issues here. First, I think I didn't clear the block cache quite correctly, previously. I also only now added a check when viewing a facet, that it is enabled, before proceeding. But still, this only hides the underlying bug in the block module – because, even though the block isn't displayed on the block adminstration page, I cleared the cache, and whatnot, the block is still displayed (without my $facet->enabled check, that is). And that can't be right. (At least since I specified DRUPAL_NO_CACHE as the caching strategy.)

Sorry, I still can't reproduce this. I now have three facet blocks for term fields, two on the same field and one on another, and I still can't do anything to make this not work. I even discovered a Field UI bug in the progress …

I now committed the patch so far, but as said will continue work on 1), and 9) is up to you. For 10) you could provide more detailled steps, but possibly you'll have to debug it yourself, when I can't reproduce the bug and have no other clues. That the two blocks have the same type shouldn't matter at all. And just searching through the whole module for any bug would be a bit tedious …
You could e.g. look if the facet is saved correctly, what search is executed and if the results are correct (especially, of course, the "search_api_facets" component).

oh, and if I clear the cache get those:

    * Notice: Undefined index: name in block_menu() (line 147 of /var/www/fago/web/recruiter/modules/block/block.module).
    * Notice: Undefined index: name in block_menu() (line 166 of /var/www/fago/web/recruiter/modules/block/block.module).
    * Notice: Undefined index: name in system_menu() (line 638 of /var/www/fago/web/recruiter/modules/system/system.module).

This seems to mean that you have a theme installed that doesn't define a name, looking at those code lines. I highly doubt that this has anything to do with this module.

The attached patch solves (at least it seems like it, according to my tests) a good amount of 1).
A mechanism for detecting changed hook_default_search_api_index() implementations is missing (and not possible in this way), though – people would have to disable and re-enable the feature module for this to work. A solution from the Entity API would be nice, therefore.

I'm gonna try the JS-edit-menu thing now …

And this one also incorporates a nice (well, at least not too shabby) edit menu for getting directly to individual tabs (even "Facets") from the overview.

Oh, and both patches contain a fix for most of the duplicate hook invocations (search_api_[server/index]_[insert/update/delete]()).

hm, still for $op != 'edit' both hooks are invoked? I'll guess the only way to fix this and to keep $op is overridding the controllers invoke + save methods... so that's still open, but no cause to halt this patch.

Yes, you're right, I'll have to fix that at some point. Went for the "quick-and-dirty" fix for now … Therefore, new issue: #964816: Provide own EntityController for fixing hook invocations.
Anyways, committed, thanks for reviewing (and finding the bugs to begin with)!