🇺🇦Ukraine @khiminrm

Can't find what causes the bug. But noticed that it not happens if I return empty results just before $value = $style->getField($row->index, $field_id); in Selective::getOids() like this:

          return [];
          $value = $style->getField($row->index, $field_id);
     

If I add return []; after $value = $style->getField($row->index, $field_id);, the error appears again. So during rendering somehow the drupalSettings receives newly generated view_dom_id and cached.

I've just used custom fix to remove doubled view_dom_id:

function my_module_js_settings_alter(array &$settings, AttachedAssetsInterface $assets) {
  if (empty($settings['views']['ajaxViews']) || count($settings['views']['ajaxViews']) == 1) {
    return;
  }
  // Fix bug with doubled view_dom_id for views with selective filters.
  $view_name_display_dom_ids = [];
  foreach ($settings['views']['ajaxViews'] as $dom_id => $ajax_view) {
    $view_name_display_dom_ids[$ajax_view['view_name']][$ajax_view['view_display_id']][] = $dom_id;
  }
  foreach ($view_name_display_dom_ids as $displays) {
    foreach ($displays as $dom_ids) {
      if (count($dom_ids) > 1) {
        unset($settings['views']['ajaxViews'][$dom_ids[0]]);
      }
    }
  }
}

But would be nice to fix source of the issue.

khiminrm → created an issue.

@joelpittet thanks! you was right. I've debugged js and received error in parseQueryString in line:
key = decodeURIComponent(pair[0].replace(/\+/g, ' '));

I've created patch to fix that and it looks like it fixes the error.

khiminrm → created an issue.

Adjusted the same fixes from #7 to the latest dev version

I've faced with the same issue. Any solution?

When exposed form in block, all attributes including classes are moved from the form to the block. In the latest patch only form is replaced. It can produce some bugs. For example if using better_exposed_filters and exclude text fields from autosubmit, it will not work after ajax replace of the exposed form https://git.drupalcode.org/project/better_exposed_filters/-/blob/7.0.x/j.... So it would be better to replace block and not only form.
So we need to improve somehow this:
$response->addCommand(new ReplaceCommand("form[id^=\"views-exposed-form-$view_id\"]", $this->renderer->render($exposed_form)));

When using multiple instances of the exposed form block for the same view on one page, both forms are updated but only for one of them the behaviors are attached. Any ideas how to fix that?

This patch fixes only views in blocks, but not exposed forms in blocks as in https://www.drupal.org/project/drupal/issues/3032353 ✨ Exposed forms in a block are not currently updated when Ajax filtering is executed Needs work , right?
Trying to find out how to fix conflicts between patches from both issues and apply to project I'm working on now.

@david-urban

I didn't notice such bug, but I haven't not tested on Core 11.x yet.
Maybe try to check template for the view. It could be that footer and pagination are outside the view's main 'div' wrapper.
You can check also ViewAjaxController how it replaces content during ajax call so you will have idea what actually is replaced on a page.

I've another one bug https://www.drupal.org/node/3163299 → and those patch conflicts with this one in similar lines of code. Have not tried yet though. Trying to compare both patches. I hope those issue's patch will work for all cases.

attaching patch for the 3.0.0 with the fix and condition from 3.0.x-dev

khiminrm → created an issue.

I need this feature too.
As a quick solution I've taken javascript from the facet's module soft-limit.js, modified it to use hardcoded limit, labels, selectors and used it in custom theme. But still need to exclude some filters.

  function softLimit() {
    // Soft limit.
    var limit = 15;
    var zero_based_limit = (limit - 1);
    var facetsList = $('..bef-checkboxes');

    // Hide facets over the limit.
    facetsList.each(function () {
      var allLiElements = $(this).find('.form-check');
      $(once('applysoftlimit', allLiElements.slice(zero_based_limit + 1))).hide();
    });

    // Add "Show more" / "Show less" links.
    $(once('applysoftlimit', facetsList.filter(function () {
      return $(this).find('.form-check').length > limit;
    }))).each(function () {
      var facet = $(this);
      var showLessLabel = Drupal.t('Show less');
      var showMoreLabel = Drupal.t('Show more');
      $('<a href="#" class="facets-soft-limit-link"></a>')
        .text(showMoreLabel)
        .on('click', function () {
          if (facet.find('.form-check:hidden').length > 0) {
            facet.find('.form-check:gt(' + zero_based_limit + ')').slideDown();
            facet.find('.form-check:lt(' + (zero_based_limit + 2) + ') a, .form-check:lt(' + (zero_based_limit + 2) + ') input').focus();
            $(this).addClass('open').text(showLessLabel);
          }
          else {
            facet.find('.form-check:gt(' + zero_based_limit + ')').slideUp();
            $(this).removeClass('open').text(showMoreLabel);
          }
          return false;
        }).insertAfter($(this));
    });
  }

Looks like I've found solution how to get min and max values regardless active other filter.
By making additional query without other active facets in custom query type processor's build() method:

  /**
   * {@inheritdoc}
   */
  public function build() {
    $field_identifier = $this->facet->getFieldIdentifier();
    $execute_additional_query = FALSE;
    // Check if there are any other active facet filters,
    // if yes - we need to unset them and execute additional query to get min and max.
    $new_query = clone $this->query->getOriginalQuery();
    $condition_groups = &$new_query->getConditionGroup()->getConditions();
    foreach ($condition_groups as $group_key => $condition_group) {
      if (!($condition_group instanceof ConditionGroupInterface)) {
        continue;
      }
      $tags = $condition_group->getTags();
      if (empty($tags) || $condition_group->hasTag('facet:' . $field_identifier)) {
        continue;
      }
      $has_facet_tags = FALSE;
      foreach ($tags as $tag) {
        if (str_starts_with($tag, 'facet:')) {
          $has_facet_tags = TRUE;
          break;
        }
      }
      if (!$has_facet_tags) {
        continue;
      }
      $conditions = &$condition_group->getConditions();
      foreach ($conditions as $key => $condition) {
        if ($condition instanceof ConditionInterface &&
          $condition->getField() !== $field_identifier) {
          unset($conditions[$key]);
          $execute_additional_query = TRUE;
          if (!count($conditions)) {
            unset($condition_groups[$group_key]);
          }
        }
      }
    }

    if ($execute_additional_query) {
      $facets = $this->query->getOption('search_api_facets');
      $new_query->setOption('search_api_facets', [$field_identifier => $facets[$field_identifier]]);
      $new_query->setProcessingLevel(QueryInterface::PROCESSING_NONE);
      $new_query->getOption('search_api_view', NULL);
      $this->results = $new_query->execute()->getExtraData('search_api_facets')[$field_identifier] ?? [];
    }

    parent::build();
  }

Hi!
Is there any ready solution for the facets exposed filters to be able to create date range filter?

khiminrm → created an issue.

I've created patch for the bef_sliders.js
I've using custom widget plugin which extends Sliders widget and adding configs for the tooltips like:

    $form[$filter_id]['#attached']['drupalSettings']['better_exposed_filters']['slider_options'][$filter_id]['tooltips'] = TRUE;
    $form[$filter_id]['#attached']['drupalSettings']['better_exposed_filters']['slider_options'][$filter_id]['tooltips_value_suffix'] = '$';

khiminrm → created an issue.

Fixed compatibility with the better_exposed_filters 7.x

@erindarri I posted patches there https://www.drupal.org/node/3470665 →

Added small fix to have 'fieldset' wrapper around the filter.

Fixed errors when there are no results.

Removed better_exposed_filters from the dependencies as had error during applying patch with composer install

Created patch with the bef widget plugin 'Glossary AZ'. So after adding facet exposed filter for the glossary field, configure exposed form to use better_exposed_filters and for the filter use 'Glossary AZ'. The plugin is based on the Links widget from the bef module. Tried to re-use as much code as possible.

I've also included fixes from the https://www.drupal.org/project/search_api_glossary/issues/3492668#commen... 🐛 TypeError: Cannot access offset of type string on string Active

First, we need this fix https://www.drupal.org/project/search_api_glossary/issues/3492668#commen... 🐛 TypeError: Cannot access offset of type string on string Active

Second, we need to apply theming to existing widget e.g. disable items without results or we need to create custom widget plugin, maybe for the better_exposed_filter.

added first fixes there https://www.drupal.org/project/search_api_glossary/issues/3492668#commen... 🐛 TypeError: Cannot access offset of type string on string Active

Looks like it's progress. Now we need to apply styles for the widget or create custom new one.

Closing this ticket for now. Will work in the related issues for the search_api_glossary.

Maybe it would be better to create some abstract base class for the plugins, move supportsFacet() to it and extend the class by the existing processor plugins.

Created patch according to my previous comment

I will try to improve conditions in the supportsFacet() methods of the search_api_glossary module's facet processor plugins and then create exposed form widget with correct items styles. Related issue https://www.drupal.org/project/search_api_glossary/issues/3497960 🐛 When using Facets Exposed Filters the Glossary AZ is not available Active .

I think the patch is wrong.
The processor plugins will not apply to any facet with these fixes.

In case of using exposed filters and trying to configure a facet filter $facet->getWidget() returns '' string.
When configuring facet in old way e.g. on facet create/edit page the same code returns associative array with 'type' and 'config' elements.

I think we need to improve code of the supportsFacet() in such way so it will work in both cases. And we could fix this https://www.drupal.org/project/search_api_glossary/issues/3497960 🐛 When using Facets Exposed Filters the Glossary AZ is not available Active

Trying to fix it now...

khiminrm → created an issue.

Created patch from the MR

Changed code to get labels from the value options of the selective filter.

Added small fix to remove new lines from the value.

After testing and debugging other cases, I've reverted almost all changes and just improved one condition as $field->getValue($row); can return FALSE when value of a field is empty. In Drupal\views\Plugin\views\field::getValue():

    if ($field_item_definition->getFieldStorageDefinition()->getCardinality() == 1) {
      return reset($values);
    }

And added one more

        if (is_null($key)) {
          continue;
        }

just in case the code inif (!is_scalar($key) || $key === FALSE) { returns NULL for the $key.

I've noticed that current solution doesn't work when we have initial value for the exposed form's param in a URL. For example we have redirected to the ajax views page from search form on a site from another page. And then we change search keyword which have been submitted by ajax. So I've improved the patch by using query params from the AJax request, but path from the referrer.

@feyp Thanks! I will try.

Hi!
I've faced with similar issue today when tried to update composer lock file.

Your requirements could not be resolved to an installable set of packages.

  Problem 1
    - Root composer.json requires drupal/core-recommended == 10.2.6.0 -> satisfiable by drupal/core-recommended[10.2.6].
    - roave/security-advisories dev-latest conflicts with twig/twig <1.44.8|>=2,<2.16.1|>=3,<3.14.
    - drupal/core-recommended 10.2.6 requires twig/twig ~v3.8.0 -> satisfiable by twig/twig[3.8 (alias of v3.14.0)].
    - Root composer.json requires roave/security-advisories == dev-latest -> satisfiable by roave/security-advisories[dev-latest].

How I can fix it with this version of the Drupal core without removing roave/security-advisories?
I've tried to apply patch from the https://git.drupalcode.org/project/drupal/-/merge_requests/9461.diff, but composer couldn't apply the patch.
We should wait when the fixes will be merged and update the core on next release?
Maybe we can use some temp solution until update?

Thanks!

@smustgrave thanks for the reply!

But I didn't write about jQuery. I've just compared code in bef_sliders.js between 6.0.x and 7.0.x and they look similar, no? but the issue exists and I'm not sure this is somehow related to jQuery.

I've just created some draft code to set form state values for the field in custom validation function for the exposed form and looks like it works. But not sure maybe there can be better solution.

My draft temp solution:

function _my_test_module_exposed_validate(&$form, FormStateInterface $form_state) {
  $values = $form_state->getValues();
  if (!isset($values['price_range'])) {
    return;
  }
  $options_min = $form['price_range']['#attached']['drupalSettings']['better_exposed_filters']['slider_options']['price_range']['min'];
  $options_max = $form['price_range']['#attached']['drupalSettings']['better_exposed_filters']['slider_options']['price_range']['max'];
  if ($options_min == $values['price_range']['min'] && $options_max == $values['price_range']['max']) {
    $values['price_range']['min'] = '';
    $values['price_range']['max'] = '';
    $form_state->setValues($values);
  }
}

khiminrm → created an issue.

Fixed option labels.

@mably thanks a lot for adding these fixes! sorry I can't re-test it right now. I hope it will work as expected. Thanks again!

Patch from #25 also works for me on Drupal 10.2.6

@mably thanks!

In our case we're using exposed form block with autocomplete search from one view in header of a site and another exposed form block in sidebar region on the views page (another one view). So there are two different exposed form blocks on one page. I know that there can be rare cases when on one page we can have even multiple exposed forms for the same view e.g. to show some filters above the view's results and other filters in sidebar etc.

I see that committed fixes don't include fixes to get correct exposed to submit in case when there are multiple exposed form blocks from different views on one page. I mentioned about it in https://www.drupal.org/project/views_filters_summary/issues/3345403#comm... 🐛 Remove link removes all filters Fixed and added some additional code changes to fix it. So in current dev version we potentially can face with the same issue.

Thanks! Works for me.

Faced with the same as described in #5 🐛 'Selected 0 items in this view' displayed instead of the total item count Needs review . In my case the views used style https://www.drupal.org/project/views_secondary_row → so class 'vbo-table' wasn't added in function views_bulk_operations_preprocess_views_view_table(&$variables). And in frontUI.js the var $viewsTables = $('.vbo-table', $vboForm); was null. I've added the class in custom theme's preprocess and it fixed the bug for me. It worked with and without the patch. I hope it will help someone else in similar cases.

Partially I was able to fix it. Need to find solution how to run custom code with setting pre-defined 'list' only before user changes the selection.

khiminrm → created an issue.

Removed some lines from the patch which are related to another issue.

I've noticed some other bugs e.g. not empty value when twig debug is enabled (so I've moved striping tags earlier and added removing new lines in a value), also noticed errors when $key is not numeric but Entity Storage is selected and I think we need to improve logic when we need to build empty value
$value = $this->t('Empty (@key)', ['@key' => empty($$sub_key) ? json_encode($sub_key) : $sub_key]);

I've noticed similar bug described there https://www.drupal.org/project/views_filters_summary/issues/3378822 🐛 Alter means of testing if a view is ajax-enabled Needs review . I had destination parameter in URL and the page was reload on clicking links in the filters summary. So I've updated javascript and added some more specific selectors for the submit buttons:

I used patch from #2 with patch from https://www.drupal.org/project/views_selective_filters/issues/3469960 ✨ Add support for the multiple value reference fields? Active .

khiminrm → created an issue.

And updated selector in javascript in case if there are multiple exposed forms for the same view on one page

I've improved a little the exposed form selector to be more precise.

Noticed bug. when after last the patch the exposed filter block has been refreshed - the exposed form is not submitted by Ajax second time - with page reload.

I've fixed bug with empty "exposed_form_display" mentioned in #45

I see that the VBO is already deleted. So we need other solution. Updated also https://www.drupal.org/project/views_bulk_operations/issues/3469974 🐛 There are no checkboxes when the views_selective_filters filter is added. Active

Ideas?

I see that VBO field is already deleted before executing $view_copy.
Maybe we can introduce some new view property e.g. do_not_init_vbo_form so other modules like views_selective_filters can use it?

and we could have condition like?

   // Don't initialize if view has been built from VBO action processor or other modules which do need to init VBO form.
    if (!empty($this->view->views_bulk_operations_processor_built) || !empty($this->view->do_not_init_vbo_form)) {
      return;
    }

I think I've found some draft solution on local test site. Improve condition in ViewsBulkOperationsBulkForm::init():

    // Don't initialize if view has been built from VBO action processor.
    if (!empty($this->view->views_bulk_operations_processor_built) || !empty($this->view->selective_handler_signature)) {
      return;
    }

So we need somehow remove VBO field from $view_copy before executing it in Drupal\views_selective_filters\Plugin\views\filter\Selective::getOids().

Any ideas how it would be better to do?

Thanks!

I think I've found some draft solution on local test site. Improve condition in ViewsBulkOperationsBulkForm::init():

    // Don't initialize if view has been built from VBO action processor.
    if (!empty($this->view->views_bulk_operations_processor_built) || !empty($this->view->selective_handler_signature)) {
      return;
    }

So we need somehow remove VBO field from $view_copy before executing it

khiminrm → created an issue.

khiminrm → created an issue.

another one noticed bug. with added selective filters the bulk operations checkboxes have disappeared from the view :((

weird, when I add sorting by product variation SKU - I have expected two rows in results of the $view_copy for the filter. Without sorting - 1 row. But in original views results I always get 2 results regardless there is or not sorting.

I've partially fixed it with a draft quick patch. The filter contains values now - separate terms as options. But for some reason $view_copy->result contains only one first row, so I don't have values from the second row in the results of the view.

khiminrm → created an issue.

I agree with #32. On a site with a lot of entities I can't even add and configure the filter. We need some better solution if it's possible.

jsacksick → credited khiminrm → .

I've fixed dependency injection, module dependencies and other noticed code issues. Please, re-view and test.

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

attaching a patch for 1.0 for those who is using this patch https://www.drupal.org/project/advancedqueue/issues/2918866#comment-1561... ✨ Add support for unique jobs Fixed

khiminrm → created an issue.

Created new issue https://www.drupal.org/project/advancedqueue/issues/3460188 🐛 In some cases the duplicated jobs are created Active

khiminrm → created an issue.

Hi!

When testing the patch, I've noticed that it's not always working properly.

I will try to explain. I've tested it with commerce_recurring.
The job payload is simple: ['order_id' => $order->id()]
So I've run the 'Commerce Recurring' cron job to process a recurring order. The job has created two queue items:
with types commerce_recurring_order_close and commerce_recurring_order_renew with payload {"order_id":"230185"}.
Then I've run the 'Advanced Queue' cron job. It has processed the queue items. One of them was failed due to another issue not related to this one. And another one was successfully processed. So I had two queue items with states failure and

success</code at those moment.
But after running the  'Commerce Recurring' cron job again, two new queue items with the same payload and fingerprint were created. So the items were duplicated.
And if ran the the  'Commerce Recurring' cron job again without running the the 'Advanced Queue' cron job before it, the duplicates are not created, because the items had state <code>queued

and they were found as duplicated.

So, I think we should remove condition where we check only two states in the getDuplicateJobs() method:
->condition('state', [Job::STATE_QUEUED, Job::STATE_PROCESSING, Job::STATE_FAILURE], 'IN');

Please, review and re-test if possible. I'm attaching the updated patch from #125 for 1.0 and interdiff.

Thanks in advance!

Added a simple command