🇸🇮Slovenia @bcizej

Merged, thanks.

@deaom I don't understand this PR. Why would the module include DDEV setup? This issue was suppose to just add info to the readme on how to add meilisearch service locally for testing (either by using docker image or if using DDEV - to use Kevin's plugin).

Also why was the issue text updated with all that? Was that a mistake and was supposed to be a comment?

Anyway, this PR is above what it was suppose to do, moving back to needs work.

Does this also mean that the meilisearch service itself must be ^15? Or does this php library work with lower service versions?

Branch rebased and targeted to 3.x branch

Merged, thanks.

Changed target branch of the PR to 3.x

Rebased branch

PR created

bcizej → created an issue.

Branch rebased, added tests and used a separate parser class for booleans.

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

Merged, thanks.

Branch rebased

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

Deprecations and ci pipeline have been updated.

@natemow The commit has been reverted as it is not a part of the ticket and the plugin should not be extended anyway. Use composition if needed.

Closing as duplicate of 📌 D11 Compatibility Active

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

A fix has been merged. Thanks.

Thanks, merged.

Merged, thanks.

The module can be uninstalled since it is obsolete.

The module is obsolete and not required since Drupal 10.2.

As mentioned in the comments, the module is no longer required and is obsolete.

Thanks for the PR. I've cherry picked your commit to the feature branch (the commit was on the 1.x branch) and used a PHP 7 compatible function as the module still has Drupal 9 compatibility listed and that version supports PHP 7.

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

PR created. The "Remove" button will be displayed only for reference fields that are not in a paragraph or fields that have a fixed cardinality. In other cases there is already a "Remove" button displayed that handles removing fields/values.

Merged, thanks.

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

@tgoeg Thanks for reporting this.

I have added a draft MR that could be tested. The idea behind the solution/workaround is before indexing items, go through all the fields and for any numeric types add a duplicated field to the index with __facet__ prefix and a value converted to string. Then when generating facets we go through each one and check if any of them are numeric type - if they are run the facet query on meilisearch with prefixed __facet__ instead of the original one. At the end move those __facet__ results to the proper/original facet.

Patch can be tested but it is nowhere ready for merging or production, it is in mvp state and there are issues with filterableAttributes re-setting sometimes, losing the __facet__ prefixed attributes etc.

Can be tested by applying the patch, having a numeric field in the index and reindexing the entire index.

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

At the moment there is no item boosting implemented. It should be possible to add a new "boost" attribute or similar to each document and have a custom ranking rule "boost:desc" as per https://www.meilisearch.com/docs/learn/core_concepts/relevancy#custom-rules.

This will require code changes so I'm updating the issue.

I went ahead and merged this. If the same problem impacts sortable attributes we will fix them in another issue. Thanks.

@ravi kant

There is an update hook that sets the default value via drush updb. I don't see any style breaking on my side.

Hi @tobiasb

Thanks for the report. IIRC we added a sort function to compare old and new searchable attributes so that we don't do unnecessary setting changes to Meilisearch index (which causes reindexing of every item). But given the fact that the order of attributes impacts relevancy - we should not sort them which the PR fixes.

I wonder if the same issue also impacts sortable attributes because we also use sort() on them...

@ravi kant

Yes, I managed to add settings field and overrided the toasts template to load the proper attribute from config.

I added a PR that fixes the template and adds a new setting field. I don't know if this will be merged but it might be helpful for others on how to modify their subtheme if needed.

bcizej → created an issue.

If this issue at hand is available as a submodule, I think I can offer testing. It's just that I am currently stuck on 1.x, as the upgrade to 2.x breaks my facetted searches, even when I add the new facetting submodule. No errors whatsoever, I just don't get any results, but that's a different story.

Feel free to open an issue with as much info as possible, there might be some hidden issues we are not aware of.

I'm not really sure what to make of this feature as it is now. I think this goes way above what the base module should provide as I explained in #2. If this is moved to a submodule as perhaps a separate backend provider (so user can choose standard connector or advanced connector with keys management, auto generate keys for specific indexes etc.) then I'm ok with it. But in the current form of this PR I do not want to merge it. For this reason I'm setting the status to back to "Needs work".

What I do agree here is that current connector should not use master key, but API and Search key fields should be configurable and used instead. But this is a breaking change as current installations would need to update configuration manually and a separate issue should be opened on how to best deal with this.

Nice thanks, although I use custom docker-compose.yml, other contributors here use a DDEV setup with custom meiiisearch service added, this comes in handy to get the environment up and running easily.

I'll update the readme when I get the chance, it is missing a section for development (setting up, running automated tests. etc), and include the link to the addon.

Ready for review.

bcizej → created an issue.

Branch rebased and added DI for event dispatcher.

Ported to 2.x as well, thanks.

Commited to 1.x, needs porting to 2.x

Merged, thanks.

I think @admirlju explained everything, Meilisearch does not have a concept of cores like Solr so I am closing this issue.

@admirlju Do we still need to do something here? This issue as you mentioned would only occur if reindexing happened while on the dev branch in between the issues we were fixing regarding the document id and @tgoeg probably did the reindexing between the issues. If I remember correctly we added a BC which had to be reverted.

I'm closing this issue for now, feel free to reopen if I missed something.

Merged, thanks.

Merged, thanks.

I think merging this right now is too soon. Yes D9 is EOL but I'd like to keep the support for D9 for now. If it's the external dependency the issue, we could write our own adapter seeing that the dependency has a few lines of code anyway.

Version 2.0.0 → has been released. Thanks everyone for your contributions.

Merged, thanks.

Merged, thanks. Any issues regarding facets can use the "Facets" option from "Component" dropdown.

I've added an "Autocomplete" option to the "Component" dropdown so any issues regarding autocomplete submodule can use that option.

Branch rebased.

Merged, thanks.

I have removed the condition to skip filtering if "zxx" and "und" language are in filter. I also fixed the test as it was under incorrect namespace and was missing @group tag.

Needs a test for when autocomplete settings has a min/max limit set to make sure this works properly.

Rebased, cleaned up the code and used query limit from settings.

Merged to 2.x as well.

Thanks, merged but needs to be applied to 2.x as well.

Merged, thanks.

This works but we should use hidden and always enabled processor plugin https://www.drupal.org/docs/8/modules/search-api/getting-started/processors → .

Search method is already bloated with code and we will need to do some cleanup in the future but we can start here :)

Ready for review.

bcizej → created an issue.

Merged, thanks.

Rebased and merged, thanks.

Merged, thanks.

Used EXISTS operator for null value operator parser and uncommented tests

Can be reviewed

Needs rebase

Ready to move forward.

Ready to move forward.

Merged, thanks.

The new version of meili changed their naming from MeiliSearch to Meilisearch and the namespaces were not updated to match that, so changed that.

Good catch, thanks.

For whatever reason, locally the QueryFilterTest the testFiltersWithSpecialCharacters is failing for me, but here it seems it passes.

Did you update the meilisearch docker image to v1.3.3? The only reason I see tests failing locally is with v0.28.1 as the parser was updated to escape backslashes properly.

Merged, thanks.

Merged.

bcizej → created an issue.

Merged, thanks.

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

Merged, thanks.

bcizej → created an issue.

bcizej → created an issue.

bcizej → created an issue.

I created a 1.1.0-rc release → which still uses v0.28 so the users are not stuck on the ancient and mostly broken 1.0.0 release while we work on creating a 2.x release supporting the latest meilisearch server.