Event rendering broken as of Obsidian 1.0

[m-paul]

The time grid view is no longer showing events in it as of Obsidian 1.0 in live preview mode or reading mode

Steps to Reproduce

Create a page named 2022-10-20 with the following content:

```itinerary
initialDate: 2022-10-20
initialView: timeGrid
minTime: 05:00
slotEventOverlap: false
nowIndicator: true
dayHeaderFormat:
weekday: long
headerToolbar: 
```

```itinerary-event
title: My Event
start: 2022-10-20T10:00
end: 2022-10-20T11:00
tag:
```

Screenshot

[yalikebaz]

Very little development activity on this repo recently... I'm scared this might not ever get fixed :(

[coddingtonbear]

It's true! It will almost certainly be many months before this is able to make it to the top of my priority list. I'm sure you can appreciate that, just like you, I have lots of other priorities to juggle this project among. There's good news, though -- this is an open-source project and you, if you find value in this project or require it for some part of your workflow, are able to investigate the problem yourself and arrive at a solution that you can share with everyone else via a Pull Request. I hope you do!

Cheers & good luck!

[yalikebaz]

Thanks for responding :) I totally understand! This plugin is spectacular and your work is really appreciated. I can try to take a look at the bug in my spare time as well, to try and help out!

[yalikebaz]

So I haven't developed Obsidian plugins but I do work as a software engineer. I found the issue in my local obsidian plugins folder in the file styles.css. There is a css class .fc .fc-scrollgrid-section table that is overriding the height property from the .fc-media-screen .fc-timegrid-cols > table class.

I fixed it for myself internally by adjusting the .fc .fc-scrollgrid-section table height property to a min-height instead. I wanted to make a PR but couldn't figure out how that fix translates to your repo (I couldn't find those class names).

P.S. I don't think event rendering in general is broken, its specifically the timeGrid view. My fix above fixes it locally (for both timeGridDay and timeGridWeek).

[smiller171]

It's true! It will almost certainly be many months before this is able to make it to the top of my priority list. I'm sure you can appreciate that, just like you, I have lots of other priorities to juggle this project among. There's good news, though -- this is an open-source project and you, if you find value in this project or require it for some part of your workflow, are able to investigate the problem yourself and arrive at a solution that you can share with everyone else via a Pull Request. I hope you do!

Cheers & good luck!

Totally get it. I do notice though that you have a PR that's been open since July. Seeing that can really discourage people from opening their own PRs because it seems like a waste of time if they aren't getting merged or otherwise responded to. Is it possible for you to find enough time to deal with PRs?

[coddingtonbear]

Re: #20, @smiller171, that particular PR adds a new feature that I'm not 100% sure I'm up for maintaining -- at least, maybe not in its current implementation. As is probably clear, it's already difficult to find time to maintain this library, and adding additional features can only increase that maintenance burden. If any folks (maybe you?) were up for helping to maintain the library, though, that could change that calculation. That being said: in general, feature requests should start as a discussion so as to prevent folks from wasting time on a PR that may not end up being merged, and that one unfortunately didn't.

Regarding bugfixes: I really can't make any guarantees whatsoever about finding time in the near term to review PRs or merge them, but members of the community can help do that themselves, too. All I'd expect is that at least one other person than the person posting the PR have tested the changes locally and to indicate that in a PR review.

[smiller171]

I can appreciate that. I think a comment on #20 explaining this would help ppl understand that the situation there.

Would you welcome a PR adding a CONTRIBUTING.md that explains the need for a code review (from the communtity) and advises opening a discussion thread for new features? I think a needs review label to go with that could potentially be helpful as well. I could probably write up a GH actions PR that automatically applies the label to new PRs

[baslat]

Thanks @yalikebaz . Do you have a similar fix for multiday events not rendering #22?

[yalikebaz]

No worries, I'm actually no longer using this plugin. Just my suggestion but if you'd like calendar functionality I have found the Full Calendar plugin to be quite a good substitute. You can connect it to your google cal and apple cal, so that works pretty well for me.