🇪🇸Spain @tuwebo

Hello,
There have been some changes lately for 3.0.x-dev, and looking into this issue (and commit) #3485860-11: TypeError: array_values(): Argument #1 ($array) must be of type array, null given → I wonder if anyone can confirm if this patch is still necessary or not (I can't test it properly right now). Although the mentioned issue does not seem to be related, the code in the commit might be.

Hello,
I know this issue is closed, but just leaving the comment here.
I wondering if the facets_exposed_filters_update_8001 should have been better done in a hook_deploy_NAME instead.
It looks like (in some scenarios) configuration changes performed in the facets_exposed_filters_update_8001 could get overriden afterwards if the configuration is imported (e.g. using drush deploy command).

Hello @pramodganore, thanks for taking the time to look at it.
The code in the comment #3459227-7: Potential risks using "Direct query" parse mode with views? → was just a proof of concept with very basic code (be aware of it and read carefully some implications in the issue's description). There is no further code, although I am still improving it but not sure when will be ready for posting it here.
Also a lot of testing will need to be done and probably, as @mkalkbrenner mentioned, Search API processors will not fully work (I am thinking for example about the Highlight.
That being said, maybe the best solution could be just customizing your search form by adding some kind of tips for the final user about how they should use it, since solr is very picky about the syntax (not only case sensitive, but also some user may forget to close the single quotes, double quotes, parenthesis...).
I am also working in the other approach by using the "Simple Query Parser", but first try yield some unexpected results, I come with something useful I'll update this issue.

Not sure about the implications of this workaround (it might break your site, take it with a grain of salt) , but it seems it is working for me if I run it before uninstalling:
drush cset --input-format=yalm views.settings display_extenders default

You might want to check the views.settings configuration before running it, executing:
drush cget views.settings

tuwebo → created an issue.

Patch 3448459-3--stop-form-altering-non-extra-field-plugin-layout-builder-components.patch correctly applies and solve the issue for my use case:
Drupal: 10.3.6
Extra Field (extra_field): 8.x-2.3
Extra Field Plus: Extra Field Settings Provider (extra_field_plus): 3.0.0-beta4
Entity Print (entity_print): 8.x-2.14

I am able to properly add/edit a "View PDF" extra field using the layout builder.

Thanks @Daniel Bornman

I think this might the case when using a module like entity_print, since I am running in similar issue. I'll try to provide more feedback since I've just run into it.

I'm sorry my bad, it didn't work. @borrison_ what issue are you reffering to that fixed it?

I am facing similar behaviour when the view has a pager, it seems like changing the view's Pager id (Pager options) to a different number than 0 (in my use case) solved the issue. Just in case could help to someone else.

Just adding a patch, to check it with that code will be enough.

TuWebO → created an issue.

Thinking about this issue,
Maybe we could use the Boolean Query parser to run both queries and this way combining them. I have never used it, but ti looks like it could be done. I am thinking about something like (didn't test it):
q={!bool}must=({!lucene}field1:value1) must=({!edismax qf=field2^2}value2)

A potential Query parser that could fit is the Simple Query Parser https://solr.apache.org/guide/8_1/other-parsers.html#simple-query-parser

Which can be added in the solrconfig_extra.xml this way or use the PostConfigFilesGenerationEvent:
<queryParser name="simple" class="solr.SimpleQParserPlugin"/>

I think we should NOT allow WHITESPACE operator (at least), but there is an easy way to restrict it using a list of allowed ones with the parameter q.operators

The downside is we won't be able to handle Function Queries https://solr.apache.org/guide/8_1/function-queries.html

A potentially Direct parse_mode handling boolean operators and grouping could look like this:

namespace Drupal\search_api_solr\Plugin\search_api\parse_mode;

use Drupal\Component\Utility\Unicode;
use Drupal\search_api\Plugin\search_api\parse_mode\Direct;

/**
 * Represents a parse mode that handles Boolean operators and grouping.
 *
 * @SearchApiParseMode(
 *   id = "direct_boolean_operators",
 *   label = @Translation("Direct query boolean operators"),
 *   description = @Translation("A direct query allowing boolean operators and grouping. Might fail if the query contains syntax errors in regard to the specific server's query syntax."),
 * )
 */
class DirectBooleanOperators extends Direct {

  /**
   * {@inheritdoc}
   */
  public function parseInput($keys) {
    // Check if input is an array.
    if (is_array($keys)) {
      // Validate each element in the array.
      foreach ($keys as $key) {
        if (!Unicode::validateUtf8($key)) {
          return '';
        }
      }
      // Convert array to string with spaces between elements.
      $keys = implode(' ', $keys);
    }
    else {
      // Validate the single string input.
      if (!Unicode::validateUtf8($keys)) {
        return '';
      }
    }

    // Test string
    // "Drupal 10 theming" AND (views OR "content types") NOT "user authentication" + performance~2 OR security^2 && (module || plugin) !deprecated

    // Boolean operators and valid symbols.
    // ['AND', 'OR', 'NOT', '&&', '||', '!', '+', '-'];

    // Valid group and scape chars.
    // ['(', ')', '\'];

    // Normalize whitespace.
    $keys = preg_replace('/\s+/u', ' ', trim($keys));

    // Handle Boolean operators and symbols, remove extra whitespaces.
    $keys = preg_replace('/\s(AND|OR|NOT|!|\|\||&&)\s/', ' $1 ', $keys);

    // Define special characters to escape.
    $escape_special_chars = ['{', '}', '[', ']', '^', '~', '*', '?', ':'];

    // Handle special characters outside of quotes.
    $keys = preg_replace_callback('/("[^"]+")|\S+/', function($matches) use ($escape_special_chars) {
      if (isset($matches[1])) {
        // This is a quoted phrase, don't modify anything inside
        return $matches[0];
      } else {
        // This is not a quoted phrase, escape only the specified special characters
        $term = $matches[0];
        foreach ($escape_special_chars as $char) {
          $term = str_replace($char, '\\' . $char, $term);
        }
        return $term;
      }
    }, $keys);


    // @TODO
    // Handle NegativeQueryProblems: Pure Negative Queries
    // https://cwiki.apache.org/confluence/display/SOLR/NegativeQueryProblems#NegativeQueryProblems-PureNegativeQueries

    return $keys;
  }
}

Hello @mkalkbrenner, thank you very much for taking your time and fast response.
I will start taking a look at search_api_solr, which seems a faster approach and easier to implement, then maybe take a look at search_api which is the optimal solution.

TuWebO → created an issue.

smustgrave → credited TuWebO → .