Support for Drupal 7 is ending on 5 January 2025—it’s time to migrate to Drupal 10! Learn about the many benefits of Drupal 10 and find migration tools in our resource center.
I need to create a view that shows currently ongoing exhibitions which may or may not have end dates (this is for a museum). In other words, nodes should be shown if their start date is in the past, and their end date is in the future or they have no end date.
I thought I could create a view with the following filters:
start date <= now
AND
( end date >= now OR end date == null )
But this doesn't work because nodes without an end date get filtered out. Apparently blank end dates aren't null. Anybody know how I can get this working?
Thanks
Comments
Comment #1
arlinsandbulte CreditAttribution: arlinsandbulte commentedBlank end dates are automatically populated with the same value as the start date. See #874322: To Date & All Day Date Handling & #523218: Default value for To date: Blank should stay blank for more details.
This might work, but IIRC, I don't think two date fields can be compared (can't do start date = end date in views)
( start date <= now AND start date = end date )
OR
( start date <= now AND end date >= now )
Comment #2
eusonic CreditAttribution: eusonic commentedThanks arlinsandbulte,
I'm fairly certain Views filters can't compare two fields. This may be possible with the Views PHP module, but that's a hack I'd like to avoid.
Another idea is to use separate fields for start and end dates, then null should function as expected. However, I suspect this will make it impossible to display multi-day nodes properly with the Calendar module.
Comment #3
das-peter CreditAttribution: das-peter commentedI've just encountered this issue too, for me this is definitely a bug.
Because I use already the date views module I decided to extend the filter handler in a very pragmatic way.
If the filter "empty" or "not empty" is used for an end-date value the handler adds a comparison with the from-date value now.
Now the filter seems to work as expected :)
Comment #5
das-peter CreditAttribution: das-peter commentedLooks like the failed tests are related to Migrate (
Class 'Migration' not found
) and not the changes I made.Comment #6
das-peter CreditAttribution: das-peter commented#3: date-views-filter-handler-end-date-fix-1635810-3.patch queued for re-testing.
Comment #8
das-peter CreditAttribution: das-peter commented#3: date-views-filter-handler-end-date-fix-1635810-3.patch queued for re-testing.
Comment #10
arnested CreditAttribution: arnested at Reload commented#3: date-views-filter-handler-end-date-fix-1635810-3.patch queued for re-testing.
Comment #12
das-peter CreditAttribution: das-peter commented#3: date-views-filter-handler-end-date-fix-1635810-3.patch queued for re-testing.
Comment #14
Renee S CreditAttribution: Renee S commentedAny luck on this? It's totally what I'm looking for too :)
Comment #15
das-peter CreditAttribution: das-peter commented#3: date-views-filter-handler-end-date-fix-1635810-3.patch queued for re-testing.
Comment #17
jannis CreditAttribution: jannis commented#3: date-views-filter-handler-end-date-fix-1635810-3.patch queued for re-testing.
Comment #19
kong CreditAttribution: kong commentedSubscribed.
Comment #20
shadysamir CreditAttribution: shadysamir commentedThe patch in #3 did not pass tests of date repeat and date migrate, which I dont use in my site, so I decided to apply it regardless. Works great, but it's still a hack around the main problem: Optional empty end date should be NULL
Comment #21
iamEAP CreditAttribution: iamEAP commentedI have a hunch that the automated tests are failing regardless of the patch (e.g. current HEAD is broken for unrelated reasons).
Comment #22
thinkyhead CreditAttribution: thinkyhead commentedIn the site I'm working on the expected behavior for the exposed date filter is that a "between" search with a blank end date should be treated as a ">=start_date" search. (Using "now" as the end date is wrong because we also want to see future items.) That makes the most sense to me for any exposed date filter that's set to "between." Setting it the same as the start date is presumptuous and semantically confusing for users. At the moment a blank end date in the form is just causing it to do no date filtering at all, which must be a bug.
(I'm using Date module 7.x-2.6)
Comment #23
das-peter CreditAttribution: das-peter commentedCould please someone confirm that the patch works? I can't imagine that the test fails have something to do with the patch. They fail because the Migrate class couldn't be enabled - but this patch has nothing to do with Migrate.
If nobody has encountered any errors with the patch and it solves the problem for you, please set this issue to RTBC.
Comment #24
iamEAP CreditAttribution: iamEAP commentedCan confirm the patch works as advertised. Have been running this in prod for nearly a month.
Comment #25
Anonymous (not verified) CreditAttribution: Anonymous commentedHello I have a similar issue with dates:
I'm selling training session on a website, they can be over 1 or 2 days.
If the training session is over 2 days I would like to display: "from 23/07/2013 to 24/07/2013" and if the training session is on 1 day: "23/07/2013".
I have created 2 fields into my view: "Start date" (hidden) and "End date".
If "End date" is empty, it should display the "Start date" value.
However "End date" is never empty...
This patch didn't fix this issue.
Any idea?
Cheers
Comment #26
mesr01 CreditAttribution: mesr01 commentedPatch #3 worked for me. Thanks @dat-peter!
Comment #27
codecouleurs CreditAttribution: codecouleurs commentedBut with this patch, we can't published a content just one day because start date = end date is equal to no end date...
The best way in my opinion is really not populate end date when the checkbox "Define an end date" is uncheck so we can test if there is really no end date or if we choose to set the end date same as the start date.
In association with a help text in date field configuration to say that an uncheck checkbox "Define an end date" means published all the time.
What did you think about it ?
Comment #28
manuelBS CreditAttribution: manuelBS commented+1 to #27
Comment #29
Anonymous (not verified) CreditAttribution: Anonymous commentedComment #30
cimo75 CreditAttribution: cimo75 commented+1 to #27 too
Comment #31
das-peter CreditAttribution: das-peter commentedGuy's if you say +1 to #27 this means "needs work". And for the maintainers of views is not really useful to have a patch that's not ready marked as RTBC ;)
Btw. I'm absolutely fine with this, but currently it's unlikely that I find some time to dig deeper and fix it.
Thus, if someone has an idea how to fix it please feel free to take over.
Comment #32
erinclerico CreditAttribution: erinclerico commented#3: date-views-filter-handler-end-date-fix-1635810-3.patch queued for re-testing.
Comment #33.0
(not verified) CreditAttribution: commentedminor correction
Comment #34
Charles BelovThe issue is not so simple. There can be multiple reasons for the lack of an end date:
1. Something begins, and will end when something else is put in its place, e.g., a policy.
2. Something begins, and will end on some future date when it's done, e.g., an open-ended stage run or construction with no fixed schedule.
For items 1 and 2, if there must be something in the end date, the most future date possible would seem to be most appropriate, e.g., Dec. 31, 9999, or whatever the maximum date value is. (Sorry if I'm setting us up for a Y10K problem.) Views could already test for this.
The ideal English date display for items 1 and 2 would be: Effective [start date]
3. Something begins, and will probably end on the same day, when the work for that day is done, e.g., a public hearing, or at worst case in the wee hours after midnight early the next morning.
4. There is also the idea that something is being published, and it will always have been published, but at some point it won't be particularly interesting that it's been published, e.g., a press release that is not about something that has a definite end time. (But we can't just drop the start and end dates off, because there are press releases that do concern matters with specific end times.)
For item 3 or 4, if there must be something in the end date, having the same start and end date would seem to be appropriate, and issue #1635810 would be needed to solve it.
The ideal English date display for items 3 and 4 would be: [start date]
For completeness:
5. There is a definite interesting, typically future, start date and a definite interesting end date, both known, e.g., definitely scheduled construction.
This of course is what date entry is best set up for, as there is no ambiguity, and is already solved. Enter the start and end date.
The ideal English date display would be: [start date] - [end date] or [start date] to [end date] or [start date] through [end date]
6. The start date is in the relatively distant past. Whether or not it is known, there is no particular reason to display it, e.g., a bus route that is about to be discontinued.
In this case, it's easy to know what to put in for the end date, but not for the start date. Ideally, the start date would be the most past date it is possible to display in a Drupal date field, e.g., Jan. 1, 0001. Again, we would never want to display this date.
The ideal English date display would be: Through [end date]
That said, one could reasonably argue that item 6 is just a contrary way of stating item 1. Still, it would be nice to be able to express item 6 in case there's a use case, and to be consistent with how I'm proposing we handle end date.
I think it is too much to ask staff to have to put in Dec. 31, 9999, or put in identical times for start and end, so ideally in place of the check box Show End Date, there would instead be radio buttons:
where the default could be overridden by the administrator by content type.
It's a whole 'nother issue for #1 and #2 remembering to go back and put in an end date if and when it finally happens. While that's outside the scope of this discussion, use of a most-future end date would allow such cases to be easily reported to whoever is responsible for checking for the up-to-date-ness of the website.
Comment #35
Charles BelovComment #36
Charles BelovComment #37
bc CreditAttribution: bc commentedTo solve the problem of filtering on start date == end date, I'm using the new views_handler_filter_fields_compare, but with the attached patch.
I added two additional fields to my view: one is the start date only and another is the end date only. These two fields can be compared using the above-mentioned filter.
The trick is that filter_fields_compare only pays attention to one SQL column per field. Start-end dates have two columns in each field, of course. So, I added a test to the filter to check if the views field option for end date was set. This is hacky. I think the views field handler in the date module is weird.
Comment #38
bc CreditAttribution: bc commentedComment #39
Shyghar CreditAttribution: Shyghar commentedHi,
I tryed the #3 patch but it do not work for me.
When the end date is not inserted it will be set to start date value so I solved this with this code:
but you have to be sure that the 'field_data_field_xxxxx' key is present in
$query->tables
and in
$query->table_queue
arrays.
I hope this will help someone.
Comment #40
B-Prod CreditAttribution: B-Prod commentedWhy not add an extra column in the date field tables, that stores the state of the "display end date" checkbox?
This would not cause trouble with the current behavior, but would allow to check against this column within a boolean view handler.
Note: this field should only be added when the end date field if optional.
Comment #41
B-Prod CreditAttribution: B-Prod commentedHere is a patch that matches the proposal exposed in comment 41.
There is an update hook for the existing fields.
The "has_todate" column is an integer, and I didn't modify the views handler to specify a boolean handler, but it can be easily improved, if necessary.
Comment #43
B-Prod CreditAttribution: B-Prod commentedSeems like the tests related to the migrate module are outdated...
Comment #44
thinkyhead CreditAttribution: thinkyhead commentedI'm going to suggest that if we need the end date to be "never" instead of being populated with the start date, there are a couple of potential solutions already existing. One option is to provide some value that stands in for "never" in the end date (such as 9/9/9999) and then do special display handling for that date. (Users can't be expected to enter 9/9/9999 in exposed forms, but we can instead show a "never" checkbox that hides the end date field.)
Another option is to add a boolean "No End Date" checkbox field to your content type (and your view exposed form) and do some extra filtering (with Views-Or module if needed) based on that.
I happen to think, however, that equating No End Date with Start Date was a bad early decision. Date module should be able to distinguish between a single date field and a date range field, and to filter date ranges more smartly.
If Date itself cannot now distinguish between a range with no end date and a range with a single date, clearly it needs fixing. These are not the same thing.
Comment #45
doitDave CreditAttribution: doitDave commentedWhat #44 says. The behaviour is unexpected to everyone in this thread, so it is probably to many more, and so it should be remedied.
Suggestion (rough, and without digging into code so far):
Turn "End date" from a bool field into an option field (0, 1, 2) where 0 and 1 stay unchanged but 2 means "never ending".
Depending on how it is saved internally, probably add a bool column to the field data table, saying "field never ends".
While this would not break any existing use, with some simple changes (views handler, display handler) date field would work as expected for both people who wouldn't consider the status quo an issue and those who do.
I desperately lack time, however, if there were a serious signal to have this in a next release, I would invest some hours for this.
Also sorry in case I should have overlooked an existing similar suggestion in the thread. :)
Comment #46
johnvITMT, #38 is working for me:
- Apply the patch to the 'Views' module (!)
- Add your date field as a FIELD (you might exclude it from the display)
- Add the "Global comparison", and add the two fields.
Comment #47
smithmilner CreditAttribution: smithmilner commented#41 provides a solution nicely.
The patch however has an issue during the update of old field values. It does the reverse of what you expect.
This should fix the update issue.
Thanks B-Prod!
Comment #48
smithmilner CreditAttribution: smithmilner commentedComment #52
jmuzz CreditAttribution: jmuzz commentedWonder why this test didn't get run. All the results are gone too.
Comment #53
jmuzz CreditAttribution: jmuzz commentedWill this make a test happen?
Comment #54
jmuzz CreditAttribution: jmuzz commentedGuess not.
The patch prevents migrations to effected fields as the new column is not covered for them and it can not be null.
Comment #55
Shiraz DindarHere is the same patch from #47 with an updated hook number so that it runs on the current stable date module.
Comment #56
artur.poninski CreditAttribution: artur.poninski commentedHow about approaching this by modifying the op_empty operator in date_views_filter_handler_simple ?
Comment #57
artur.poninski CreditAttribution: artur.poninski commentedSorry, an error got into the patch. This one is better
Comment #58
lazzyvn CreditAttribution: lazzyvn as a volunteer commentedThanks so much #57 It works fine
Comment #59
SocialNicheGuru CreditAttribution: SocialNicheGuru commenteddoesn't apply to date 2.10.