Needs review
Project:
Facets prefix/suffix
Version:
8.x-1.x-dev
Component:
Code
Priority:
Normal
Category:
Bug report
Assigned:
Unassigned
Reporter:
Created:
11 Mar 2019 at 19:01 UTC
Updated:
21 Mar 2019 at 19:14 UTC
Jump to comment: Most recent, Most recent file
Comments
Comment #2
chrisolofAttached patch checks that the facet's data comes from a field before attempting to load the field's definition and only shows source-field prefix and suffix config options when a source-field definition can be loaded. Custom prefix/suffix config is always available.
Comment #3
ericclaeren commentedThank you for the patch. Do you have some more information on how to reproduce this issue.
When you say aggregated field, do you mean:
* Extra field on an entity
* Pseudo field through annotation on an entity.
* Computed base field on an entity
* Field through a contrib module
Is there a way you could provide a code example so I can reproduce this issue and test the patch?
Thanks.
Comment #4
ericclaeren commentedComment #5
chrisolofSure! I'm using this module in conjunction with the Search API and Search API Solr Search modules. To reproduce:
1. Click "Add fields" at
/admin/config/search/search-api/index/default_solr_index/fields. A modal pops up.2. Click "Add field" next to the "Aggregated field (aggregated_field)" choice, which on my screen is the first choice under "General" at the top.
3. Set this field up however you'd like.
4. Now head back over to facets at
/admin/config/search/facetsand attempt to add a facet for this new aggregated field. You should see a "Call to undefined method" error when attempting to configure the facet.The module assumes $facet->getDataDefinition() will always return a Drupal\Core\Field\TypedData\FieldItemDataDefinition object with the getFieldDefinition() method. But in the case of an aggregated field, $facet->getDataDefinition() will return a Drupal\search_api\Plugin\search_api\processor\Property\AggregatedFieldProperty, which doesn't have a getFieldDefinition() method, since it doesn't correspond to any single field-api field.
The patch allows the module to work for all types of facet data. When $facet->getDataDefinition() returns a Drupal\Core\Field\TypedData\FieldItemDataDefinition object we present the familiar options to use suffix/prefix from the field's definition (because we actually have that information). When $facet->getDataDefinition() returns something else, we only present the custom prefix/suffix options in config, since we don't have a field-api field to pull existing prefix/suffix config from.
Anyway I hope that makes sense. Let me know if I can clarify further.