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.
When I create a node with multiple dates (like 08/04/2016, 08/05/2016 and 08/06/2015) the all show up on the 4th.
Comment | File | Size | Author |
---|---|---|---|
#9 | interdiff-5-9.txt | 3 KB | Anonymous (not verified) |
#9 | nodes_with_multiple-2639794-9.patch | 6.67 KB | Anonymous (not verified) |
#5 | Screenshot from 2015-12-29 18-44-11.png | 11.88 KB | parijke |
#4 | nodes_with_multiple-2639794-4.patch | 4.61 KB | Anonymous (not verified) |
Screenshot from 2015-12-23 13-42-23.png | 11.64 KB | parijke |
Comments
Comment #2
Anonymous (not verified) CreditAttribution: Anonymous at XIO commentedI verified that this is a regression and it looks very much like something we introduced while porting. I'll look into it more thoroughly when I have a bit more time.
Thanks for reporting!
Comment #3
parijke CreditAttribution: parijke commentedVery welcome. I wish I could help to solve it.
Comment #4
Anonymous (not verified) CreditAttribution: Anonymous at XIO commentedActually we didn't introduce it. We simply didn't port it yet. This patch should fix your issue and does some additional clean-up and documenting around the edges.
This definitely needs some more testing though.
Comment #5
parijke CreditAttribution: parijke commentedA quick glance and it looks like it is working now!
Comment #6
Anonymous (not verified) CreditAttribution: Anonymous at XIO commentedApparently this breaks adding the links on the year view and at one point I had php exception. This will need further investigation.
Comment #7
Anonymous (not verified) CreditAttribution: Anonymous at XIO commentedActually, using the row index here is just wrong. We'll need something to track the field delta's similar to what the D7 version did, but without the magical setting of properties. I'm thinking we might be able to store the info in de date info object if we document it properly. I'll have to think about that.
Also this issue clearly demonstrates the need for automatic testing.
Comment #8
parijke CreditAttribution: parijke commentedCan I help in any way?
Comment #9
Anonymous (not verified) CreditAttribution: Anonymous at XIO commentedHere is the approach I was thinking about. This again will need extensive testing.
Comment #10
parijke CreditAttribution: parijke commentedIf I try to apply this patch I get:
Reversed (or previously applied) patch detected!
How do I (re)apply this later patch? Sorry for my ignorence and a happy NY to you all.
Comment #11
parijke CreditAttribution: parijke commentedOk I managed to add the patch. When testing it I saw the following behaviour.
When I add an event with a date and a time as 12:00:00 AM it doesn't show in the calendar. I Think it is unrelated to this situation. If so, I am happy to file another bug.
Comment #12
Anonymous (not verified) CreditAttribution: Anonymous at XIO commentedRe #10: I'm not sure how you are applying the patch, but we use git for code management, see https://www.drupal.org/project/drupal/git-instructions
Re #11: I tested this using fields with 24h and I see the same issue. I also tried this against the 8.x-1.x branch without this patch and it gave the same result, so this patch does not introduce this bug. A new bug report would be good to track that.
Did the patch in #9 work for you?
Comment #14
Anonymous (not verified) CreditAttribution: Anonymous at XIO commentedI did some further manual testing and it seems ok to me, so I went ahead and pushed it to 8.x-1.x.