🇩🇪Germany @mkalkbrenner

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...

The happens for newlines.

A quick workaround could be to enter HTML entities instead that get converted by the HtmlFilter processor later.
As a patch we could add a hint to the description of the Replacements text field.

I close this issue as it seems to be unrelated to this module, but caused by your local PHP setup.
If you think that it is really an issue with search_api_solr and have further information, re-open this issue.

Check the logs. Drupal watchdog and Solr's logs.
We need more information here.

Use the Analyzer to verify how such values get indexed and how they are searched. It is available in the Solr UI or by search_api_solr_admin. It is just a configuration issue , not a bug. It is important to modifay the string the same way when indexing and searching.

We handle very similar SKUs at Jarltech.

I recommend that you define your own content domain and modify the text based string type according to your needs.
https://www.drupal.org/docs/8/modules/search-api-solr/search-api-solr-ho... →

If you do so, leverage Solr's patternReplace char filter instead of Search API's ignore chars processor. This is way more efficient.

This patch break the entire functionality of "Add new Solr Document fields".
The purpose of that feature is to filter the down the normal "Add field" modal to only offer fields that aren't configured yet.
This feature is entirely removed by the merge request.

To test it, you need a "foreign" Solr index not reflecting Drupal's data. By "adding" fields to the Search API Index you make that data available to be searched within Drupal and to build Views based on that data.

Seems like an issue with your composer / autoloader setup.

We have some big and complex entity forms in our backend systems. Since the lastest security updates, the loading time of a very important form increased from 1.5 seconds to more than 50 seconds. Way more than factor 10.
Running composer require twig/twig:"3.14.0 as 3.14.2" reduced the loading time 1.5 seconds again!

I will test the proposed patch.

mkalkbrenner → created an issue.

mkalkbrenner → created an issue.

schema_extra_types.xml belongs to the search_api_solr config-set.

It could be that you made a mistake in the setup and you're running the default managed schema of Solr instead of the one that belongs to this module.

If indexing and searching "works", it doesn't mean that it really works. The default managed schema simply accepts any field name using a simple default string type. So a lot of features don't work as they should, for example language-specific full text searches.
you just don't get errors, but the search results are very bad. You might not notice it directly if your content is in English.

It works with PHP 8.3 and Drupal 11

You're right. We should be consistent here an provide a corresponding patch.

Nevertheless, some examples would be good. Or even better, a test.

It seems that search_api_solr_entity_type_alter() doesn't work correctly on your system. Or another server or instance overwrites the cached container.

Isn't that exception the correct behaviour if the value could not be parsed?
Simply silently skipping the value seems wrong to me.

Can you provide a list of examples that are valid drupal field values, but result in a parse error?

Why don't you follow our instructions?

Two essential errors:
You created a core using the default schema, not the drupal schema.
You tried to use the templates, which aren't a config-set, but the templates to create a config-set.

Follow the README!

mkalkbrenner → created an issue.

greggles → credited mkalkbrenner → .

default_content_deploy was a add-on for default_content in the beginning. But the use-cases were too different.
I used default_content and it was too limited for my requirements. So I switched to default_content_deploy and started contributing later.
But I have no time to work on a comparison sheet.

Thanks for the feedback!

I improved my patch a bit and committed it.
If you still discover problems, report them.

Using the patch in #6, the behaviour should be consistent in all export variations as described in #4.

Can you test it?

I just noticed that the intended behaviour only works with the search_api backend, but not with the standard batches. This is a bug.

Thanks for the patch.

I don't understand why the current feature Skip entity types to be exported indirectly by reference or in site export isn't sufficient.

We have a similar use case. We export Product Variations with references but skip references to other Product Variations. And this is already working.

I know that it might be confusing that the existing skip_entity_types has a dual use. It skips these types during a site export. And it skips these types if referenced.

So if you explicitly export "node" with references and skip the type "node", it should only skip referenced nodes.

mkalkbrenner → created an issue.

Default Content is designed to deploy default content once, for example when a module or profile gets installed or updated.

Default Content Deploy is designed for continuously "synchronizing" content between multiple systems.

mkalkbrenner → created an issue.

I think, the situation has mean improved in 2.1.x.

But we have another issue about troubleshooting import issues.

I think that the patch needs some adjustments for 2.1.x. At least it should be tested again.

Is that still an issue with 2.1.x?

I think, we fixed that in 2.1.x

credits

mkalkbrenner → created an issue.

see 🐛 User 1 isn't the super user anymore in Drupal >= 10.3 Active .

Fixed in 2.1.x

I think we fixed that in 2.1.x

The issue doesn't exist in 2.1.x anymore.

Meanwhile, the situation changed drastically. Paths are computed fields and don't belong to a node or an other entity directly.
The recommended way is to export the path alias entity itself.

Nevertheless we should handle pathauto. We should add a configuration option if a alias should be generated or not during import.
The default should be to turn it off.

solved by search_api_default_content_deploy