When using Antlers to filter a collection by a custom date field, the collection does not get filtered.
It is worth noting that is_after and is_before do seem to work with the built in date field, but custom Date fields that you add to blueprints do not.
Create a new Collection & Blueprint with a Date field where the name of this Date field is not date, e.g. date_start. Create a few entries with differing dates. Attempt to filter the collection by your new date field, using is_before or is_after
Here's an example:
{{ collection:events as="events" paginate="12" date_start:is_before="2000-01-01" }}
...
{{ /collection:events }}
Docs reference: https://statamic.dev/conditions#string-conditions
Statamic 3.0.19 Pro
Laravel 8.9.0
PHP 7.4.9
Install method (choose one):
statamic/statamiccan confirm. The "is_future" doesn't work either. The following shows all entries past, current and future:
{{ collection:veranstaltungen scope="veranstaltung" sort="startdate:asc|title:asc" startdate:is_futue="true" }}
...
{{ /collection:veranstaltungen }}
However I can reference entries inside the loop with {{if startdate | is_future }}
startdate in blueprint is:
handle: startdate
field:
mode: single
time_enabled: true
time_required: false
earliest_date: '1900-01-01'
full_width: false
inline: false
columns: 1
rows: 1
display: Start
type: date
icon: date
instructions: 'Startdatum der Veranstaltung'
listable: hidden
Yeah, I'm running into this. Did anyone found a workaround?
Data:
date_start: '2021-01-01'
date_end: '2021-05-31'
Template:
{{ collection:my_collection date_start:is_past="true" date_end:is_future="true" }}
Today it's the 13th of January so I'd expect each entry with the above data to show. The tag returns nothing.
This also doesn't work:
{{ collection:my_collection date_start:is_before="{now}" date_end:is_after="{now}" }}
This however does seem to work. Hopefully it'll help others:
{{ collection:my_collection date_start:lte="{today format='Y-m-d'}" date_end:gte="{today format='Y-m-d'}" }}
+1 Dealing with the same issue, confirming that the workaround is indeed working.
Running into this issue too, on v3.0.45. Workaround from @robdekort does the trick, and gt/lt variants seem to work as well.
Most helpful comment
This however does seem to work. Hopefully it'll help others: