@bspeare

I've gone through this and incorporated @zany's suggestions and fixed a number of phpcs issues and issues with the tests. The module is working as expected for me but this could use another review.

Thanks @crutch. I am still unable to replicate the issue that you are having. Testing this on my 10.2.8 version and the bef_test module on Drupal 11, it fixes the issue that I had with the secondary filters and the weight issue with fields marked secondary and collapsible.

I am not able to recreate that weight issue @crutch. What version of Drupal are you running and could you provide the yml of the view you are using?

Thanks for taking a look @smustgrave. I removed my code suggestion from FilterWidgetBase.php and updated the test to use assertTrue to hopefully show that the field_bef_integer_value is not appearing in the secondary options.

@smustgrave I have added a fix and a test case to https://git.drupalcode.org/issue/better_exposed_filters-3444996/-/compar... if you have time to review.

I've updated the view config in https://git.drupalcode.org/issue/better_exposed_filters-3444996/-/commit... to illustrate how the secondary filters are appearing outside the advanced options toggle. I hope that you are able to import the config and see the issue in the attached screenshot.

I've run through the testing instructions on https://www.drupal.org/project/better_exposed_filters/issues/3444996#com... 💬 Secondary option displays incorrectly after version 6.0.3 Needs work and compared it to the bef_test view in the tests and noticed that this error is only happening for blocks. I think the testSecondaryOptions function would fail if this test was being run on a block: https://git.drupalcode.org/project/better_exposed_filters/-/blob/7.0.x/t....

Have you tried running through these steps on simplytest.me https://www.drupal.org/project/better_exposed_filters/issues/3444996#com... 💬 Secondary option displays incorrectly after version 6.0.3 Needs work ? If you do, you can't even complete the task because of errors like `TypeError: Drupal\better_exposed_filters\Plugin\BetterExposedFiltersWidgetBase::setViewsHandler(): Argument #1 ($handler) must be of type Drupal\views\Plugin\views\ViewsHandlerInterface, null given, called in /var/lib/tugboat/stm/web/modules/contrib/better_exposed_filters/src/Plugin/views/exposed_form/BetterExposedFilters.php on line 598 in Drupal\better_exposed_filters\Plugin\BetterExposedFiltersWidgetBase->setViewsHandler() (line 76 of /var/lib/tugboat/stm/web/modules/contrib/better_exposed_filters/src/Plugin/BetterExposedFiltersWidgetBase.php).`. I also tried writing a test for this but I couldn't my local chromedriver running. Maybe we could jump on a zoom call or Drupal slack huddle and I could show you?

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

The issue appears to be happening within this check https://git.drupalcode.org/project/better_exposed_filters/-/blob/7.0.x/s....

I've noticed the same issue trying to update past 6.0.3.

How to recreate:

1. https://simplytest.me/ 7.0.0-beta1
2. Enable the archive view at /admin/structure/views/view/archive/enable
3. Edit the archive view at /admin/structure/views/view/archive
4. Under filter criteria set both filters to " Expose this filter to visitors, to allow them to change it" and allow multiple for translation filter
5. Turn on Better Exposed Filters for the view
6. Edit Better Exposed Filters settings
7. Check "Enable secondary exposed form options"
8. Set Translation language to "Exposed filter widget" as "Checkboxes"
9. Under advanced filter options for Translation language field check " Make filter options collapsible" and "This is a secondary option"
10. Try to apply and get an Ajax error, I've attached what it looks like testing locally not on simplytest.me below.

The secondary option for the Translation language field is appearing outside the secondary options even though it is set as a secondary option.

Thank you @mandclu!

bspeare → created an issue. See original summary → .

bspeare → created an issue.

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

Thank you for putting this together @pivica! After testing, this does seem like the correct fix for the expected functionality of the fallback image. As it is mentioned on https://web.dev/patterns/web-vitals-patterns/images/responsive-images, it is recommended to "set the width and height attributes to match the dimensions of the fallback image" and this patch fixes that problem.

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