Problem/Motivation

When editing a facet based on an aggregated field, a critical error is thrown.

The website encountered an unexpected error. Please try again later.
Error: Call to undefined method Drupal\search_api\Plugin\search_api\processor\Property\AggregatedFieldProperty::getPropertyDefinitions() in Drupal\facets\Plugin\facets\processor\BooleanItemProcessor->supportsFacet() (line 92 of modules/contrib/facets/src/Plugin/facets/processor/BooleanItemProcessor.php).
Drupal\facets\Plugin\facets\processor\BooleanItemProcessor->supportsFacet(Object) (Line: 195)
Drupal\facets\Form\FacetForm->form(Array, Object) (Line: 117)
Drupal\Core\Entity\EntityForm->buildForm(Array, Object)
call_user_func_array(Array, Array) (Line: 514)
Drupal\Core\Form\FormBuilder->retrieveForm('facets_facet_edit_form', Object) (Line: 271)
Drupal\Core\Form\FormBuilder->buildForm('facets_facet_edit_form', Object) (Line: 74)
Drupal\Core\Controller\FormController->getContentResult(Object, Object)
call_user_func_array(Array, Array) (Line: 123)
Drupal\Core\EventSubscriber\EarlyRenderingControllerWrapperSubscriber->Drupal\Core\EventSubscriber\{closure}() (Line: 576)
Drupal\Core\Render\Renderer->executeInRenderContext(Object, Object) (Line: 124)
Drupal\Core\EventSubscriber\EarlyRenderingControllerWrapperSubscriber->wrapControllerExecutionInRenderContext(Array, Array) (Line: 97)
Drupal\Core\EventSubscriber\EarlyRenderingControllerWrapperSubscriber->Drupal\Core\EventSubscriber\{closure}()
call_user_func_array(Object, Array) (Line: 153)
Symfony\Component\HttpKernel\HttpKernel->handleRaw(Object, 1) (Line: 68)
Symfony\Component\HttpKernel\HttpKernel->handle(Object, 1, 1) (Line: 57)
Drupal\Core\StackMiddleware\Session->handle(Object, 1, 1) (Line: 47)
Drupal\Core\StackMiddleware\KernelPreHandle->handle(Object, 1, 1) (Line: 99)
Drupal\page_cache\StackMiddleware\PageCache->pass(Object, 1, 1) (Line: 78)
Drupal\page_cache\StackMiddleware\PageCache->handle(Object, 1, 1) (Line: 47)
Drupal\Core\StackMiddleware\ReverseProxyMiddleware->handle(Object, 1, 1) (Line: 50)
Drupal\Core\StackMiddleware\NegotiationMiddleware->handle(Object, 1, 1) (Line: 23)
Stack\StackedHttpKernel->handle(Object, 1, 1) (Line: 657)
Drupal\Core\DrupalKernel->handle(Object) (Line: 19)
Support from Acquia helps fund testing for Drupal Acquia logo

Comments

sardara created an issue. See original summary.

borisson_’s picture

Issue tags: +Needs tests

Thanks for bringing this up, I don't we have a test with an aggregated field or we would've noticed this. Let's create a test and fix the offending code.

borisson_’s picture

This test doesn't work yet - but it's a start.

borisson_’s picture

Status: Active » Needs review
FileSize
4.67 KB
7.14 KB

Patch should work, but I don't know how to write the patch so that it passes. It currently breaks in super awesome ways.

Status: Needs review » Needs work

The last submitted patch, 4: critical_error_thrown-2917323-4.patch, failed testing. View results

archnode’s picture

Thank you for working on this! Still fails for me with patch and latest facets dev, though.

oxrc’s picture

This happened to me also on custom fields added via a processor for Search API using this tutorial: https://www.drupal.org/docs/8/modules/search-api/developer-documentation...

Because of my lack of experience/knowledge with Search API and Facets modules, I wasn't sure if the Search API processors or the Facets approach should be changed, your patch makes lots of sense and has been applied so far ok, I have been able to finally see the configuration form for my widget. I'll be continuing testing it and see if all is fine (running facets 1.x-dev + Search API 1.5 here).

borisson_’s picture

I asked Markus for help on how to write this test, he suggested adding a new index as config - and using that. So that's the plan.

Already adding credit for that helpful suggestion.

borisson_’s picture

Status: Needs work » Needs review
FileSize
3.1 KB
4.31 KB
7.36 KB

So markus suggested using a new index and adding that export config. I figured that was a good solution until I figured that would mean a new testmodule + view. That seems like a lot for one test.

So intead I put some more work into adding the field from the code.

I also added comments in the test to explain what I'm trying to do.

This adds a test-only (that should fail) and a normal patch (that should pass). Let's see if the testbot agrees with me.

The last submitted patch, 10: critical_error_thrown-2917323-10--testonly.patch, failed testing. View results

drunken monkey’s picture

Issue tags: -Needs tests

Joris asked me to look at this. It seems you've already got the tests passing as they should, so that's great.
However, regarding the actual fix, I have two comments:

  1. Explicitly filtering out processor-generated properties doesn't really make sense, in my opinion. Instead, when you're calling getPropertyDefinitions(), you should just check whether the data definition is actually an instance of the interface that defines that method – i.e., \Drupal\Core\TypedData\ComplexDataDefinitionInterface. I'm actually amazed that this doesn't cause trouble way more often – but probably that's because Field API fields are actually complex data now, so unless you index a sub-property (e.g., text field format), this bug won't be triggered by them.
  2. Also, I'm not clear on why you only check the sub-properties, and not the data type of the data definition itself? Makes more sense to me – but then, I'm of course not 100% familiar with this. However, it seems to me like whoever wrote this just needed a way to trigger for a boolean Field API field – in which case the value sub-property will have the desired data type. However, looping over all sub-properties for this also isn't the right way to do this – instead, you should just check the type of the main property, if available (cf. ComplexDataDefinitionInterface::getMainPropertyName()). That last bit isn't included in my attached patch, since I only thought of that just now.
drunken monkey’s picture

borisson_’s picture

FileSize
1.95 KB
8.13 KB

#13 copied the boolean check to all processors. This should be more specific. If all tests pass and everything still works we can commit this.

Thanks @drunken monkey!

oxrc’s picture

Hey there,

Patch #14 applies fine for me and the problem seems solved. Nice to have @drunken_monkey looking into this one. Works for me.

borisson_’s picture

Status: Needs review » Reviewed & tested by the community

Awesome, marking this as rtbc based on #15.

StryKaizer’s picture

Status: Reviewed & tested by the community » Fixed

Thx all!

  • StryKaizer committed 135a146 on 8.x-1.x authored by borisson_
    Issue #2917323 by borisson_, drunken monkey, mkalkbrenner: Critical...

Status: Fixed » Closed (fixed)

Automatically closed - issue fixed for 2 weeks with no activity.