🇪🇸Spain @gxleano

gxleano → created an issue. See original summary → .

gxleano → created an issue.

Seems like Search API's behaviour after adding fields has changed in latest version.

Previously, when you were clicking on "edit-done" kept users on the fields form page, so tests could immediately interact with the new field elements, but now it redirects to the index overview page instead, so those form fields no longer exist on the current page, causing the test to fail.

I've just updated the test to work with the updated version.

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

As far as I was checking, this won't be an issue on 2.0.x where deleteItems() is now abstract.

So, for me the change that was added by @mediabounds, totally make sense only for version 1.2.x

The test testTagifyFacets() is failing, so we would need to check/fix this.

Yep, we should avoid this kind of BC. So, we would need to try the way to filter by name (maybe) and just remove entries which were created by Tagify (tagify and tagify_user_list).

I will try to add this change to the MR, so Darko you could test it and tell us if this is basically "skipping" the BC in your side.

Hey @ruby232!

Thanks to discover and point this out.

You were in the right direction, but you added the changes directly to the 1.2.x branch, I have just moved your changes to a proper branch and made some changes.

Feel free to have an eye on this and check if everything works fine in your side.

gxleano → changed the visibility of the branch 1.2.x to hidden.

In this case, as @herved mentioned, we would need to implement the isApplicable() method to the Tagify BEF filter plugin, then just allow this filter to be applicable to "textfield" types.

In order to understand why textfield is the type we would need to check the TaxonomyIndexTid class which is the views filter plugin for taxonomies, there we have:

    $form['type'] = [
      '#type' => 'radios',
      '#title' => $this->t('Selection type'),
      '#options' => ['select' => $this->t('Dropdown'), 'textfield' => $this->t('Autocomplete')],
      '#default_value' => $this->options['type'],
    ]; 

This is something that would be only applicable for taxonomy entity.

When you try to add a filter criteria using another entity reference field of type node or user, it would not be applicable, you won't have the selection type option.

If we would like to also support select, we would need to create an issue to request this new feature.

In order to have a bunch of icons to test this new implementation, I have provide the iconsets using https://www.drupal.org/project/iconify_icons → 2.0.x, in this case we would just need to:

1. Enable the module
2. Go to /admin/config/iconify_icons/settings and enable the iconsets which we would like to use.

It can be even tested with core iconsets, like navigation. In this case, we would just need to enable the Navigation module and it will be available to be used in the icon_autocomplete form element

In order to test this implementation, we would need to create a new element like:

$form['icon_element'] = [
    '#type' => 'icon_autocomplete',
    '#title' => $this->t('Icon element (NEW 🎉)'),
    '#description' => $this->t('Search and select any icon from all available icon packs.'),
    '#default_value' => '',
    '#required' => FALSE,
];

Evidences:

Artem thanks for the progress there, just a minor thing, I would point this to 2.0.x instead of 1.2.x then you could even try what Scott is suggesting

I don’t see any issue with including this field among the default indexed metadata. In fact, capturing the language of each item is valuable for filtering or language-aware queries. So, I’d support adding it by default.

So, if you are agree Scott, we could move it to RTBC, it looks good to me.

It looks good to me.

Thank Artem and everyone involved!

Look good to me, Luca!

Nice addition, thanks.

LGTM!

Thanks Luca

I've been testing including:

1. https://www.drupal.org/project/search_api/issues/3551144 ✨ Make IndexBatchHelper a service so it can be overridden Needs review
2. https://www.drupal.org/project/ai_vdb_provider_milvus/issues/3553054 📌 Add embedding_validator dependency to MilvusProvider Active

and everything works as expected.

Thank you very much Scott.

gxleano → created an issue.

It looks good to me @grimreaper!!

gxleano → created an issue.

We would also need to check the VDB providers which are extending from AiVdbProviderClientBase and need to include embeddingValidator.

The code looks good to me so far Scott.

After we include this on 2.0.x we could handle https://www.drupal.org/project/ai_provider_openai/issues/3552523 ✨ Opt-in to cache embedding lookups Active

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

And yes, it is also not completed 😂

Thanks Scott!

I was just checking what there was done, and what we should do here.

Currently working on it.

I would say that this issue could be move to Fixed after https://www.drupal.org/project/ai/issues/3477973 📌 Dynamically load Tokenizer after selecting Embedding Engine Postponed is validated.

1. https://www.drupal.org/project/iconify_icons →
2. https://www.drupal.org/project/tagify →

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

Thanks @ishani patel, it is already working as expected

So, moving to RTBC.

There is a related issue with the other boost plugins which will be fixed here: https://www.drupal.org/project/search_api/issues/3550113 🐛 Undefined array key "boosts" warning in NumberFieldBoost processor on Drupal 11 Active

gxleano → created an issue.

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

It will be included on 1.2.1 release

I would like that someone could take a second look on this after been moved to 2.0.x

Moving this to 2.0.x because of it is not a bug fix, so it could wait.

Will do, thanks Artem for review it.

Thanks @tmiguelv to do a second test there.

Moving it to RTBC.

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

Yep, thank you Marcus!

So, we have added a new logic with three possible scenarios:

Title NOT in contextual content + exclude_title FALSE (default) -> Title IS auto-added
Title IS in contextual content + exclude_title FALSE -> Title NOT auto-added
Title NOT in contextual content + exclude_title TRUE -> Title NOT auto-added

So, we would add the title automatically when it is not added as contextual content and the option "exclude_title" is FALSE?