🇩🇪Germany @mkalkbrenner

greggles → credited mkalkbrenner → .

Never edit composer.lock!

Edit the top level composer.json.

I believe I have not installed solarium/solarium explicitly, by itself, or in a specific version.

You must have done that. A contrib module can't do it.

For whatever reason you must have installed solarium 6.3.6 explicitly.
Simply remove solarium from composer.json.

I don't think that this is an issue with search_api_solr, but with your installation. Run
composer why-not drupal/search_api_solr:4.3.8

I was able to reproduce the issue if a module is installed that reacts to media entity updates. In our case, image_replace isn't fault tolerant. So default_content_deploy can't import the entity or fix the file ID later.

A quick fix is to handle files at the beginning of the import.

BTW that issue was hidden in previous versions. Meaning, it existed as well but didn't hurt because of the more verbose export format.

The format changed. Most of _links at top level is not need for our use-case.

So from the JSON code above, it's missing this outside of _embedded:

No, this is correct. Entity Reference fields are only in _embedded.

It seems to be an import related issue.

Sorry, but these patches aren't readable because they reformat entire files.

I ended up using this:
sudo su - solr -c "/opt/solr/bin/solr create -c IAB -n data_driven_schema_configs"

This is totally wrong. It doesn't use the drupal schema. That's why the file is missing.

Also of note, I was not able to use this command from the README.md file to create a core:
`$ sudo -u solr $SOLR/bin/solr create_core -c $CORE -d $CONF -n $CORE`

Did you replace $CORE and $CONF with the required values?

BTW why don't you start Solr in cloud mode and let Drupal create the collection for you?

In 2.2.x we still use JSON, but the format become much more readable because not required information gets removed now.

Nevertheless, YAML would be interesting as alternative.

We import users, webform submissions and newsletter subscriptions from different sites into one backend using default_content_deploy. So we need a UUID field to avoid id collisions.

This works well for everything except the SubscriberHistory. With that patch applied, SubscriberHistory works as well.

But I agree that the update hook requires a batch.

mkalkbrenner → created an issue.

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.