Follow me on a little path down on memory lane:
Since the early days of SilverStripe there’s been a calendar module around. It’s the SilverStripe Event Calendar, by one of the early heroes of SilverStripe, the American developer Uncle Cheese (who actually ended up moving from the US to New Zealand and is now working at SilverStripe Ltd.). I first heard about Uncle Cheese back in the summer of 2009, when I went to visit my then-girlfriend, and now-partner-in-life Susana for her exchange year in Viña del Mar, Chile.
I had brought my Macbook, and was busy working on my startup, 1Calendar, and also excited with the framework I had chosen to power 1Calendar, SilverStripe. While dealing with a problem, I read a comment by a guy named Francisco, and found out, he was Chilean. It turned out he had his office, only a few blocks, away! Francisco and I met up, and I ended up working from his office for a few days, and learning more about the SilverStripe community. And he told me about this great community member, Uncle Cheese…
Fast forward to November 2014
It’s a module that we’ve been working on for quite a while - in this blog post I’ll share with you what led me to develop another calendar, and my thoughts behind it.
Deciding to build a calendar module
When I needed to build event management for 2 clients (Colin, and Adair Creative Group) back in 2012, I decided it was time to once and for all get calendaring right on SilverStripe.
In the days of 1Calendar we didn’t know much about SilverStripe, and I only vaguely started to understand the concepts of object oriented programming, so we abused SilverStripe, and built a lot of custom code. I later had some endeavours, playing with event aggregation based on Uncle Cheese’s calendar, which I’m also using on my own project Yogatid, which is a Danish yoga community site.
With those projects I ran into quite a few limitations with Uncle Cheese’s calendar. Let me start by saying that this shouldn’t be seen as a rant on why one product is better than the other, these are just my reflections. Also, Uncle Cheese’s calendar is doing a fairly good job at what it was built for: presenting public events on a website. My main grief is that events are tied to page types. That’s fine if you want to present public events, but what if you want to:
- aggregate events from different sources
- allow users on your site to have private events
- display only coming events in the backend
- work with 1000s of events that you want categorized
If you’ve ever considered similar use cases for that calendar, you will agree with me: I felt there was a need for a more flexible calendar. One, based on DataObject instead of Page, and one that allowed the end user to easily administer calendars and events from a single entry point in the backend.
SilverStripe Calendar by Title Web Solutions
That’s how I took out a few days to draw and think. I lined up all the possible use cases I could think of, and started diagramming. The outcome is what has now finally been released as SilverStripe Calendar by Title Web Solutions.
Our calendar aims to be a solid base for all calendaring needs, it’s built to be flexible and configurable so that it fits to most scenarios - both for web sites with public events, and web apps with private events - or a combination of both.
It contains quite a few features out of the box and most of these can be enabled and disabled through the configuration to fit your specific needs:
- Extensible. Customize it any way you want, while the basic concepts are taken care of
- Solid, opinionated models
- Event/Calendar/Category relations allowing complex filtering
- Public/Private events
- Comprehensive calendar/event administration
- Listing of events on the frontend through the CalendarPage
- Frontend calendar view, using the fullcalendar jQuery plugin
- Event Registrations (this might be moved to an external module)
- Calendar colors with configurable color options, and JS color palette field (works on both frontend and backend) - shading calendars allow for holiday calendars etc. to appear in the background
- No default frontend styling
- Composer based workflow
Thoughts & Considerations
The main point was that for administration of calendar events you’d rarely want to administer events that were in the past, so I used GridField to only display coming events to the user.
There’s of course also a filter for past events.
Also I gave the entire event creation process a thought. When creating an event on my Mac I have to enter a start and an end time. Mostly I’d be adding events that should start on a specific point in time, but I often don’t have a specific end time - instead and I’d expect them to take an hour, maybe 2, or similar. My point is that you should give the user the option to choose a duration instead of a specific end time. I built this into the calendar and the event model (it can be turned off).
The event model and event create/edit form is built generic, so it can be used both from the backend, or frontend, and also in modal boxes.
Below is a simplified ORM of the main objects in the calendar and their use cases:
There might still be a use case that’s not covered by this, and I’m fairly certain that the core is flexible enough to be used for any calendar-related use case.
Our plan was to sell this module as a premium module, but various factors - including lack of time and dedication to do this properly - have led to us now open sourcing it.
It’s the first release - the core is fairly stable, and is used on several production sites.
There’s unfortunately one but - it doesn’t have recurring events. Having worked with that at 1Calendar, I know that it’s a big thing to get right. It’s certainly possible though - Uncle Cheese did good work on this for his own calendar. I haven’t needed it yet in my own projects, but if you do need it,
get in touch, or send a pull request :)