Seperate filters/processors by stage

How far are you on this? Do you still have time to work on it? Otherwise, please post a patch (or create a branch) with your current progress!

Great job so far, thanks! You are right, the getProcessors() method is a mess, that should definitely be refactored. But that, as well as UI tweaking (e.g., I'd love to see the three stages lined up horicontally, to a) better visualize the workflow and b) save space – but that would probably also need some responsive-design magic, so nothing we have to or should hurry) can be done in follow-up issues, I think.

This, in any case, is how I'd imagine that form:

Apart from that:

1. As said, I really don't think we should make it possible to switch processors on/off by stage. I can't imagine a use case for that for any of our processors, and if there's one for a contributed processor, that processor can just display its own option for that. Moreover, some of the processors won't work properly if not enabled for all their stages, without it really being apparent to users – we can't let users make that decision, when only the most experienced ones will really be able to understand it.
2. The current UX for this – enabling enables all stages, disabling only the one –, while it makes sense and is a handy shortcut, is also very confusing when you see it the first time, and I can predict that there would be issues caused by this.
3. However, thinking about it a bit more – what are even the use cases for re-ordering the processors per-stage? Are there really instances where this makes sense? Since this wouldn't really be possible to change for a custom processor itself, I'm more inclined to add this feature than the per-stage enabling, but I'd still like to have some vision for features, not just add them for their own sake. Especially since this makes the "Filters" tab even more complex.
4. Even if we allow no per-stage configuration, having each processor's stages still makes sense: for displaying it to admins, for moving field-only processors to the "Fields" tab and if we want to implement #1720348: Add the concept of query extenders.
5. In any case, I'd vote for a fourth stage, add_fields. Only ever makes sense in combination with preprocess_index, of course, but would allow for moving the fields-only processors. However, re-ordering for that stage would of course make even less sense than for others, so we shouldn't make that a displayed stage (just maybe some indication to admins which processors add fields).
6. And one thing that definitely needs to happen is adapting \Drupal\search_api\Entity\Index::preSave() to this change so the "Language" processor is always enabled again.

@ Nick: It would be great to get your feedback on this.

Thanks for the overhaul, this looks already very good now!
Made a few changes in the branch and added two @todos, but apart from those and the two failing tests this seems to me to be ready to go. Thanks!

Great, thanks!
Will you also work on the remaining @todos in the branch? (Regarding the one: when moving the stages information to a method, I do think we should translate them, yes. Which probably means it shouldn't be static, so it can use proper DI.)
Otherwise, please unassign and we'll see who wants to pick it up.

I don't recall but now it is confusing. The tab mentions Filters but the whole page mentions processors. I think Filters is much more clear to users what it means. Can I rename all the wording on the page to Filters but in the code we can keep calling it Processors?

Doing this makes sense, the UI should be friendly and not map 1:1 to the underlying code. Having it called Filters is perfectly valid, even in the case where we move some processors that add new fields to the Fields tab. In code, they are all processors but in the UI they appear in different places.

Also saving processors is not working at the moment.

I think Filters is much more clear to users what it means. Can I rename all the wording on the page to Filters but in the code we can keep calling it Processors?

No, we voted in the BoF and agreed on "processors" – remember? But of course we should rename the tab now: see #2348185: Clean up terminology.

Also, this has nothing to do with this issue. Please revert your commit and start a new issue if you want to propose a new, expanded description.

My memory is really bad - sorry for that. Reverting!

No problem.
Still waiting for ekes' answer to #13.

OK, thanks for the response.
I'm currently on finalizing the move back to the proper repository, so I won't work on this for now. Maybe someone else wants to take this up? Otherwise, let's get back to it later.

Moving this issue to the proper project. Also re-merged the branch – I guess we should still develop that in the sandbox, so ekes (or whoever) can commit to it.

I'll finally tackle this before there is more rebasing trouble …
I'll also try to fix the other current problems with the "Filters" tab while I'm at it – there are enough at the moment, after all.

Unfortunately, I didn't have enough time to finish this yet and, as per #1188562-53: [meta] Important project announcements, I'll be on vacation the next three weeks.
I pushed my latest code to the sandbox branch, if someone has the time to pick it up and finish it that would be great. But since there are currently some weird issues I don't really understand myself, I can't really expect it.

At it again.

And, finally done! That was really quite some work there …
Attached is a patch, and the sandbox/2349435-seperate-processors-by-stage also contains the latest code. It would be great if someone else could take a look and maybe give it a try – however, since I didn't want to complicate things even more by also chasing HEAD, the patch still pertains to the D8 Core version 7c6a23f, from December 12. But everything seems to work fine for me, and all tests run green as well.
So, if no-one objects (or says they still want to test) I'll commit this in a few days.

I'd love to test it. Please hold till I can take a look :) Ekes, it would be also be great if you could do the same?

Oh, sorry, I didn't see you've been working on this recently in here. Contrary to your worries that it would be a pain to merge, this was trivial, or at least it seems so, did not run any tests yet.

I only had merge conflicts in Index.php and IndexFiltersForm.php. In both cases, I simply went with the code from this branch. I find it a bit scary to carry around the processors in $form_state and let them get serialized, I kind of preferred my approach to only use $form_state temporarily between validate and submit, but let's see how this goes.

Also pushed the merge (did not rebase) to your sandbox branch again.

Oh, you renamed the key, this should be better.

Finally got the time to rebase this and fix things up. The attached version passes tests for me locally, so I hope we can finally commit this.
(I also updated the branch, in case you want to look at interdiffs.)

Forgot that that was still a WIP regarding the "Content access" processor. This is the finished patch.

Nice to see it pass.
Does anyone still want to take a look or should I commit?

OK, finally committed!
Thanks a lot for your work on this, ekes, and also to Sascha for helping finish it!