Call to undefined method Drupal\search_api\Query\Condition::getConditions()

Created on 6 December 2022, almost 2 years ago
Updated 3 August 2023, over 1 year ago

Problem/Motivation

This is a continuation of https://www.drupal.org/project/search_api_meilisearch/issues/3264559#com... and https://www.drupal.org/project/search_api_meilisearch/issues/3264559#com...

When I try to use Meilisearch as a backend for my search_api based site search that does work with search_api's built in database backend, I get the following error using current 1.0.x-dev@dev

Error: Call to undefined method Drupal\search_api\Query\Condition::getConditions() in Drupal\search_api_meilisearch\Plugin\search_api\backend\SearchApiMeiliSearchBackend->extractConditions() (Line 467 in /var/www/upcoming-drupal/web/modules/contrib/search_api_meilisearch/src/Plugin/search_api/backend/SearchApiMeiliSearchBackend.php)

#0 /var/www/upcoming-drupal/web/modules/contrib/search_api_meilisearch/src/Plugin/search_api/backend/SearchApiMeiliSearchBackend.php(335): Drupal\search_api_meilisearch\Plugin\search_api\backend\SearchApiMeiliSearchBackend->extractConditions()
#1 /var/www/upcoming-drupal/web/modules/contrib/search_api/src/Entity/Server.php(473): Drupal\search_api_meilisearch\Plugin\search_api\backend\SearchApiMeiliSearchBackend->search()
#2 /var/www/upcoming-drupal/web/modules/contrib/search_api/src/Query/Query.php(539): Drupal\search_api\Entity\Server->search()
[..]

The error somehow makes sense. Taking a look at the search_api source (src/Query/Condition.php), it seems getConditions() is not defined. This is only the case for src/Query/ConditionGroup.php

Steps to reproduce

This is somewhat non-deterministic. With some sites/search implementations this works, with some it doesn't. I really tried to find the actual difference, but to no avail.

The route that seemed to cause it the last time seems to be this:

  1. Create index of some fields in all articles (title, body, attachments parsed using file_extractor)
  2. Index items - works flawlessly
  3. Create a search page based on an exposed filter; default options, parse mode multiple terms
  4. Type in the first search term and hit submit

Proposed resolution

The patch attached fixes it for me.
I am unsure whether $conditions ever is an instance of ConditionGroupInterface on my sites at all, as it even works without the if-clause (and just the else part) in whichever setup I tried it. This is just a safety measure as basically I do not have much understanding of what data actually comes in from search_api and which data structures have to leave the module for Meilisearch to be happy.

The changes you did in https://git.drupalcode.org/project/search_api_meilisearch/-/merge_reques... a few days ago seem to address the same problem, so this might be fixed by this commit already.

I am waiting for it to stabilize/land in -dev so I can verify.

🐛 Bug report
Status

Closed: duplicate

Version

1.0

Component

Code

Created by

🇦🇹Austria tgoeg

Live updates comments and jobs are added and updated live.
Sign in to follow issues

Comments & Activities

Not all content is available!

It's likely this issue predates Contrib.social: some issue and comment data are missing.

  • 🇦🇹Austria tgoeg

    Alright, this was haunting me for too long :-)

    I know why this was only partially reproducible: It depends on whether or not you're logged in (and in the development phase I am more or less constantly logged in, so only seldomly saw this).
    The problem is this:
    When not logged it, there are more conditions/condition groups. Which makes the mentioned location in the code fail as another condition group needs to be unrolled.
    The linked MR only made it worse in my case, as my (specific) query would not work anymore, neither logged in nor as an anonymous user.

    This was pretty hard, considering I am no (PHP) dev at all, however dump(condition) worked wonders.

    This is how the conditions look like in my case:

    ^ Drupal\search_api\Query\ConditionGroup {#7804 ▼
      #conditions: array:2 [▼
        0 => Drupal\search_api\Query\ConditionGroup {#7564 ▼
          #conditions: array:2 [▼
            0 => Drupal\search_api\Query\Condition {#7573 ▼
              #field: "search_api_datasource"
              #value: "entity:file"
              #operator: "="
            }
            1 => Drupal\search_api\Query\ConditionGroup {#7561 ▼
              #conditions: array:2 [▼
                0 => Drupal\search_api\Query\ConditionGroup {#7554 ▼
                  #conditions: array:1 [▼
                    0 => Drupal\search_api\Query\Condition {#7341 ▼
                      #field: "status"
                      #value: true
                      #operator: "="
                    }
                  ]
                  #conjunction: "OR"
                  #tags: array:1 [▶]
                }
                1 => Drupal\search_api\Query\ConditionGroup {#7340 ▼
                  #conditions: array:2 [▼
                    0 => Drupal\search_api\Query\Condition {#7338 ▼
                      #field: "node_grants"
                      #value: "node_access_all:0"
                      #operator: "="
                    }
                    1 => Drupal\search_api\Query\Condition {#7337 ▼
                      #field: "node_grants"
                      #value: "node_access__all"
                      #operator: "="
                    }
                  ]
                  #conjunction: "OR"
                  #tags: array:1 [▶]
                }
              ]
              #conjunction: "AND"
              #tags: []
            }
          ]
          #conjunction: "OR"
          #tags: array:1 [▶]
        }
        1 => Drupal\search_api\Query\Condition {#7335 ▼
          #field: "role_access"
          #value: array:1 [▼
            0 => "anonymous"
          ]
          #operator: "IN"
        }
      ]
      #conjunction: "AND"
      #tags: []
    }

    So a group of groups of groups of groups :-)
    It seems to me this can be nested indefinitely and we don't know beforehand.

    That's why a recursive algorithm for unrolling the groups seems most adequate (and readable) to me.
    It's even shorter than the original code.

    I pushed a change to the MR in https://www.drupal.org/project/search_api_meilisearch/issues/3322856 🐛 Custom filter groups on a View (Search API index view) are not working Fixed . This is my first commit ever, so I hope everything's in order. If not, please say so and I'll try to improve!

    Any changes to the code welcome - I am just a sysadmin with some C background.

  • Status changed to Closed: duplicate over 1 year ago
  • 🇸🇮Slovenia DeaOm

    As you already mentioned this is handled in the 🐛 Custom filter groups on a View (Search API index view) are not working Fixed and you also added a commit there, I'm closing this as duplicate in favor of the related issue (better transparency).

Production build 0.71.5 2024