Support for multiple standard (non smartdate) date fields

Have you tried not selecting any fields in the "Customize Fields" option?

I did, it still did the infinitely long events ending at today.

I can go back and try again in a few days, but with either one or two standard drupal date fields added to the view it wasn't creating reasonable events.

Using a standard date field on that entity as start, then referencing a standard date field in a related (storage) entity leads to a blank calendar. I've tried selecting no date fields, one date field, and both. There are no other date fields in the view.

If I switch to unformatted list all the fields show up, so I'm not just messing up the relation.

If I have two dates on the same entity it's the same infinite past to present day list of entries. Again I've tried selecting no date fields, one date field, and both.

Could you post a screen grab that shows the fields you're trying to use? Also, you mentioned that you have this working with Fullcalendar View. Would you be willing to post a screen grab of that config?

Upgraded, testing against rc1 entries start and stop when they should! Selecting fields or not selecting fields doesn't seem to make any difference.

There are two issues:

1) Each entry shows up twice. I assume that this is because it loads a date field for the start, and then another one for the end.

2) Each entry has a 5p or 12a even though the fields are "date only" and don't have any time associated with them. I don't see an option for "all day events only" etc in the config settings, but regardless it probably shouldn't make up a fake time if none is present.

As per https://www.drupal.org/project/fullcalendar/issues/3475373#comment-15860986 ✨ Time format options Active times should now be able to be hidden, so it's really just the duplicate entries showing up. Anyone able to replicate this?

Here is the patch if you want to test and check the unique events for the same.

Sorry for the comment #14 please look into this patch.

Please use this patch DuplicateAllDayEvents-3480947-15.patch for the Duplicate entries for all day events with multiple standard (non smartdate) date fields issue.

Duplicate entries for all day events with multiple standard (non smartdate) date fields

Thanks for the patch, I'll try and get this tested in a few days - things are hectic now.

This works great, thanks!

I can confirm the duplicate entries on the frontend when assigning start and end dates to an event. Following the comment #7 by @erutan, I removed the end date and the duplicates don't show up on the front end. I've attached screenshots that demonstrate this behavior. Please merge the fix and issue a new release.

Dear all,

I can also confirm that this patch works. I've added my comments and screenshots to the other related issue I posted here 🐛 Major bug: Duplicate entries or incorrect duration on calendar Active . The patch seems to fix the issues I was facing. Shout out to @vinayakmk47 → for the patch and all the contributions from this community.

Thanks a ton!

Mithun A. Sridharan

I appreciate the work done to date here, but unfortunately there are a few things needed before this will be ready to merge. First, there are a variety of code standards issues, in fact the changes in the MR that actually introduce code standards failures outnumber the lines required for the actual solution. If it were as simple as that, I would have made a new MR with only the actual proposed solution.

My bigger concern is that the proposed solution does a pass for deduplication at the very end, after all the processing has been done for all the rows in the view. That means that the back end is still doing all its work on duplicate rows, we're just stopping them from all being passed to the front end. I would suggest that there's a much more sufficient way to address the cited problem.

Consider this code towards the end of the unmodified prepareEvent() method:

          $event = $this->prepareEvent($entity, $title, $date_fields, (int) $index);
          if (!empty($event)) {
            // @todo more sophisticated key assignment needed?
            $events[] = $event;
          }

The proposed changes include this line:
$uniqueKey = $event['id'] ?? $event['start'] . '_' . $event['end'];

We could generate the $uniqueKey value and check for an existing value in the $events array BEFORE calling the prepareEvent method.

I would be happy to help this along more directly myself but since neither this issue nor the one closed as a duplicate include detailed steps to reproduce the problem on a clean install, I don't want to guess how to replicate an issue I haven't yet come across myself.

It's been a while since I looked at this, but to reproduce this simply use non smartdate (core) date fields for the beginning and end dates for a multiday event. The ones I were using were date only, not date+time. I can spin up a new install and document it better if you'd have time to dig into this soon.

Step to reproduce:

1) Choose an entity/bundle with two or more core date fields.
2) Create a view with fullcalendar as a view display
3) Add date fields to the view

All entries are duplicated.

4) Optionally select two date fields for the view to use.

All entries are duplicated.

I'm not sure how long this will be up, but admin:admin on https://master-tb3wj0kram2h8gdhhswittxkcve9fq07.tugboatqa.com/admin/stru...

Thanks for the additional work here. I see now (having done a little testing) that my earlier optimism that we could skip processing by generating the $uniqueKey before calling the prepareEvent method was unfounded, since the logic for generating it depends on start and end keys that will not be available until after the method has been called.

@erutan thanks to your steps to reproduce, I was able to see the problem, and validate that the proposed code resolves it.

I do see a bigger problem, however. The patch also prevents multivalue date range fields from displaying as expected. That also means that recurring Smart Date fields only display the first value.

I suspect we need a deeper refactoring, to use different logic for date fields that are ranges (where it's reasonable to expect multiple events per entity) from entities that need multiple fields for a single value (and where multiple events per entity are less likely). We currently have some of this logic within the getEventStartEndDates() method, but some different logic might be needed at a different level.

Here's a new MR with a tweaked approach. In my testing it eliminates the duplicate display for datetime fields, but preserves the multivalue display for ranges.

Thanks for coming back to module mandclu, and taking a deeper look into this issue!

#70 works on my end, though I did not test multi-value ranges.