Hiding Past Dates

Thank you for the quick response.

It is a tough one, as there is likely going to be a scenario where a date field is set to have the option for multiple/unlimited rows, so could contain once off dates, as well as recurring dates, maybe not on the same node, but in my case, definitely on the same content type / field.

We are using it on a basic events calendar, so some are recurring, some are single, some are multiple single dates.

I see your thought about having a different formatter, but in my case, I would still be needing to use the Recurring formatter. I wonder if there is a way in the logic of this formatter to only show upcoming dates outside of recurs, or an option to hide all past dates, regardless if they are recurring or not. But I get this may not be possible, as you said, the logic is set within the recur rule. So not sure what option there is on the base date.

Here is an example of my scenario just to make sure Im clear
Event with recurring date (hides all past occurances)
https://redjacketresorts.com/events/finger-painting

Event with multiple single dates (shows past date rows)
https://redjacketresorts.com/events/campfire-0
(I get that this specific one could be set using recurs and overrides, but it illustrates the issue)

Thank you for your time.

Yes that does sound like it would be a good solution, as long as we would still get the recurring display, but with the ability to hide past single dates, or recur occurrences.

Basically the overall goal would be a setting to never show past dates, regardless of recurring or not.

Thank you for taking the time to discuss.

Thank you so much for your work here and responding so timely. This is actually perfect! And working better than I had even expected.

Maybe it was my lack of understanding on the available formatters, but this is working great, what I am getting is the next date separated out and then all future dates, whether they are from a repeat rule, or from singularly entered dates, all grouped together withing the 'Upcoming' block. This is the exact scenario I was hoping for, and will work perfectly for my client, who has events that are all over the place and not always following a specific recurring format.

Currently, if they enter separate date rows, each with their own recur, plus single date rows, we get a messy output of all individual rows, this fully solves that issue.

Thank you so much!

One issue Ive just found, is that if the node display for the field has a label set to be shown, it isnt actually showing. Oddly, any preprocess function i try to run on the field within hook_preprocess_field seems to not being run.

Not sure if this is something you were aware of as it was just a proof of concept. I tried to look into the formatter plugin, but Ill be honest, I havent worked with these before, so might be a quick and obvious thing for you.

Thank you again.

Thank you, glad it was an easy fix, I'll check it out hopefully later on today.

I'm all for having it in the existing Recurring formatter, but not entirely sure about how to name this option. "Force chronological" isnt exactly obvious for the functionality, so maybe would require a description under the checkbox. You mentioned this setting is currently not doing anything within this formatter, so maybe renaming to something along the lines of 'Group multiple rows', or 'Group all dates instances'. or something like that.

Just had a play with this, and the previous issue mentioned with the labels is resolved and preprocess functions are working as expected, thank you.

I did come across another potential issue, which is a bit of an outlier. When a single non-recurring date is set as an all day date and spans multiple days, ie start date 1 Dec - end date 24 Dec, on the full display mode, the date is hidden completely. Im assuming as this is seeing the start date as in the past, so it is being removed by the formatter.

Sounds like potentially a difficult one to allow for.

Perfect, thank you for that, I had previously seen that setting before, but hadn't used it and forgot about it, that worked! Thanks again.

Thanks for this. I just tried applying the patch using Composer and it failed, not entirely sure why, as it doesnt give any useful error. I tried (with my limited knowledge) trying to apply it manually and it also didnt work, asking me to manually merge chunks of code.

Sorry, this doesn't give you much to go on.

Sorry, I was using 3.4.3, patch applies fine on 3.5.0-beta4.

Couple things.

- The field description has a grammar error, 'as s single group' instead of 'as a single group'

- Im getting a php warning message

Notice: Undefined index: instances in Drupal\smart_date_recur\Plugin\Field\FieldFormatter\SmartDateRecurrenceFormatter->buildOutput() (line 349 of modules/contrib/smart_date/modules/smart_date_recur/src/Plugin/Field/FieldFormatter/SmartDateRecurrenceFormatter.php).

This seems to be with any date set, regardless of having recurring rule or not.

Thanks again.

Thank you.

Unfortunately getting a different error now after running on 3.5.0-beta4

Error: Class 'Drupal\smart_date\Plugin\Field\FieldType\SmartDateItem' not found in Drupal\field\FieldStorageConfigStorage->mapFromStorageRecords() (line 169 of core/modules/field/src/FieldStorageConfigStorage.php).

Odd, I went back and applied what I thought to be the same steps to apply the patch, and this time no issue, so clearly did something wrong.

This looks to be working great with multiple single dates and recurs, but when just 1 single date is set, I am getting a warning

Warning: array_shift() expects parameter 1 to be array, null given in Drupal\smart_date_recur\Plugin\Field\FieldFormatter\SmartDateRecurrenceFormatter->subsetInstances() (line 321 of modules/contrib/smart_date/modules/smart_date_recur/src/Plugin/Field/FieldFormatter/SmartDateRecurrenceFormatter.php).

Not a problem at all, thanks for your continued work on the updates!

Latest warning is gone. Though Im seeing one of the previously reported issues where the field label isn't displaying, likely because the fix wasn't brought over when the update was moved to the Recurring Formatter maybe?

Thanks again

Thank you yet again!

But sorry yet again.. I think I have found another issue. Though this does not seem to be specific to this patch, rather specific to 3.5.0-beta4.

If I set one single, non-recurring date to be occurring later on during the current day, the date does not show. I tried using the setting 'Treat current events as upcoming' and this did not make a difference. I downgraded back to 3.4.3 and the date showed correctly. Are you able to confirm this?

If necessary, I can create a new ticket tagged specifically for this issue?

Thanks again.

To be honest, after more testing, I'm now not entirely sure that it isn't related to this patch.

With a fresh install of 3.5.0-beta4

- Create a node with a single non-recuring date for a time later on the current day
- node display set to Recurring formatter with Force chronological, Show next instance separately, Treat current events as upcoming all checked

I get a bunch of warnings.

Apply the patch from #25, all the warnings are gone, but the date does not display, the field does.

If i set the date to tomorrow, it shows, or if I apply any repeat rule for future dates, they show, it just seems to be when the date is on the same day.

It seems that any date set to the current day looks as though it is seen as in the past, regardless of the time being in the future or not.

I hope that is enough information for you, again, thanks very much for your time here, sorry to be finding issues :)

Thanks for looking further into this. The issue I am seeing seems to be related to what timezone I have the site set in. We generally leave our timezones always set as UTC to have a standard base, then if we have to do anything in our code with timezones, we work from that, so it is the same between projects.

With 3.4.3, I am not seeing issues, nor with 3.5.0-beta4, a date set just an hour in advance on the same day shows correctly, but after applying the patch, then it is seen as it is in the past. Assumption being that the new logic is taking into consideration the timezone of the site to determine what is past and future, so with mine being set is UTC, it sees the date as already being past. I confirmed this by setting the time to just ahead of current UTC time, which then the date showed as expected within the formatter.

Not sure of a solution here, as this is obviously the logic you are using in this patch to determine what is past/future, and this may just be an isolated issue for me for incorrectly using UTC time for the site default. My issue now, if I change my timezone, all existing times set on nodes then get updated to stay in sync with what they would have been, which obviously causes me issues in having to reset all the events times.

Hope this information helps and understand if this is not something you can account for, as it obviously makes sense to be using the sites timezone, but wonder what logic was being used previously to determine past/future?

Thanks

Just tested in a fresh install of Drupal, Bartik theme, and reproduced the same issue. All I can say is, for whatever reason, it seems to be using UTC time to determine if a date is past or future. Which would make sense, as my default site timezone is set to UTC.

If i change the field settings to have Default date set as Current date, then when creating a new node, UTC time is used. If i change my site timezone to Vancouver (PST), then this is used and dates work as expected. I tried changing the display settings to my timezone with 'Time zone override', but this made no difference.

When you say 'I also tried manually setting the event timezone to my actual timezone', how were you doing this? The only place I see a timezone setting is in the display mode, maybe this is what you mean?

Adding a screenshot of my settings. And to be clear, the field settings are set for unlimited values.

Sorry to drag this out, not sure what it is in my settings that is differing, clearly something that I am missing or not understanding.

Thanks again.

Hello, thanks for the futher patches and release.

Im really sorry to be continuing this, but I have followed your steps as exactly outlined, and I am still seeing the same results

1. Fresh install of Drupal, UTC timezone
2. Install 3.5.0-rc1, enable Smart Date Starter Kit and and Smart Date Recurring
3. Update the When field on the Event Content Type to allow recurring values and use the Recurring formatter with "Force chronological" enabled
4. Create an event within the next hour

My event does not show the date as upcoming. If I have 'Recent Instances' set to any number, the date shows as recent, if I set this to 0, the date does not show.

I'm not sure I understand the problem here. It sounds as though if your site is using UTC as its timezone, then when you create an event it assumes the times are for UTC. If you create an event on a site using UTC as its timezone and set the time as something upcoming in Vancouver time, that's actually in the past in UTC.

Yes, that is exactly what I am saying. The sites timezone is set to UTC, the field settings for the When field has the Default date set as 'Next hour'. When creating a new event, the dates default value is set as the next hour of UTC time. Not my current time. If I change the sites timezone to Vancouver, then a new events default date is shown correctly to Vancouver time.

So, when creating a new event in PST time, the site is seeing this as in the past for UTC time, and then not showing the date as upcoming. If I set the time to something that would be upcoming in UTC, then the date shows as upcoming.

I really cannot understand what is different here as to why we are getting completely different results.

Do you get the same results when you create a new content type with a new field, rather than using the starter kit?

Thanks again.

Ive just installed the latest release on the site Ive been working on, and I saw the same results, though Ive changed the Form display for the field to 'Date and time range with timezone' and have forced the timezone to what I want and this looks to have solved all the time display issues. The dates are now specific to my timezone and no confusion with UTC. Seems like this is the fix, which kind of makes sense.

Thanks again for all your work on this, really appreciate it, and sorry for any wasted time I may have caused.