🇩🇪Germany @mkalkbrenner

mkalkbrenner → created an issue.

There's already an incremental import based on metadata this module adds to the JSON file.

mkalkbrenner → created an issue.

mkalkbrenner → created an issue.

I don't use Paragraphs at all. Feel free to provide a patch for that issue.

mkalkbrenner → created an issue.

For sure you can commit that patch in the Drupal 7 branch. But the 7.x module is already marked as unsupported, just like Drupal 7 itself.

BTW it is a bit strange that people want to update to newer Solr versions but not to newer Drupal versions ;-)

I went the "events way" in all the contrib modules I'm involved in. And a s far as I know, Core still does events as well.
And other big contrib modules like commerce are using events as well.
I don't think that one thing is right and the other is not. And there's not the one drupal way.
My understanding is that hooks get an OOP replacement. But it is totally valid to use Events.
BTW I would have preferred to replace hooks in core by events and closer following a PSR standard instead of introducing something new that is drupal-specific.

mkalkbrenner → created an issue.

mkalkbrenner → changed the visibility of the branch 1.0.x to hidden.

mkalkbrenner → created an issue.

mkalkbrenner → made their first commit to this issue’s fork.

Thanks for reporting. Can you provide a patch?

Thank you!

Thank you!

The _dcd_metadata is essential for the incremental import and to track entity references that don't use an UUID.

Patches are welcome.

Thanks for this MR. Can you adjust it to the current code base? I'll merge it immediately afterwards.

mkalkbrenner → created an issue.

I prefer to stay with events as well. The reason is that third-party libs like solarium or others to integrate search backends are using events, based on a PSR standard.
Now it is possible to bundle search related customizations that build one feature together in one event subscriber that subscribes to events of serach_api, serach_api_solr, solarium and facets.

Within the Solarium library tests, we also went for SOLR_MODULES=extraction

Thanks, but it is fixed in the dev branch on github already.

Todo: document search_api_solr_admin.

It is way easier to install search_api_solr_admin and to use the button for that use-case. Or the drush command.

The issue on github is fixed

The problem is that I can't get the tests to work on gitlab. I asked for help, but obviously the interest isn't that high.

If you would have followed the rules to add a PR on our github repro where the full test suite runs, you would have noticed that some fixes are in the code already.

What do you mean by "post the schema"?
This module creates a config-set zip. using search_api_solr_damin you can "deploy" that zip to a Solr server running in cloud mode and doesn't block the config-set API.

Can you debug what actually is in the array?
Can you find out which search triggers that?

turn on search_api_solr_devel to see the resulting Solr queries and why they match a document.

The lib includes for Solr 9 could be seen here:
https://git.drupalcode.org/project/search_api_solr/-/blob/4.x/solr-conf-...

Basically we include the required stuff for some aditional features per default:

• extraction to parse PDFs
• langid and analysis-extras for special languages that aren't English
• ltr for the LearnToRank feature

There's a pending feature request to load more advanced libs for spatial search.

In general, the config-sets provided by this module are defaults which have to be adjusted to your use-case. A lot of things are already configurable. But you can also use an EventSubsriber to do further modifications.
But we can't do anything about what needs to be configured in the Solr server itself.

So having a doumentation would be great. In the README and the online handbook.
Also, a patch that adds information to the UI of search_api_solr is welcome.

For composer.json the correct patch would be to turn the dependency into a suggestion.

But I don't know hoe the module behaves internally if the dependency us not fulfilled.
If it works as expected, then the dependency is not needed at all and really a bug.

Could it be an issue with your composer.json?

 ± composer require 'drupal/ckeditor5_plugin_pack:^1.2'

./composer.json has been updated
Running composer update drupal/ckeditor5_plugin_pack
Gathering patches from patch file.
Loading composer repositories with package information
Updating dependencies                                 
Lock file operations: 11 installs, 0 updates, 0 removals
  - Locking aws/aws-crt-php (v1.2.7)
  - Locking aws/aws-sdk-php (3.339.1)
  - Locking caxy/php-htmldiff (v0.1.16)
  - Locking drupal/ckeditor5_plugin_pack (1.2.4)
  - Locking drupal/ckeditor5_premium_features (1.3.5)
  - Locking ezyang/htmlpurifier (v4.18.0)
  - Locking firebase/php-jwt (v6.11.0)
  - Locking mtdowling/jmespath.php (2.8.0)
  - Locking openai-php/client (v0.10.3)
  - Locking php-http/discovery (1.20.0)
  - Locking php-http/multipart-stream-builder (1.4.2)
Writing lock file
Installing dependencies from lock file (including require-dev)
Package operations: 11 installs, 0 updates, 0 removals
  - Downloading php-http/discovery (1.20.0)
  - Downloading aws/aws-crt-php (v1.2.7)
  - Downloading php-http/multipart-stream-builder (1.4.2)
  - Downloading openai-php/client (v0.10.3)
  - Downloading firebase/php-jwt (v6.11.0)
  - Downloading ezyang/htmlpurifier (v4.18.0)
  - Downloading caxy/php-htmldiff (v0.1.16)
  - Downloading mtdowling/jmespath.php (2.8.0)
  - Downloading aws/aws-sdk-php (3.339.1)
  - Downloading drupal/ckeditor5_premium_features (1.3.5)
  - Downloading drupal/ckeditor5_plugin_pack (1.2.4)
Gathering patches from patch file.
Gathering patches for dependencies. This might take a minute.
php-http/discovery contains a Composer plugin which is currently not in your allow-plugins config. See https://getcomposer.org/allow-plugins
Do you trust "php-http/discovery" to execute code and wish to enable it now? (writes "allow-plugins" to composer.json) [y,n,d,?] 

mkalkbrenner → created an issue.

Thanks for the patch. I'll adjust the code a bit and commit it.

Thanks a lot.
I will adjust the patch a bit and commit it.

mkalkbrenner → created an issue.

mkalkbrenner → created an issue.

mkalkbrenner → created an issue.

mkalkbrenner → created an issue.

Drupal 7 reached EOL.

Drupal 7 reached EOL.

Drupal 7 reached EOL.

Drupal 7 reached EOL.

Drupal 7 reached EOL.

Drupal 7 reached EOL.

re-roll

Thanks for the explanation.

But this is how it works. Facets are filters and don't influence the scoring.
Converting them into a query will break a lot of different facets features, especially tagging and excluding:
https://solr.apache.org/guide/solr/latest/query-guide/faceting.html#tagg...

I still don't understand the use-case.
All result items must match any of the filters. How should a result item match more filters than another?

Could you describe a concrete example?

I don't think that we should add that workaround to search_api_solr.
The feature request should target search_api first to allow multiple boosts.
Then the backends should be adjusted accordingly.

Did you debug the query?

I think we create the query as "q" and only conditions as "fq". So I think that it is correct that conditions should not influence the scoring as all documents have to meet the condition.

Which use-case does create filter queries should influence the scoring?

mkalkbrenner → created an issue.

mkalkbrenner → created an issue.

mkalkbrenner → created an issue.

Also, a raw value of 2019-10 could not be formatted this way.

mkalkbrenner → created an issue.

mkalkbrenner → created an issue.

Meanwhile, there's a module:
https://www.drupal.org/project/search_api_clir →

mkalkbrenner → created an issue.

It seems to be required to define a new text based field type for that use case. That is "easy".
But I need the complete requirements for that field type. For example, it should behave like XY, but with newline included.

But another problem might be Search API which already splits a text in chunks. So we need to disable that functionality or recombine the chunks by adding newlines.

But again, I can't implement it based on guessing the requirements. I need your help to do it.

The tests are failing:

https://github.com/mkalkbrenner/search_api_solr/actions/runs/11451902990...