I am having this issue too, where when two events share the same start time, they overlap on the view, and only the topmost event can be be clicked on. The HTML output shows that both events do have a valid HREF, so my guess is that it's somehwere within the CSS/JS.

I am also experiencing this. The issue does lie within the CSS for the Calendar module. If you analyze the HTML output (I'm using Chrome) for the calendar day view it looks something like this (this is for a day with two items scheduled for the same time):

This looks like it should work fine at a glance but if you inspect the parent div for each of these cases (the divs with the classes "view-item" and "view-item-events_calendar" - lines 4 and 11) You can see that each of these divs is spanning the full width of their parent container. This is why ONLY the last item added to this container is clickable. As far as the browser is concerned all previous items are underneath the last item div and thus unable to be clicked.

I haven't figured out a reliable way to fix it yet. I'll check back soon if I come up with a CSS or jQuery solution.

I hate fixing things with jQuery unless I know of no other way. Due to the complexity of the Calendar module and my relatively limited module development experience I did not feel comfortable jumping into the code to craft a more elegant solution. I'm using the following jQuery solution for the time being:

This code captures the width and margins for each .dayview item, applies those styles to the parent element (to fix the overlapping issue) and then zeroes out the margins for each .dayview item before setting the width to 100% of the container we just updated.

The YOUR_OWN_CALENDAR is the part of the class name generated by drupal calendar. It's your calendar content type. You can find out the exact value using firebug. It's the parent of dayview or weekview class div.

However, nothing has been done with it in over a year and while I am not dealing with other bugs this one seems to be major. The fact that events just disappear on the Weekly and Daily view seems like someone of the 57,000+ users of the module would have come up with a patch.

If I had the skill I would do it but I have to depend on someone who does.

I can fiddle with code to get this working but in this case I would appreciate someone explaining #8 a little more or perhaps provide a patch or even better an upgraded version.

Sorry for the lapse in communication nfriend. I've been away from drupal.org for a bit. The code I posted in #8 above goes in a javascript file. I simply put the code in my main.js file for the entire site - although it would probably be better to put the fix in its own custom javascript file (maybe call it calendarfix.js) and then programatically add the javascript file only where it is needed using drupal_add_js: https://api.drupal.org/api/drupal/includes%21common.inc/function/drupal_...

I haven't done this yet for lack of time but this would be the ideal setup until the module is patched to fix the issue.

Thanks CopperBot for responding - I tried adding the code to a few different JS areas and had no luck (like drupal.js too). So I tried to implement what calebtr offered in #9 and still no luck. I am able to get a JS Alert to work using the drupal_add_js just before this code but the code doesn't appear to do anything. I have multiple events at same time showing on Month view but not on day or week.

I placed this code in the calendar-day-overlap.tpl.php file located in the \calendar\theme folder. You can see I also changed the view class reference (.view-item-registration_events).

That's what I can see (I ran a diff of your code against mine), but if there is more, Chrome offers a good javascript troubleshooting tool - when you right click and inspect element, there is a tab for 'console' and errors will show up there.

The above contains no view-specific view names so should be reusable as-is. I added in some jQuery handling of item widths, so if you have one item in a time slot it shows full-width, but with two they're each at 50%, with three they're at 33%, etc. I cut it off after 6 items (16%) because that would be ridiculously narrow. Adjust as needed.

humansky, a temporary fix might be to not use the overlapping display. In the view there's an option for this; then the events will show one after another, each on a row, and there won't be overlaps or missing events. This is also handy for when you want to print the calendar. This is what I ended up doing in my case because printability was important to my project.

I found that removing the last ".calendar" selectors from the css in the calendar-overlap.css line 687 through 813 does the trick everywhere I've tested it. Is there some situation that this wouldn't work?

I would think the ideal "right way" to fix this would be at the template layer, doing about what #8 does but with PHP. Like others, I didn't want to dig in that far; but hopefully this simple CSS fix is useful to someone else.

This allows horizontal scrolling of all events in a given hour, without needing to know how many are present (tested to work in IE7+, FF, and webkit):

@ryandekker, this does not fix the issue really. It just adds a horiz. scrollbar to each time slot (even if there is no event there), and does not prevent my calender to make ONLY the latest event a link (means clickable) all others are not accessible. See screenshot.

In the day display, if there 2 events with the same start time, regardless of end times being set or the value of end times, they overlap, but the second has a higher z value than the first (source order?) and the first is not clickable. This may be a side effect of the css applied to both events, as this screenshot highlights.

@ArVar, I'm not seeing that issue. If you could, take some time to look more closely at the CSS in that area.

I'm wondering if you're facing the issue I've seen on numerous occasions with rows that have the .half-hour class.

I forget the actual fix, but somewhere in there it's necessary to add a position:relative otherwise it's impossible to hover over the link and make it clickable. This is something that can just be added to your site CSS.

ArVarCreditAttribution: ArVar as a volunteer commented June 25, 2015 at 4:32pm

Hi ron_s,
I dived into the css and there is some strange behavior in the "inner" wrapper where the item class is generated, e.g. div class="item d_4 o_0 i_0 md_1". I'm not sure what the class flags (d_4 o_0 etc.) in detail mean, but when I delete the end-date of an event, the same event is rendered with div class="item d_0 o_0 i_0 md_0", whereas the md flag is significant in this case.

This changes the applied css definition.
I think somehow the items array in the calendar-week-overlap.tpl.php should be different then. So the effect seen in #26 possibly has a completely different origin, than discussed here before.

@ArVar, I don't think the items array needs to be different. The css classes you are referencing are related to the the duration ("d") of the event in segments (there are 96 15-minute segments in one day), the position of the event within an hour ("o"), the position of the item horizontally ("i"), and the number of events happening concurrently ("md").

I highly recommend testing your events in Firebug so you can see how these work. Select a particular event, and change "d_4" to "d_5", and you'll see the box grow taller. The positions of "o_0" (:00), "o_1" (:15), "o_2" (:30), and "o_3" (:45) are particularly helpful related to the issue I'm describing.

If you can change the class from "o_0" to "o_2" (or vice versa) and the link is clickable, then it's a problem with the half-hour class as I mentioned.

ArVarCreditAttribution: ArVar as a volunteer commented June 25, 2015 at 6:56pm

Okay, let me explain it more detailed.
By changing these mentioned flags, I can get any position (horizontal and vertical) and height of each item. When I have two or more items which have identical start- and end-dates everything works as desired: The concurrency is well detected, md is set to 1 (or more respectively). Then i and o are set adequately. which means o is the same and i is different, such that I'm able to see (and click) each event.
Now I take two (ore more events) with an identical start-date, but without an end-date. Then I understand that each d is 0 because there is no duration effectively. o is the same. But now no concurrency is detected, thus md is 0 and each i is 0, too.
Only the upmost event is shown and I can only access its content.