Add additional preprocessing method at index time?

Clarified task. This is by no means one we have to implement soon (i.e., while still in the sandbox), though, I think.

This patch implements that and seems to work fine.
I'd also like to add some tests for this (and all other processor methods) to our HooksTest, but this depends on #2752749: Make handling of index plugins/fields consistent and #2134803: Add a "processing level" setting to search queries to avoid conflicts.

Only one thing I'd like to see changed, as well as the additional tests is the following:

1. +++ b/src/Tests/HooksTest.php
   @@ -41,7 +45,13 @@ public function setUp() {
   +//    /** @var \Drupal\search_api\Processor\ProcessorInterface $processor */
   +//    $processor = $index->createPlugin('processor', 'search_api_test');
   +//    $index->addProcessor($processor)->save();
   

   @drunken monkey--

@drunken monkey--

:(
That was already part of said tests, I just wanted to keep it for them.
See the attached patch.

Is this already enough?

A bit worrying that we didn't spot this config schema issue before – but then again, it's just in the test processor, so not really relevant.

And finally figured out what's wrong with the new hook test.

+++ b/src/Entity/Index.php
@@ -962,7 +968,13 @@ public function indexSpecificItems(array $search_objects) {
+      // This will cache the extracted fields so processors, etc., can retrieve
+      // them directly.

Lets rewrite this comment, I'd suggest: Get all the extracted fields for the item. The fact that this is cached is an implementation of the method and shouldn't matter for this comment.

If you disagree, than I feel this is RTBC, but setting back to NW for the comment update.

Thanks for your thorough review!

Lets rewrite this comment, I'd suggest: Get all the extracted fields for the item. The fact that this is cached is an implementation of the method and shouldn't matter for this comment.

No, I disagree. If this didn't cache the field values, than calling this method here would be pointless and just a waste of ressources. Also, if the method didn't store the extracted values, processors wouldn't work, since the server would always receive newly extracted, unprocessed field values anyways. So it's not an implementation detail at all, it's a basic characteristic of the framework.

The patch needed a re-roll, but if tests pass I'll then treat it as RTBC, in accordance with your comment.

Committed.

-  public function preprocessIndexItems(array &$items);
+  public function preprocessIndexItems(array $items);

This is causing a fatal error ::preprocessIndexItems(array &$items) must be compatible with Drupal\search_api\Processor\ProcessorInterface::preprocessIndexItems(array $items)

See https://www.drupal.org/node/2230915

This is causing a fatal error ::preprocessIndexItems(array &$items) must be compatible with Drupal\search_api\Processor\ProcessorInterface::preprocessIndexItems(array $items)

In which class, or which module? I'm positive we changed this in all our classes (and the tests would surely report it, otherwise) and we're not responsible for updating other modules.
Your link leads to this same issue.

Sorry for the wrong copy paste but I still see it in UnsavedIndexConfiguration:

  /**
   * {@inheritdoc}
   */
  public function preprocessIndexItems(array &$items) {
    return $this->entity->preprocessIndexItems($items);
  }

And that produces actual fails anywhere on your site? As said in the other issue (I think), we currently don't use that class.