Transform entity id into label doesn't work with aggregated fields

This patch no longer applies and needs a reroll

Ok, let's postpone this one.

The issue this depended on is committed.

We discussed this in today's hangout and decided that the current approach makes this way too complicated.

Instead, we'd like to keep this processor as-is and add documentation in the UI that a new custom processor should be created to do this.

Attached is what #20 suggested.

NR for #21

> We discussed this in today's hangout and decided that the current approach makes this way too complicated.
> Instead, we'd like to keep this processor as-is and add documentation in the UI that a new custom processor should be created to do this.

Are you really sure this is the way to go?

Doing this means duplicating code in a new processor that handles entity labels on aggregated fields.

It also means the the complication that is being saved in code is moved onto to the site builder, because there will be two 'Transform entity ID to label' processors, and the site builder will need to choose one and know what sort of Search API search index they are using.

Furthermore, I am guessing that the 'List item label' processor will be affected in the same way -- that too might need special treatment to work with aggregated fields.

Also, reopening because if this *is* the right way to go, there needs to be form validation to prevent this being added to aggregated fields -- views with this processor on an aggregated field crash with:

> Call to undefined method Drupal\search_api\Plugin\search_api\processor\Property\AggregatedFieldProperty::getPropertyDefinition

Also, I think patch #18 can be improved, with something like this

  // Support multiple entity types when using Search API.
  if ($source instanceof \Drupal\facets\Plugin\facets\facet_source\SearchApiDisplay) {
    $field = $source->getIndex()
      ->getField($facet->getFieldIdentifier());
    
    $configuration = $field->getConfiguration();
    
    foreach ($configuration['fields'] as $field) {
      list($entity_type, $property_name) = \Drupal\search_api\Utility\Utility::splitCombinedId($field);
      
      // TODO:
      // 1. Split $entity_type from the form 'entity:TYPE'
      // 2. see if there is a field storage $property_name on $entity_type
      // 3. if it's an entity ref field, get its target
      // 4. check that all the aggregated fields have the same target.
    }
    

That's not far off from being able to figure out the target entity type of an aggregated field.

Rather than load fields on every page view, this could be figured out in the facet form, and saved into the processor configuration?

Doing this will introduce a big difference in the processor between core search and search api. Aggregated fields are only working for search api so that is somewhat expected. However this might make things very complex.

However, I think that implementing #2851851: Facet source plugins should provide metadata for facet fields would be a good start to simplify the code to decide what field it is, see also the code already added to TranslateEntityProcessor in that patch.

(BTW, for people who are finding this breaks their facets from older versions, a quick and dirty workaround is to copy the taxonomy term label processor plugin from an old alpha (3 in my case) into a custom module.)

I ran into this issue today. It leads to a fatal error:
The aggregated_field_type field has no datasource, there is no valid use for the list_item processor with this facet in ...

The aggregated field contains the types (bundles) of two different content entities. If I remove the "List Item label" option, it works.

I ran into this issue today. Not on an aggregated field but on a custom field I created that contains a bundle value.

ListItemProcessor contains fallback code to handle the bundle label but it doesn't reach that part of the code since my custom field doesn't have a datasource.

I ran it today as well with aggregated fields that contain a bundle value.
Would be a nice feature to add- a processor of transforming aggregated field entity IDs to labels

Ended up with a new processor to aggregated fields

Just tested the patch in #33, works well not only for taxonomy terms, but for custom entities too.

Two minor code review comments:

1.
"An array of values that contain possible replacements for the orignal"

Should be:
"An array of values that contain possible replacements for the original"

2.
The processor should hide itself from the list already if not an aggregated field, so

+      if ($field->getPropertyPath() !== 'aggregated_field') {
+        throw new InvalidProcessorException("This field is not aggregated field.");
+      }

Could be removed and added as a pre-build check, not?

Good point, I fixed them both

Fix tests

Ok, works.

I rescind the RTBC. Will fix a couple of small things:

1. InvalidArgumentException description is incorrect.
2. It gives issues with computed fields

Patch with very small changes.

         $field_storage = $definition_update_manager->getFieldStorageDefinition($field, $entity_type_id);
-        if ($field_storage->getType() === 'entity_reference') {
+        if ($field_storage && $field_storage->getType() === 'entity_reference') {

This was changed because computed fields don't have storage.

I actually used the wrong previous patch. I used the one from #36 instead of #38 so my patch is worthless...

Correct versions of the files.

Hey @Jax. Your patch in #45 is good! Just tested it.

Thanks so much! You saved me a lot of time :)

Works well also with entity type bundles!

Looks great, we don't have specific coverage for this, but that is going to be a lot of specific setup. I like that the supportsFacet is very specific here. +1

+    if ($field->getPropertyPath() === 'aggregated_field') {
+      return TRUE;
+    }
+
+    return FALSE;

should be converted to

return $field->getPropertyPath() === 'aggregated_field';

Committed and fixed

    /** @var \Drupal\search_api\Entity\Index $index */
    $index = $facet->getFacetSource()->getIndex();

I think this line is a problem. It assumes that the facet source is a Search API source, which is not always true (see the core_views_facets module, for example). We should probably return early if the facet source is not Search API. Patch incoming.

Here's a patch for this.

Looks like a simple change, LGTM.

Pushed the followup.