Introducing RockCalendar: A Powerful and Flexible Calendar Module for ProcessWire

[Christophe]

Hello @bernhard, 

Any updates on the date/time picker issue that you could also reproduce?

Thanks in advance!

[bernhard]

@Christophe I don't have any open issues on my list. If you have one, please open a separate thread, so it's easier to keep track. Please describe everything as good as possible and please check if you have the latest versions of all modules.

[Christophe]

@bernhard It's the issue that I had on a website that we had talked about via PM around the 5/6 January where I had explained everything, and with more/complementary details the 9th (PHP 8.2, utfmb4, InnoDB, MariaDB..., the steps I took, etc.)  and for which I had sent you via your cloud a copy of the fresh new installation I had done, as you asked me to, where the issue was reproducible a second time. You told me that you could reproduce my issue and that you were working on it. It was apparently the day the version 1.5 was released, the 11th.
Compared to the installation copy I had sent you (where the modules were all the latest at that moment), I've just upgraded now the modules listed below (all the others were already up to date):

*** By the way, RockCalendar, be it with 1.4.3 or 1.5.0 installed, still shows as 1.0.1 for "Latest"/ 1.0.1 (older than the one you already have installed!), in the Upgrades module page or in
Admin -> Modules -> RockCalendar -> Download and Update ***

RockCalendar     RockCalendar     1.4.3->1.5.0     1.0.1
RockFrontend     4.0.0->4.1.0
RockMigrations     6.5.0->6.7.0
TracyDebugger     4.26.47->4.26.57

The issue is still present. With new events created (past, present and future) and with several times of the day/night.
The time is saved correctly in the calendar as before but the time still goes back to 00:00 in the date/time picker field after saving the page, as before.

Do you want that I summarize/condense/merge/compile everything discussed concerning this specific time issue on a separate thread under Modules/Plugins (or another sub-forum)?

Added: Do you want me to create a thread specific to the date/time picker fieldtype and/or inputfield?
Added 2: if you want me to create a specific thread I'll remove everything in this post and just link to the thread with the details (I'll probably remove all the content of this post anyway as I don't like when my posts are messy).
Added 3: I tested after only upgrading RockCalendar to 1.5.0, and then also after upgrading the other modules, trashing the old events and creating new ones. And even logging out/in of ProcessWire, etc.

Edited January 21 by Christophe

[bernhard]

Hey @Christophe sorry for that. I totally missed that and after your last message talking about RockCommerce and some other projects on your side my brain dumped everything we talked before.

It was quite an easy fix though, so it might have been good to start over with a fresh head, because I can remember I was on another track with solving that issue 2 weeks ago.

Please grab v1.5.1 and let me know if it works now! https://www.baumrock.com/en/releases/rockcalendar/

Also @Stefanowitsch could you also please upgrade and see if it breaks anything on your project?

[Christophe]

Hi @bernhard,
And thank you!

I've just updated the module on the website that I had copied. I've done several tests, also with the date range option on the same day and on several days, from the calendar or creating directly children.
It seems to be working. 
In the calendar (in the admin) I see the starting time but not the ending time (the same day or another day) but I'm sure it's normal by default.
I've not yet installed RockGrid and tested repetitive events like for example on several days (consecutive days or not) starting at the same time.
But I've noticed something: if I have a range like 31/01/2025 12:00 - 04/02/2025 13:05 that is on 2 different weeks on the calendar, the starting hour of the first day is also displayed on the first day of the new week, making it seem as if it only starts at 12 pm on the 3rd February.
Is it the default "behaviour" of FullCalendar?
Is this only happening in the admin or will it also happen on the frontend if someone uses FullCalendar?

I'm thinking/I guess that repetitive events (at the same time range or not the same time range each of these days - I haven't tested yet) (can) resolve this case.
I'll have to test.

Edited January 23 by Christophe

[Stefanowitsch]

  On 1/21/2025 at 11:05 PM, Christophe said:

The issue is still present. With new events created (past, present and future) and with several times of the day/night.
The time is saved correctly in the calendar as before but the time still goes back to 00:00 in the date/time picker field after saving the page, as before.

Expand  

I am using the RockCalendar too and I tried to reproduce this error but everything looks normal to me. Can you explain how to reproduce this step by step?

One thing that I did notice: If you edit an event that has a time assigned to i, then uncheck the "set time" checkbox and then re-check it, the time will default back to "00:00".

I don't know if this is the problem you are experiencing but it seems as the default behaviour for me.

[Christophe]

Hello,

It was an issue where if you put 31/01/2025 18:30 for example and saved the page, the time was displayed in the calendar/parent page, but in the child page the time was back to 00:00.

[bernhard]

  On 1/23/2025 at 6:09 PM, Christophe said:

But I've noticed something: if I have a range like 31/01/2025 12:00 - 04/02/2025 13:05 that is on 2 different weeks on the calendar, the starting hour of the first day is also displayed on the first day of the new week, making it seem as if it only starts at 12 pm on the 3rd February.

Expand  

Sorry, I don't understand your example. Please show screenshots and explain what you'd expect and what you actually see.

[Christophe]

Hi @bernhard,

The screenshot was the one at the end of the post. But I thought I had replaced it with the version where the 04/02 was added to show that only the first day (03/02 ) of the 6th/new week displayed again the start time (12:00/12 h) of the first day of the event.

With "31/01/2025 12:00 - 04/02/2025 13:05" I wouldn't expect to see "12 h Event range on 2 weeks" on the 03/02.
It could be to show some time info if a weekly calendar view is chosen but the (test) event doesn't start at 12pm on the 03/02 (or any other day other than the 31/01).
It is supposed to be a continuous event, so I suppose only "Event range on 2 weeks" would be expected to the displayed on the 03/02.
Edit: or the start date of the event should be displayed too on the first day of the new week (perhaps it would be easier to do, but it would probably also make no sense...)

Edited January 26 by Christophe

[bernhard]

That's how FullCalendar renders Events and shows their info. It should be configurable though: https://fullcalendar.io/docs/displayEventTime which should be easy to hook: https://www.baumrock.com/en/processwire/modules/rockcalendar/docs/hooks/#getitemarray

 

[Christophe]

Ok, thanks. I normally won't have that "problem" appear on the 2 websites where I want to try to implement it but I just wanted to let you know about this specific "behavior" I had encountered.

[noodles]

Hi!

We just purchased this fantastic module. The feature set looks great and almost completely covers our use case. However, I have a problem and a question. 😉

Problem
When I try to create recurring events, I see an issue in the Chrome console related to Page::localPath. Our website runs on ProcessWire 3.0.229 and is multilingual. I can see that the first call to /create-recurring-events/ correctly transmits the information for the events to be created:

{
    "pid": 2049,
    "diff": 0,
    "title": "Test",
    "rows": [
        {
            "id": 1,
            "date": "2025-03-04 12:00:00",
            "done": 1
        },
        {
            "id": 2,
            "date": "2025-03-05 12:00:00",
            "done": 0
        },
        {
            "id": 3,
            "date": "2025-03-06 12:00:00",
            "done": 0
        }
    ]
}

However, all subsequent AJAX calls return this error:

data: {"current":1,"progress":0.33}

Fatal error:  Exception: Method Page::localPath does not exist or is not callable in this context (in /path/to/project/wire/core/Wire.php line 563)

#0 /path/to/project/wire/core/Page.php(1512): ProcessWire\Wire->___callUnknown('localPath', Array)
#1 /path/to/project/wire/core/Wire.php(419): ProcessWire\Page->___callUnknown('localPath', Array)
#2 /path/to/project/wire/core/WireHooks.php(968): ProcessWire\Wire->_callMethod('___callUnknown', Array)
#3 /path/to/project/wire/core/Wire.php(484): ProcessWire\WireHooks->runHooks(Object(ProcessWire\Page), 'callUnknown', Array)
#4 /path/to/project/wire/core/Wire.php(487): ProcessWire\Wire->__call('callUnknown', Array)
#5 /path/to/project/wire/modules/PagePaths.module(451): ProcessWire\Wire->__call('localPath', Array)
#6 /path/to/project/wire/modules/PagePaths.module(82): ProcessWire\PagePaths->updatePagePaths(Object(ProcessWire\Page))
#7 /path/to/project/wire/core/WireHooks.php(1094): ProcessWire\PagePaths->hookPageMoved(Object(ProcessWire\HookEvent))
#8 /path/to/project/wire/core/Wire.php(484): ProcessWire\WireHooks->runHooks(Object(ProcessWire\Pages), 'added', Array)
#9 /path/to/project/wire/core/PagesEditor.php(787): ProcessWire\Wire->__call('added', Array)
#10 /path/to/project/wire/core/PagesEditor.php(478): ProcessWire\PagesEditor->savePageFinish(Object(ProcessWire\Page), true, Array)
#11 /path/to/project/wire/core/Pages.php(840): ProcessWire\PagesEditor->save(Object(ProcessWire\Page), Array)
#12 /path/to/project/wire/core/Wire.php(416): ProcessWire\Pages->___save(Object(ProcessWire\Page))
#13 /path/to/project/wire/core/WireHooks.php(968): ProcessWire\Wire->_callMethod('___save', Array)
#14 /path/to/project/wire/core/Wire.php(484): ProcessWire\WireHooks->runHooks(Object(ProcessWire\Pages), 'save', Array)
#15 /path/to/project/wire/core/PagesEditor.php(117): ProcessWire\Wire->__call('save', Array)
#16 /path/to/project/wire/core/Pages.php(975): ProcessWire\PagesEditor->add(Object(ProcessWire\Template), Object(ProcessWire\Page), '67c6c56091a46', Array)
#17 /path/to/project/wire/core/Wire.php(416): ProcessWire\Pages->___new(Array)
#18 /path/to/project/wire/core/WireHooks.php(968): ProcessWire\Wire->_callMethod('___new', Array)
#19 /path/to/project/wire/core/Wire.php(484): ProcessWire\WireHooks->runHooks(Object(ProcessWire\Pages), 'new', Array)
#20 /path/to/project/site/modules/RockCalendar/RockCalendar.module.php(71): ProcessWire\Wire->__call('new', Array)
#21 /path/to/project/site/modules/RockGrid/RockGrid.module.php(502): ProcessWire\RockCalendar->ProcessWire\{closure}(Object(stdClass), Object(stdClass))
#22 /path/to/project/site/modules/RockGrid/RockGrid.module.php(116): ProcessWire\RockGrid->sseEndpointStream(Object(Closure), Object(Closure))
#23 /path/to/project/wire/core/WireHooks.php(1085): ProcessWire\RockGrid->ProcessWire\{closure}(Object(ProcessWire\HookEvent))
#24 /path/to/project/wire/core/Wire.php(484): ProcessWire\WireHooks->runHooks(Object(ProcessWire\ProcessPageView), 'pathHooks', Array)
#25 /path/to/project/wire/modules/Process/ProcessPageView.module(265): ProcessWire\Wire->__call('pathHooks', Array)
#26 /path/to/project/wire/modules/Process/ProcessPageView.module(116): ProcessWire\ProcessPageView->renderNoPage(Object(ProcessWire\PagesRequest))
#27 /path/to/project/wire/core/Wire.php(416): ProcessWire\ProcessPageView->___execute(true)
#28 /path/to/project/wire/core/WireHooks.php(968): ProcessWire\Wire->_callMethod('___execute', Array)
#29 /path/to/project/wire/core/Wire.php(484): ProcessWire\WireHooks->runHooks(Object(ProcessWire\ProcessPageView), 'execute', Array)
#30 /path/to/project/index.php(67): ProcessWire\Wire->__call('execute', Array)
#31 /path/to/server/vendor/laravel/valet/server.php(234): require('/path/to/project/index.php')
#32 {main} in /path/to/project/index.php on line 76

Warning: Cannot modify header information - headers already sent by (output started at /path/to/project/site/modules/RockGrid/RockGrid.module.php:455) in /path/to/project/wire/core/WireHttp.php on line 1823

This is going endlessly then and a lot of "broken" events are created. 🙂

And my question
Would it be possible to consider opening hours when creating recurring events?
For example, I want to create appointments every 75 minutes between 10 AM and 5 PM for the next 6 weeks. Do you have an idea for this?
If necessary, I could take a "dirty" approach and delete the unwanted appointments afterward. 😉

Thanks in advance,
Niko

[noodles]

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:

  public function init()
  {
    wire()->addHookAfter('/rockcalendar/events/',             $this, 'eventsJSON');
    wire()->addHookAfter('/rockcalendar/eventDrop/',          $this, 'eventDrop');
    wire()->addHookAfter('/rockcalendar/eventResize/',        $this, 'eventResize');
    wire()->addHookAfter('Page::loaded',                      $this, 'inheritFieldValues');
    wire()->addHookAfter('ProcessPageEdit::buildFormContent', $this, 'hookRecurringEventEdit');
    wire()->addHookProperty('Page::isRecurringEvent',         $this, 'isRecurringEvent');
    wire()->addHookAfter('ProcessPageEdit::buildFormDelete',  $this, 'addTrashOptions');
    wire()->addHookAfter('ProcessPageEdit::buildForm',        $this, 'openDeleteTab');
    wire()->addHookAfter('Pages::trashed',                    $this, 'hookTrashed');
    wire()->addHookAfter('ProcessPageList::execute',          $this, 'autoCloseModal');
  }

  public function ready(): void
  {
    $locale = $this->getUserLocale();
    if ($locale) {
      wire()->config->js('RcLocale', $locale);
    }
    wire()->config->js('RockCalendar', self::translations());

	$this->addSseEndpoints();
  }

It works fine like this.
Am I in for another surprise now? 🙂

[bernhard]

Hey @noodles thx a lot for your purchase and for your kind words 🤗 And thx a lot for looking into this on your own! I'm on vacation and I'll be back at my computer at Thursday - I'll take a look into your issue then. If you find anything useful until then please let me know.

  On 3/4/2025 at 9:25 AM, noodles said:

For example, I want to create appointments every 75 minutes between 10 AM and 5 PM for the next 6 weeks. Do you have an idea for this?

Expand  

Are you able to create this schedule on https://jkbrzt.github.io/rrule/ ?

  On 3/4/2025 at 9:25 AM, noodles said:

If necessary, I could take a "dirty" approach and delete the unwanted appointments afterward. 😉

Expand  

Personally I hate these kind of dirty solutions so I'm happy to work on a better solution but it needs to be a solution that helps everybody. Otherwise we might want to find a way to make it work for you and also work for everybody else (aka make something hookable or such...).

[noodles]

Hey @bernhard!

First of all: Enjoy the rest of your vacation! 😉 And thank your for your reply!

  On 3/4/2025 at 7:03 PM, bernhard said:

Are you able to create this schedule on https://jkbrzt.github.io/rrule/ ?

Expand  

Yes, I am! It's done with the "byhour" property, like this, which obviously is way nicer than any dirty workaround approach.

new RRule({
  freq: RRule.MINUTELY,
  dtstart: new Date(Date.UTC(2025, 2, 5, 10, 0, 0)),
  count: 30,
  interval: 75,
  byhour: [10, 11, 12, 13, 14, 15, 16, 17, 18]
})

Let me know if I can help in any other way. I'm in Vienna in April. Coffee's on me. 😉 

[bernhard]

  On 3/5/2025 at 8:37 AM, noodles said:

Hey @bernhard!

First of all: Enjoy the rest of your vacation! 😉 And thank your for your reply!

Expand  

Thx! It was great 🤩

  On 3/5/2025 at 8:37 AM, noodles said:

Yes, I am! It's done with the "byhour" property, like this, which obviously is way nicer than any dirty workaround approach.

Expand  

That's very good news, so we'll get it working! I'll let you know when I have the new version ready.

  On 3/5/2025 at 8:37 AM, noodles said:

I'm in Vienna in April. Coffee's on me. 😉 

Expand  

Cool. Let me know when exactly and we'll arrange something! 🙂 

[noodles]

Super, thanks a lot for your reply and for your work on the module.

Our project is almost finished – extremely fast, thanks to RockCalendar! 🙂  But I still have one use case where I’m currently working around a limitation.

In the hookRecurringEventEdit method, all fields are removed for recurring events. However, my client is using a booking calendar where events shouldn't be permanently deleted, as they may need to be made available again later. Right now, I could simply delete an individual event from the recurring series when it's booked, but that would mean my client would have to manually create a new event if it needs to be released again.

A more convenient solution would be to allow them to just make the event available again. So, I added a checkbox to the template that gets set when an event is booked. The event is then no longer offered in the frontend and is displayed in a different color in the backend.

However, it would be really awesome if my client could simply uncheck the box to make the event available again. But currently, that’s not possible. 🙂 

What was your reasoning behind removing all fields from recurring events instead of just the title field? I'm curious. 🙂 

For now, I’ve made a quick and dirty modification in your module to allow only the RockCalendar field and my additional field, but I’m very interested to know if I’m overlooking something.

 

Edit:
Okay, I probably know why. My field won't save. 😄 

Edited March 6 by noodles

[bernhard]

Hey @noodles

  On 3/6/2025 at 3:10 PM, noodles said:

Super, thanks a lot for your reply and for your work on the module.

Our project is almost finished – extremely fast, thanks to RockCalendar! 🙂

Expand  

Glad to hear that! 🙂 I've added that quote to the RockCalendar page on my website: https://www.baumrock.com/processwire/module/rockcalendar/ hope that's fine?

  On 3/6/2025 at 3:10 PM, noodles said:

But I still have one use case where I’m currently working around a limitation.

In the hookRecurringEventEdit method, all fields are removed for recurring events. However, my client is using a booking calendar where events shouldn't be permanently deleted, as they may need to be made available again later. Right now, I could simply delete an individual event from the recurring series when it's booked, but that would mean my client would have to manually create a new event if it needs to be released again.

A more convenient solution would be to allow them to just make the event available again. So, I added a checkbox to the template that gets set when an event is booked. The event is then no longer offered in the frontend and is displayed in a different color in the backend.

However, it would be really awesome if my client could simply uncheck the box to make the event available again. But currently, that’s not possible. 🙂 

What was your reasoning behind removing all fields from recurring events instead of just the title field? I'm curious. 🙂 

For now, I’ve made a quick and dirty modification in your module to allow only the RockCalendar field and my additional field, but I’m very interested to know if I’m overlooking something.

 

Edit:
Okay, I probably know why. My field won't save. 😄

Expand  

I'm not sure I fully understand. Fields are hidden because the idea is to inherit all fields except the date from the main event. That concept might be extended in the future - for example it might be necessary to show basic information for all events in a series but some details specific to a single event (like a weekly podcast with a general description and then an individual subject for each recurring item).

But in your case I don't understand where they want to enable/disable the event? Do you want to disable the main event and then disable/hide all events of the series? Or only one? I don't get it please be more precise with your description. Thx!

[FireWire]

  On 3/6/2025 at 4:25 PM, bernhard said:

Fields are hidden because the idea is to inherit all fields except the date from the main event. That concept might be extended in the future - for example it might be necessary to show basic information for all events in a series but some details specific to a single event

Expand  

@bernhard This is something that is coming up in my current project for a client that has support group meetings. For example, a support group meets every Monday at 3pm but the second meeting next month has to be moved from 3pm to 4pm due to an unforeseen situation, or maybe an in-person meeting will be held online instead. This would also apply if an occurrence needed to change days, so a recurring event could take place every Monday at 3pm but meeting "X" will take place on Tuesday due to that Monday being a holiday. This happens regularly enough with the client's operations that I have to take it into account.

In this situation they would need to:

1. Adjust the start/end time or possibly day for that specific instance
2. Update fields (such as a description or body field) for this instance to inform visitors of any changes when they visit the site
3. Click a checkbox to mark this instance has having had a schedule adjustment which renders a "badge" on that event when rendered in a list of support groups and make it easy to query with a selector. Will be used to differentiate occurrences that have had a schedule change vs just some edits to content somewhere on the page.

A couple of months ago I was tinkering with showing/hiding fields to achieve this but I haven't worked on that component of the site since then and don't remember where I was at with it.

[noodles]

  On 3/6/2025 at 4:25 PM, bernhard said:

Glad to hear that! 🙂 I've added that quote to the RockCalendar page on my website: https://www.baumrock.com/processwire/module/rockcalendar/ hope that's fine?

Expand  

Of course it is! 🙂

  On 3/6/2025 at 4:25 PM, bernhard said:

I'm not sure I fully understand. Fields are hidden because the idea is to inherit all fields except the date from the main event. That concept might be extended in the future - for example it might be necessary to show basic information for all events in a series but some details specific to a single event (like a weekly podcast with a general description and then an individual subject for each recurring item).

Expand  

Let's focus on appointments rather than events. In my case, I create a series of appointments: every weekday from 10 AM to 7 PM, every hour, until June 30th. People can book an appointment in my online calendar. Once booked, the appointment needs to be marked as "booked" so my client and his clients can see that it is no longer available.

My initial idea was to add a checkbox field to the appointment template. This checkbox would be automatically checked when an appointment is booked. If an appointment gets canceled, my client could manually uncheck it, making the slot available for booking again. However, I realized that this approach conflicts with the concept of recurring appointments since they are inherently identical.

That said, I forgot to update my post yesterday! 🙂 Here's what I ended up doing: Instead of modifying recurring appointments directly, I took a more straightforward and compatible approach. When an appointment from the series is booked, I delete that specific instance and create a new single appointment via the API. This way, my client can still modify the checkbox if needed, and the appointment time is kind of "extracted" from the recurring series. I think that's way cleaner than my previous idea.

[bernhard]

Hey @FireWire and @noodles I have a present for you: v1.6.0 now supports custom fields/values for recurring events.

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

wire()->addHookAfter('RockCalendar::keepFields', function ($event) {
  $fields = $event->return;
  $fields[] = 'booked';
  $event->return = $fields;
});

See the full docs here: https://www.baumrock.com/en/processwire/modules/rockcalendar/docs/recurring/#custom-fields-for-recurring-events

[noodles]

Ha! That's awesome! Thank you very much!!! 

[noodles]

I tested it. Works great. Thank you very much! I merged it with my adjustments. Maybe you’d like to take another look at it sometime. But for now, I think I’ve bothered you enough. 😄

RRule "byhour" extension

  On 3/5/2025 at 8:37 AM, noodles said:

Yes, I am! It's done with the "byhour" property, like this, which obviously is way nicer than any dirty workaround approach.

new RRule({
  freq: RRule.MINUTELY,
  dtstart: new Date(Date.UTC(2025, 2, 5, 10, 0, 0)),
  count: 30,
  interval: 75,
  byhour: [10, 11, 12, 13, 14, 15, 16, 17, 18]
})

Expand  

Problems with multilanguage websites and PagePaths module:

  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:

  public function init()
  {
    wire()->addHookAfter('/rockcalendar/events/',             $this, 'eventsJSON');
    wire()->addHookAfter('/rockcalendar/eventDrop/',          $this, 'eventDrop');
    wire()->addHookAfter('/rockcalendar/eventResize/',        $this, 'eventResize');
    wire()->addHookAfter('Page::loaded',                      $this, 'inheritFieldValues');
    wire()->addHookAfter('ProcessPageEdit::buildFormContent', $this, 'hookRecurringEventEdit');
    wire()->addHookProperty('Page::isRecurringEvent',         $this, 'isRecurringEvent');
    wire()->addHookAfter('ProcessPageEdit::buildFormDelete',  $this, 'addTrashOptions');
    wire()->addHookAfter('ProcessPageEdit::buildForm',        $this, 'openDeleteTab');
    wire()->addHookAfter('Pages::trashed',                    $this, 'hookTrashed');
    wire()->addHookAfter('ProcessPageList::execute',          $this, 'autoCloseModal');
  }

  public function ready(): void
  {
    $locale = $this->getUserLocale();
    if ($locale) {
      wire()->config->js('RcLocale', $locale);
    }
    wire()->config->js('RockCalendar', self::translations());

	$this->addSseEndpoints();
  }

 

Expand  

I am happy to provide my dirty code, if you'd like so. 😉 

[bernhard]

  On 3/7/2025 at 2:00 PM, noodles said:

I tested it. Works great. Thank you very much! I merged it with my adjustments.

Expand  

Great! It was actually a very little change so I was quite confident it should work as expected 🙂 

  On 3/7/2025 at 2:00 PM, noodles said:

Maybe you’d like to take another look at it sometime. But for now, I think I’ve bothered you enough. 😄

RRule "byhour" extension

  On 3/5/2025 at 8:37 AM, noodles said:

Yes, I am! It's done with the "byhour" property, like this, which obviously is way nicer than any dirty workaround approach.

new RRule({
  freq: RRule.MINUTELY,
  dtstart: new Date(Date.UTC(2025, 2, 5, 10, 0, 0)),
  count: 30,
  interval: 75,
  byhour: [10, 11, 12, 13, 14, 15, 16, 17, 18]
})

Expand   Expand  

Problems with multilanguage websites and PagePaths module:

  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:

  public function init()
  {
    wire()->addHookAfter('/rockcalendar/events/',             $this, 'eventsJSON');
    wire()->addHookAfter('/rockcalendar/eventDrop/',          $this, 'eventDrop');
    wire()->addHookAfter('/rockcalendar/eventResize/',        $this, 'eventResize');
    wire()->addHookAfter('Page::loaded',                      $this, 'inheritFieldValues');
    wire()->addHookAfter('ProcessPageEdit::buildFormContent', $this, 'hookRecurringEventEdit');
    wire()->addHookProperty('Page::isRecurringEvent',         $this, 'isRecurringEvent');
    wire()->addHookAfter('ProcessPageEdit::buildFormDelete',  $this, 'addTrashOptions');
    wire()->addHookAfter('ProcessPageEdit::buildForm',        $this, 'openDeleteTab');
    wire()->addHookAfter('Pages::trashed',                    $this, 'hookTrashed');
    wire()->addHookAfter('ProcessPageList::execute',          $this, 'autoCloseModal');
  }

  public function ready(): void
  {
    $locale = $this->getUserLocale();
    if ($locale) {
      wire()->config->js('RcLocale', $locale);
    }
    wire()->config->js('RockCalendar', self::translations());

	$this->addSseEndpoints();
  }

 

Expand   Expand  

I am happy to provide my dirty code, if you'd like so. 😉 

Expand  

I'll look into this when I find time, but I have to launch a project next week myself 😅

My plan for the RRule is to add another option to the GUI:

I thought about adding "Simple / Advanced / Expert" - but not sure yet. Maybe just adding all possible options (like in the link above) to the "advanced" tab would be better?

I think keeping the very basic "simple" option and a full blown "advanced" gui should be fine from a user perspective...

[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