Introducing RockCalendar: A Powerful and Flexible Calendar Module for ProcessWire

[FireWire]

  On 3/7/2025 at 1:17 PM, bernhard said:

All you have to do is to add the field you your event's template and then tell RockCalendar to "keep" it:

Expand  

Perfect!!! This will make everyone's dreams come true 🙌

I have been looking forward to spending more time with RockCalendar. I've just had to prioritize things according to client needs so I've had to put that feature on the back burner but can't wait to work with it. It's such a relief to know that there's a quality modern module to handle this feature. Well done and many thanks!

Note: It double posted for some reason, but this is the better comment 😆

[FireWire]

  On 3/4/2025 at 12:57 PM, noodles said:

I was able to temporarily fix the problem by moving $this->addSseEndpoints(); from init() to ready(). After that, everything worked immediately. It now looks like this:

Expand  

@bernhard I ran into the broken recurring event that noodles was having. After performing this fix in RockCalendar.module.php everything works as expected. I'm on 1.6.1. Not sure if there's something "special" about my PW setup that is causing the issue but it works for me now.

[FireWire]

@bernhard I'm having trouble with selecting the "All events of this recurring series" option when deleting an event.

When I choose that option the event is deleted, then it shows a "This page has no process assigned" message. When I close the window, only that one event has been deleted and all the other recurrences are still present.

 

If I open the next occurrence it shows "This event is part of a recurring series. Click here to edit the main event", but clicking on that opens the page that is in the trash.

 

When I click on the next event and attempt to delete it with the option "This and all following events", it still only deletes that one event and shows the "This page has no process assigned" message.

 

 

 

[FireWire]

@bernhard One of the other things that may be difficult for the end user is after creating a recurring event, there's no reference to the recurrence afterwards. So creating a recurrence with advanced options like this:

Opening that event again only shows "Every day for 100 times" and the "Simple" view rather than "Advanced". It's not really possible to tell what the schedule is for a recurring event after creating it.

 

It seems like the date/occurrence field is only a generator and can't be used to re-schedule, change, or manage the recurrences. Opening the original event should show how the events are scheduled, and then let you update it. It would be good to be able to delete existing recurrences by clicking the trashcan icon next to each.

When changing or deleting recurrences the "Create Events" button could change to "Update Events" which re-run modifications/deletions to recurrence pages on the server.

The client that will be using the calendar is coming from their site that was built using Recurme which isn't as powerful as RC but lets you view and edit the schedule.

Without being able to manage events from one location I'm not sure how they will respond to losing the ability to do that.

 

[bernhard]

Hey @FireWire thx for testing RockCalendar and thx for your feedback and questions!

  On 3/24/2025 at 7:26 PM, FireWire said:

@bernhard I ran into the broken recurring event that noodles was having. After performing this fix in RockCalendar.module.php everything works as expected. I'm on 1.6.1. Not sure if there's something "special" about my PW setup that is causing the issue but it works for me now.

Expand  

Thx! I'll have to test and then push it to the repo. Just have two launches this week 😅🤞

  On 3/24/2025 at 9:35 PM, FireWire said:

@bernhard I'm having trouble with selecting the "All events of this recurring series" option when deleting an event.

Expand  

Looks like a bug! I'll have to investigate next week!

  On 3/24/2025 at 10:02 PM, FireWire said:

It seems like the date/occurrence field is only a generator and can't be used to re-schedule, change, or manage the recurrences.

Expand  

Correct.

  On 3/24/2025 at 10:02 PM, FireWire said:

Opening the original event should show how the events are scheduled, and then let you update it. It would be good to be able to delete existing recurrences by clicking the trashcan icon next to each.

Expand  

I disagree on this one. I don't think it's possible to get what you are describing without losing many of the features/flexibility that RockCalendar offers (like moving a single event out of the row, having custom fields for each recurring event, etc).

BUT: I understand that this is an important need. My solution/idea was to just delete all recurring instances and then recreate them. That was before we had support for custom fields on events, though. So this might be a culprit. I also thought about maybe supporting a "move all", so when one recurring instance was moved it would ask "also move all following instances?" and then it would get the time difference of the move and apply that to all following instances.

But when I did tests in that direction I even found bugs in google calendar, which tells a lot...

  On 3/24/2025 at 10:02 PM, FireWire said:

Without being able to manage events from one location I'm not sure how they will respond to losing the ability to do that.

Expand  

Well... They could always pay someone (you/me) to get it done. But even then this might mean that this might have a side effect somewhere else, for example what about an event that has been pulled out of the series? Would that have to be modified or not? Maybe there would need to be a GUI for that, which asks the user what to do in such a case. But, well, that would be a lot of work, which means a lot of Dollars/Euros.

So don't get me wrong. I'm not against it, I just don't have a good solution for it so far and I can't think of one. If you can please let me know and we'll see how we can make it possible! But at the same time I want to mention that Recurme had huge issues with how it stored it's data (as far as I can remember from what I read in the thread). I really don't want to make that module bad - just want to say that it might be a good idea that my module works differently and I'll be very careful about changing that 🙂 

[FireWire]

@bernhard That was very helpful, thank you for taking the time to explain more. I definitely don't want to replicate past ideas or force RC into trying to be something it isn't!

  On 3/24/2025 at 10:39 PM, bernhard said:

BUT: I understand that this is an important need. My solution/idea was to just delete all recurring instances and then recreate them. That was before we had support for custom fields on events, though. So this might be a culprit. I also thought about maybe supporting a "move all", so when one recurring instance was moved it would ask "also move all following instances?" and then it would get the time difference of the move and apply that to all following instances.

Expand  

This is an interesting idea. I'm understanding your approach better now and I think that my concept was too focused on having the RockDateRangePicker field do "too much".

I'll share a little more about what I got wrong when using RC. When I opened the original event and saw the RDRP field it was confusing since it automatically shows the date and "Recurring" is checked, to indicate that this is a recurring event, but the contents of the RDRP field do not match the schedule/recurrence that the event was created with. If I uncheck "Recurring" and save the event page, nothing is changed with the other events, so I was confused on what the purpose of the Recurring button, schedule, list of dates, etc. was for. Even though you labeled it "Create Additional Events", I was focused on the UI since it presents things to interact with.

The other part where I stumbled was the "This event is part of a recurring series" message. It made me think that clicking on "Click here to edit the main event" had something to do with the recurrences since it showed the other buttons below the date field. Since this occurrence isn't the "main" event, would it be a good idea to remove the "Recurring" and "Range" buttons and only allow for setting/editing the time?

 

I used Thunderbird for my email/calendar client and took a look at how the UI works. I had never thought about it before and it's also more simple than the suggestion I was making, and might be more inline with RC's approach.

I made a quick video and if managing recurrences could be something like this it would work really well. The Thunderbird UI, date selection, calendar style, etc. can all be ignored of course. Here are the steps I took:

• Create an event that occurs every Tuesday
• Edit the event and change it so that it occurs every Wednesday
• Move one of the occurrences in the series to Thursday
• Edit the event to change it back so it occurs every Monday

 

What is interesting is that moving the one occurrence to Thursday "detached" it from the schedule. It is still a part of the main event, but the date is no longer managed by the recurrence rule. So I was able to change back from every Wednesday to every Monday and that individual occurrence was not changed. Any further edits to the schedule, like changing it to Monday of every other week, would also not affect the occurrence I moved to Thursday.

Maybe the "generator" UI only appears when you create the event and then afterwards it only lets you edit the recurrence rule without displaying or managing any of the individual pages. Thunderbird does not have any "central" manager for all events the way that Recurme did or in the way that I was suggesting. It only allows you to adjust the schedule and doesn't let the user get involved any deeper than that when dealing with the schedule. Like RC, the calendar UI is used to manage individual occurrences.

Interested in your thoughts. This is different than what I was originally thinking and perhaps this style is more compatible with RC's approach.

  On 3/24/2025 at 10:39 PM, bernhard said:

But at the same time I want to mention that Recurme had huge issues with how it stored it's data (as far as I can remember from what I read in the thread).

Expand  

RC has the great approach by using pages as the way to store and retrieve data since it doesn't "fight" the ProcessWire style. I definitely don't want to stray from the formula 😎