🇨🇦Canada @plousia

+2. I also want to use this for an authored on filter and can't see any way to do that in the UI, either with views basic exposed filters or better exposed filters.

@ maintainer, this might be useful to add to the documentation.

I had to do this and thought I'd write it up for those who may be looking for the same thing. Note that this setup is assuming a single-value image or image media entity reference field on a node, so you don't need to add unique IDs or anything like that as you do with Paragraphs where you may have more than one on the same page.

/**
* Implements template_preprocess_node().
*/

function MYTHEME_preprocess_node(&$vars) {
  $node = $vars['node'];
  $type = $node->bundle();

  switch ($type) {
    // here you will need to replace 'landing_page' with the machine name of your content type
    case 'landing_page':
      // Make sure the image field is not empty.
     // Replace 'field_hero_image' with your content type's image field machine name
      if (!empty($node->get('field_hero_image')->getValue()[0]['target_id'])) {
     // in your node or page template, you will need to add a div with the class "page-hero". Change this class name if needed to whatever you want to use
        $css_selector = ' .page-hero';

        // Here we call the method to generate media queries.
        // We pass in the CSS selector string as described above.
        // We pass in the entity object.
        // We pass in the machine name of the image/media image field.
        // We pass in the machine name of the Responsive Image Style.
        // In this example, I have a Responsive Image Style called 'fullscreen_hero'.
       // Replace the field machine name and the responsive image style machine name to whatever you are using.
        $style_tag = ResponsiveBackgroundImage::generateMediaQueries($css_selector, $node, 'field_hero_image', 'fullscreen_hero');

        // We then check if the media queries were properly generated and attach them to the HTML head.
        if ($style_tag) {
          $vars['#attached']['html_head'][] = $style_tag;
        }
      }

      break;
   }
}

You can also do this in a page preprocess function if you want, although if you use node preprocess and just put a div with the correct CSS class in your page template, it will still work. Here's the page preprocess function, you just need to check if it's a node page:

/**
* Implements template_preprocess_page().
*/
function MYTHEME_preprocess_page(&$vars) {
  $node = $vars['node'];

  if($node) {
    $type = $node->bundle();

    switch ($type) {
    case 'landing_page':
      // Make sure the image field is not empty.
      if (!empty($node->get('field_hero_image')->getValue()[0]['target_id'])) {
        $css_selector = ' .page-hero';

        $style_tag = ResponsiveBackgroundImage::generateMediaQueries($css_selector, $node, 'field_hero_image', 'fullscreen_hero');

        if ($style_tag) {
          $vars['#attached']['html_head'][] = $style_tag;
        }
      }

      break;
    }
  }
}

plousia → created an issue.

@berdir, the patch works for me and solved this issue, thanks. One thing that might help someone, the .diff file wouldn't apply, but when I went to the merge request page and downloaded the .patch file, it applied.

Thanks, as it turned out my sorting issue was the aggregation setting on the date field filter. I was already outputting only the next instance in Twig.

plousia → created an issue.

Figured out what the issue was, in case this may help someone else. My view has aggregation turned on, and the aggregation setting for the "date field > now" filter was set to MIN. Changing it back to the default "group results together" fixed the problem and the events are now sorting according to upcoming date.

I found another weird issue, though. If you set a Smart Date recurring field to "ends on" a specific date, rather "ends after" a certain number of instances, that content doesn't sort properly with content with the date field recurrence set to "ends after". That doesn't seem like the expected behaviour.

Yes.

Thanks. I can't install Smart Date Starter Kit because I already have a content type called "event". But looking at the YML for the view that comes with it, the sorts for the upcoming display are like this:

sorts:
        field_when_value:
          id: field_when_value
          table: node__field_when
          field: field_when_value
          relationship: none
          group_type: min
          admin_label: ''
          plugin_id: '1'
          order: ASC
          expose:
            label: ''
            field_identifier: field_when_value
          exposed: false
          granularity: second

This is the sorts YML for my view, which looks pretty identical, but it's still not sorting by next upcoming date:

sorts:
        field_event_dates_value:
          id: field_event_dates_value
          table: node__field_event_dates
          field: field_event_dates_value
          relationship: none
          group_type: min
          admin_label: ''
          plugin_id: date
          order: ASC
          expose:
            label: ''
            field_identifier: ''
          exposed: false
          granularity: second

Happy to provide any more information that might be needed to diagnose the issue.

Maybe this isn't the issue I should have posted in; I'm just looking to sort in a regular view, not Solr. Is that possible?

I'm having the same issue and wonder if this is getting any attention? It seems like a common use case and a pretty needed functionality.

I have a site with "programs" with recurring dates. I have to be able to display only the next instance of the date, and sort the view on that. The patch in the issue linked in #11 does allow you to output the next instance in a view, but not to sort by it (unless I'm missing something).

Is this formatter intended to allow sorting of a view by the next date instance? I couldn't figure out how to get it working, if so. Checking "force chronological" in the field configuration didn't seem to do anything. Any sorts applied still seem to be working on the first instance, rather than next upcoming.

Patch not working for me. I get:

Applying patches for drupal/menu_token
https://www.drupal.org/files/issues/2023-05-12/menu-token-d10-compqtibil... → (D10 compatibility)
Could not apply patch! Skipping. The error was: Cannot apply patch https://www.drupal.org/files/issues/2023-05-12/menu-token-d10-compqtibil... →

In PluginManager.php(277) : eval()'d code line 331:

Cannot apply patch D10 compatibility ( https://www.drupal.org/files/issues/2023-05-12/menu-token-d10-compqtibil... →
359873-2.patch)!

Thanks for replying. I'll check into the modules you reference. I'm a frontend dev so don't muck around too much with module coding, but maybe Last Delta could provide a starting point for writing something.

plousia → created an issue.

It's a bit late, but I had to do this recently and wrote it up on my blog → .

For all the details, you can read the blog post, but this is the basic technique to get the next date from a Smart Date field and display it in your view. You will put this code in your views-view--fields.html.twig template (renaming it for your particular view as needed, e.g. views-view--fields--view-machine-name--display-machine-name.html.twig). You should also be able to use this in the View UI rewritten field output:

// Create new empty array to push future values to
{% set future_dates = [] %}
// Loop over all date field values; if they are greater than now, push them to the future_dates array. Note that Twig does not have a "push" filter; it's called "merge":
{% for key in row._entity.field_event_dates|keys %}
    {% if row._entity.field_event_dates[key].value > now|date('U') %}
        {% set future_dates = future_dates|merge([row._entity.field_event_dates[key].value]) %}
    {% endif %}
{% endfor %}

// Create variables from the first item of the future_dates array for display. I had to display the date and time separately, hence two variables:
{% set next_date = future_dates[0]|date('F d, Y') %}
{% set next_time = future_dates[0]|date('h:i A T') %}

You can then put the {{ next_date }} and {{ next_time }} variables wherever you need them in your code. Or just create one variable if you don't need to print the date and time separately.

Note that I'm not sure how this will work with Twig caching; your mileage may vary.

Thanks for this patch, this gets me sort of partway to what I need. Two things would be really useful:

1. The ability to combine positive and negative conditions. E.g. for my use case I want to show the block on the first page of a paginated view only, but not any following pages. This sort of works by setting the block visibility to the root url in the normal page visibility setting, and exclude others using Condition Query and this patch with page=* and checking "negate the condition". But this doesn't work if someone follows the pagination link to the first page, as it uses the query string page=0. It would be nice to be able to specify visibility only on the query string page=0, but exclude all others.

2. This leads me to the second useful feature, which would be ranges. If I could do the above plus specify exclusion of a range, e.g. pages 1 to end, that would be perfect. I get the idea you can exclude pages for example with page=*\1,2,3 etc., but it's not possible to keep up with entering exact page numbers on a site with a large amount of content which is being constantly added.

Thirding, this is really a necessity for sites that use Groups and SearchAPI.

FWIW I'm using this patch on a client site and it's working fine, but the client has requested exploded (individual) search terms rather than the whole search string, so one at a time can be cleared. This may be a use case others have as well. For now as a front-end dev I'm just going to have to go a different route and create the functionality with JS, but might be worth considering this as a config option.

Seconding this, came here to look for this issue. I'm not sure the title is the best wording, but the description is spot on. What happens is if you apply enough facets that no results come back, the "reset" functionality and the active filters summary disappear.

This is precisely when you most need the ability to reset or clear filters, when your filters return no results. The user needs to be able to see which ones are active and remove some or all of them till they get results again.

If you use the more specific template suggestion with facet type + facet name, it solves this problem. E.g. facets-item-list--searchbox-checkbox--FACETNAME.html.twig. That may be a pain if you have multiple searchbox facets, but it's a workaround at least till this issue is fixed.

Same issue here, actually my theme picks up and uses the modified template but it stops the links from being converted to checkboxes and throws the same error as in the original report.

After a lot of work I narrowed this down to the fact that I was displaying the region with the facets block twice on the page, once for mobile and once for desktop. Probably not a good idea for performance anyway, so I'll just have to bite the bullet and write the JS to do it properly. Interestingly, once I stopped hiding one of the regions with CSS, the searchbox widget in both regions worked. Maybe relevant information for the maintainers, or anyone else who runs into the same issue.

Hmm switching to the Olivero theme causes the searchbox to work, so must be an issue with my theme. I'll update if and when I'm able to track it down.

plousia → created an issue. See original summary → .

For those who got this patch to work, I'm looking for a little guidance. I set my facets to "disable autosubmit", and added the filter summary with apply button enabled, but my facets are still autosubmitting. I tried enabling ajax but that didn't prevent autosubmit and broke my filters in other weird ways.

Seconded with the reasoning that this is necessary for accessibility.

NickDickinsonWilde → credited plousia → .

#6 worked for me, thanks.