When I first heard the vision for Starshot (now Drupal CMS), I knew exactly how I wanted to contribute. For years I have been working on trying to make it easier to quickly build Drupal sites following established best practices. I had been working on a set of modules I called Configuration Kits, but they were conceptually very similar to Recipes, albeit in a simpler (and less flexible) form.
For many readers it won't be a surprise to hear that I am also deeply passionate about making it easier to manage dates and times in Drupal. It's what led me to create Smart Date, as well as an ecosystem of modules around it. Eventually this led me to help create the Event Platform, a set of modules to accelerate the creation of a website for organizing a Drupal camp.
I feel tremendously honoured to be named Track Lead for the Events Recipe in Drupal CMS. It's an amazing opportunity to leverage my interests to help make Drupal even more powerful out-of-the-box.
Initial planning
Even before I had any formal role in the Events Recipe track, I tried to contribute some thoughts around what I've seen as the commonly expressed requirements, in my own years of building Drupal sites, as well as talking to other developers about their own requirements for Smart Date. A number of other people prominent in Drupal's events space have shared their thoughts too.
I also spent some time reviewing popular events solutions on competing platforms like Wordpress. Beyond the obvious difference that many have a "freemium" model that require payment to unlock the full capabilities, there were come common features, such as:
- Registration (potentially including paid)
- Booking management, including approval and rejections
- Integration with calendar apps
- The ability to display the event location in a map
- Notifications/reminders before an event's start
Some early progress
I have always believed that projects like Recipes (and Configuration Kits before them) can be very useful to think of as "systems": an events system, a staff directory, a locations map, and so on. As such, they should include both the basics of a typical content type, but also one or more views to present the information. In my experience they are most useful if they can provide something tricky to configure, and if they can establish a predictable baseline for commonly needed functionality, that can be expanded to meet more specific requirements.
I had previously built the Smart Date Starter Kit as a way to help site builders easily implement what I consider best practices for creating a basic events system with Smart Date. It doesn't include recurring dates by default, but is configured in a way that allows for recurring dates to be added with just a few clicks. I knew that many (but not all) sites that use Smart Date would also want to easily set up a calendar display, so I created a separate Smart Date Calendar Kit. In more than four years of maintaining both projects, I have consistently seen that the usage numbers for the calendar kit is about 20% lower than the starter kit.
I decided to adapt the starter kit into a new project, so it could be quickly changed in whatever way the community and Starshot leadership decided was best for the overall initiative. After discovering that the Events namespace had been effectively abandoned (more than 10 years without a commit), I decided to apply for this namespace as the working home of what will be the Events recipe for Drupal CMS. I decided to similarly adapt the calendar display into Events Calendar.
I had previously developed Locations as a module and recipe that would provide a Location content type, and a Leaflet-based map to visually display locations. I created the Events Locations recipe to integrate that with Events. I would normally also recommend using the Inline Entity Form module to make it easier for authors to manage these kinds of nested relationships, but since it doesn't have a stable release, it doesn't have security coverage. I firmly believe that everything that makes it into Drupal CMS should have security coverage.
The last capability I saw as essential was registration. On the meta issue for the Events recipe there was a suggestion to look at the Entity Registration module, and it lined up with some research of my own in the space a few months back. There's now a Drupal 11-ready release of the module, and an Events Registration recipe to get it set up and enabled as the default for your site's event content type.
There is still an open question about how much of this should be included in a standard installation of Drupal CMS. I decided to keep the recipes more granular to start, thinking that would be easier to combine them later if need be, than to try and tease them apart. I have proposed a Project Browser feature to allow add-on modules and recipes to be suggested to the site builder, which I believe would allow for recipes that are simpler to begin with, but easily expanded to meet more complex needs.
The final recent development was the addition of add-to-calendar links. I previously created a Date Augmenter for this purpose, but it had always been left to a site builder to get this configured. I decided that this should be included in a recipe as well, so a recent release of the Events recipe has this built in too.
In my personal view, this base Events could be a solid foundation for the basic needs of Drupal CMS, especially if the other capabilities are easy and intuitive to add if needed. I'd like to get more community input on this question, however, so in the coming days I will release a survey on the question of what event features every Drupal site needs, which are frequently needed, and which are less frequently needed but complex enough to implement that they would benefit from a recipe. More on that to come.
Defining a new experience for Drupal
Crucially, a key point of Drupal CMS is to define a new experience for people wanting to try out Drupal for the first time. While experienced Drupalists love the platform for the flexibility and broad range of capabilities available in the thousands of free modules available on drupal.org, this hasn't been evident to people just getting started.
Drupal CMS will offer an expanded experience of the broader possibilities when using Drupal, by including contributed modules and their initial configuration out-of-the-box. This will help newcomers to understand how Drupal can help them meet a variety of common requirements.
In the last few days there's been some significant progress moving the functionality developed within the Events recipes into the new Drupal CMS project, to define how newcomers will be able to work with dates and times. A base events system includes an Events content type and a view with displays for upcoming and past events. More recently, we've incorporated the work in the Events Location recipe mentioned above, so people trying out Drupal will be able to work with not just events but also locations, and associate the two.
Thanks to the robust config validation and testing that's already built into the Drupal CMS project, I discovered some work that needs to be done on the add-to-calendar links to get them ready for inclusion, so that will be a priority in the days ahead. Incorporating the calendar and registration work will follow soon after.
The Events recipes need you
So what else is being worked, and how can you help? For starters, there are a couple of patches to core views that are currently needed to get the Events recipe to apply as expected:
- [#3464160] Warnings output when importing a view using tab links
- [#2804195] Views does not create parent local task for a default local task
There are also some UX improvements that could allow Drupal CMS to feel more like popular calendar software content creators use every day. I created an issue to explore the potential improvements, so I'd love to hear the community's thoughts on ways we can make the Drupal CMS a joy to use.
Get this show on the road
I recently had the opportunity to present at GovCon (video below) about some of this, and it created some great discussion. My next appearance will be at Twin Cities Drupal Camp, so if you're interested in hearing more (and catch all the latest developments) then hopefully I will see you there.
Comments