How do the various Calendar plugins fit together?

So I’m looking to integrate a calendar into a Kirby site. It’s to maintain events and planned training sessions on a sports club website. What I’m looking for:

  • graphical panel editor interface
  • calendar entries need to be ‘taggeble’ (so that an event is ‘training session’, ‘competition’, ‘social event’ and similar
  • custom fields on calendar events - like ‘location’, ‘trainer’, etc
  • some way to display the calendar graphically on the main site (read only), per year, per month
  • programmatically access calendar entries to list them in ‘upcoming events’ sections
  • export calendar so that it can be added in (mobile) apps, ical, ics or similar

It seems there are several calendar related plugins (as a new user I can only post 2 links a post so I had to mangle to urls):

  • Kirby calendar board: github -> texnixe/kirby-calendar-board
  • Calendar: github -> bastianallgeier/calendar
  • Kirby-Calendar: github -> moritzz/Kirby-Calendar
  • Kirby Calendar Plugin: -> mzur/kirby-calendar-plugin

The first seems to be a graphical editor for the panel, and it defines a data structure where the calendar events are stored. The manual says there’s a way to make front end view as well, although it doesn’t explain how - I think you have to completely implement it yourself.
The seconds seems to be more of a library to work with dates, not Kirby specific, although the others all seem to reference it.
The third, I think, has a data model where events are content of regular pages; it provides snippets to list calendars as event lists but no real gui, but it does supply ICS support.
The fourth also defines a data model to store event data, structured fields etc - and various snippets to display events as tables through table element, divs, etc. It also provides ICS support. Last update was 3 years ago though.

So, am I missing something here? It seems that they all supply slightly different functionality, but because they all store data in different ways, I guess they won’t interoperate? Is there a ‘current best practice’, or should I just wing it and piece together what I need from the various available options?



I hate to say it but theres a fifth way :slight_smile:

I looked at the various solutions available that you listed and in the end walked my own path.

This is the way i tackled it.

  1. Create an Events Section
  2. Use a sub page for each event, with date & time start end custom fields, add location fields and others as you see fit.
  3. Used Full Calendar jQuery plugin to display them on the front end, and on each event page i had a mini calendar in the side bar as well.
  4. optional - Use the scheduled plugin to automatically post events at a future date, and auto remove them when the event has passed.

This way is great because each event is its own page which means you can do what the heck you like with it. Rolling your own ICS export isnt all that hard either, you can do this with a route. Theres a few recent threads on this.

Listing upcoming events out sorted by calendar month was one of the trickier hurdles I had to get over. I can share some code for that if you want it, just shout.

Hopefully that gives you more food for thought. ive built a few events areas, so if theres anything i can help with, just give me a nudge.

Right rolling your own is always an option too I guess :slight_smile: But as so much work has been done already on these various plugins, I figured that would be the path of least resistance… Because I guess to get the Full Calendar jQuery plugin, you had to do quite a bit of work to get it to fetch the data, or was it not so bad?

Also I guess the data model depends on what sort of ‘event’ we’re talking about. If we have say 10 training sessions a week (across teams and locations), that would be 510 events per year for the training alone - and that is if we split it all under ‘year’ pages as well, which you would then have to account for in the code everywhere. So that means having 510 pages in the panel. And you have to manually be careful to name those event pages consistently, which (at 510 times a year) is bound to go wrong at some point.

But since you must’ve thought longer and harder about it than I, maybe you disagree?

Wasn’t a bother at all… i got Kirby to write the javascript (mine was an array becuase i had more events coming in from an external source, so i had to combine them into one calendar):

<div id='calendar'></div>
$(document).ready(function() {
    header: {
      center: 'title',
      right: 'today',
      left: 'prev,next'
		defaultDate: '<?= date('Y-m-d') ?>',
		navLinks: false,
		editable: false,
		eventLimit: true,
    events: [
		<?php foreach($eventroot as $event): ?>
        title: '<?= $event['ETitle']; ?>',
        url: '<?= $event['ELink']; ?>',
        start: '<?= $event['EStart']; ?>',
        end: '<?= $event['EEnd']; ?>',
        eid: '<?= $event['EID']; ?>',
        src: '<?= $event['ESrc']; ?>',
        className: '<?= $event['ESrc']; ?>'
		<?php endforeach ?>

Blimey! That’s a lot. There must be someway to restructure that so it’s less pages. But then if you used the other ways you would end up with one epic structure field on a page. Swings and roundabouts.

Theres an alternitive - Don’t store the events in Kibry at all. Use Google Calendar instead. I have succesfully pulled in data from Google Calendar and pulled it into the front end for display in jQuery Full Calendar.

Yeah I was actually starting out thinking I would put it in Google Calendar, but then I started searching for a Kirby plugin to do it for me, then I found the existing plugins, and then I thought it would be better to do it internally to have more control over how it all fits together…

Maybe I need to think about it some more, it seems that there will be no ‘best’ way without me doing a lot of work (well, not a lot lot, but more than just installing and configuring a plugin). Coming in to this new though, it seemed that there are several plugin projects that partly overlap but focus on different aspects, and aren’t compatible, which is a shame. But maybe I was missing something, which is why I asked. Thanks for your responses so far, much appreciated.

I have a solution that mixes google calendar data and kirby event data, using the google calendar API. They all get displayed on jQuery Full calendar as if they all lived in Kirby. When you click on a Gcal event on the calendar, it pops a modal window with the event details in it this information is set within Google Calendar. If the event is an event page with in kirby, when you click on it it will take you to the page in the Kirby site and display the full article.

I think this is the way you should go - you have alot of repeating events, and this way lets you do a one off event as a kirby page (like an open day or a fete or charity match or what ever). I think those are more easily handled though the Google Calendar interface.

The codes a bit much to put in here, but i’m happy to put a repo together and share if it will help. Heck, i might even write a blog post… :slight_smile:


That does sound like best of both worlds - it would even add mobile training editing (through the Google Calendar mobile app), which I had written off earlier for being too cumbersome to implement.

Yes if you wouldn’t mind, I’d be very interested in that code.

Ok, I’m a little busy today with client work, but I’ll try and pull a repo together and do something of a write up over the weekend.

For repeating events I use start and end dates, a select field for the repeat interval, and a structure field for exceptions. Works fine all in Kirby. Bastians calendar plugin to help with dates, and some logic to calculate dates per day to show in frontend. No need for jQuery plugins.

What I see in practice though is that it’s fine to do initial entry of events like that, but then you need to be able to modify them - maybe it’s a holiday and the event is cancelled, or you want to add some different data every time on what the class topic will be, so then you need to either make events anyway when something is modified for a regular event (like a copy-on-write) plus coordinate ‘regular’ from ‘customized’ events, or have some parallel storage for changes to regular events. Or how do you deal with this issue? In your structure field, do you store more than ‘events that don’t happen on date such-and-so’? It seems that would get unwieldy very quickly in your templates/snippets, no?

I wouldn’t mind dropping the jQuery dependency at all - at the time i just had to get it done, and the site was already using it. Maybe i’ll refactor my approach if i get a chance before blogging it. I’ve gone off jQuery over the last year.

The structure field is only for a particular event, it just takes a date field as input.

For example, Event X takes place Wednesdays let’s say till the end of this or next year every two weeks, but not on Wednesday June 20, 2018 and not on Wednesday, August 22, 2018. So I enter these two dates in my structure field. Any time I have to cancel an event, I just add it to the exceptions.

My logic then calculates the difference between the array of exceptions and an array of all dates between start date and end date.

Well, that could soon get messy but depending on what sort of information you would have to change, you could even handle these variations in structure field entries or subpages that are then tied to particular date.

At least you wouldn’t end up with hundreds of event pages for repeating events.

It really depends on your particular use case what will work for you or not. With the setup for a current project, I can mix single and repeat events in one form and handle everything with two functions and the calendar plugin. But then I don’t think my client needs to change other data of these events.

@roel_v Well, here you go, as promised, a repo using google calendar and Kirby articles to display them using Fullcalendar for jQuery.

To get this to work, you need to setup an account on the Google Calendar api website and get credentials in JSON format. The event page will break until you do this. Basically to run this example locally you need to setup a local test domain, and set this on line 16 of webpack.mix.js before doing the following:

  1. yarn install
  2. cd public && composer install
  3. Open config.php and set lines 27 - 29 with your Google Calendar information
  4. Make sure you credentials are all set in public/eventcreds.json. You can this info from your google API account.
  5. yarn start

I am not much of backend programmer, and the PHP in this could definatly do with a refactor. Also, the event sidebar list is in alpha order rather then calendar month order, I havent yet figured that out. It does all work though!

Hope this helps.

1 Like

Thank you for taking the time to put this together. I will study this example - it’s been years since I did any js work so I will have to dive into the tooling first :slight_smile:

No worries, theres actually very little javascript involved, its just a loop to run out the events into the bit that initialises the calendar. Nothing scary.