It's About Time to Discuss Drupal Event Recipes

Martin Anderson-Clutz's NEDCamp session for the year started with an oopsie-daisy while he forgot to press the recorder. Don't worry, for those of you who couldn't attend in person, you only missed the initial few minutes. Nevertheless, Martin powered through, reminding us it was time to discuss Recipes.  After the successful conclusion of New England DrupalCamp 2024, The DropTimes reached out to several of the speakers to give an overview of their session. Martin, Senior Solutions Engineer at Acquia and Drupal Starshot Event Track Lead, generously agreed to share his thoughts.

A luminary in the Drupal community, Martin’s accolades are unmatched—he holds the distinction of being the world’s first triple Drupal Grand Master, certified across Drupal 7, 8, and 9 as a Developer, Front-End Specialist, and Back-End Specialist. He has also significantly contributed to the Drupal ecosystem, lecturing at numerous conferences, founding the London, Ontario Drupal Users Group, and advancing tools like Smart Date and FullCalendar.

In this interview with Alka Elizabeth, a sub-editor with The DropTimes, Martin reflects on his experiences presenting at NEDCamp and delves into his work under the Starshot initiative, which aims to enhance Drupal’s capabilities for event management. He highlights the evolution of Drupal recipes, explores the complexities of event-based tools, and shares developments slated for upcoming releases. Also, on how collaboration within the Drupal community has shaped tools and practices, offering insights into the future of event management and site-building with Drupal.

TDT [1]: How was your experience presenting at NEDCamp this year? Did your session's audience engagement or feedback spark new ideas or insights for you?

Martin Anderson-Clutz: It was great, except that I forgot to press the button to start the recording at first. So, anyone who goes back to watch the recording will miss the first couple of minutes. But it was a standing-room only, and the audience asked some great questions, so there was lots of engagement.

TDT [2]: Managing dates and times is a challenging aspect of web development. In your session, you explored how Drupal addresses these complexities. Could you share an example where the tools you discussed significantly impacted a real-world project?

Martin Anderson-Clutz: Some of these tools are built into the Drupal Event Platform, which was used to build the NEDCamp website. So, anyone who attended the camp (or even considered it) interacted with some of the tools we talked about.

TDT [3]: In your GovCon 2024 presentation, you discussed the evolution of recipes in Drupal, highlighting their journey from concept to implementation. Could you elaborate on the key milestones in this development process and how they have influenced the current capabilities of recipes?

Martin Anderson-Clutz: The most significant milestone was undoubtedly when the initiative team marked Phase 1 as complete earlier this year, meaning that the recipe system was ready to start building and using recipes, although obviously with some additional areas that will need attention.

The next major milestone was the release of Drupal 10.3, which marked the first version of Drupal that had the recipes system built in. Prior to that, anyone who wanted to use recipes had to patch Drupal core, which is not for the faint of heart.

Another significant milestone is fast approaching, with the release of Drupal 10.4 and 11.1. There are lots more improvements to the recipes system we’ll see in these releases, and the recipes that will be possible based on those will really take the sophistication of the solutions recipes can provide to another level. It’s an exciting time!

TDT [4]: As the Starshot Event Track Lead, what are the key challenges and opportunities you’ve encountered in advancing tools for event management? How do you see this shaping the future of Drupal’s capabilities for event-based use cases?

Martin Anderson-Clutz: The most significant challenge is the broad spectrum of capabilities that potentially roll up to the concept of managing events. The most basic version is a content type with a field to store date and time information, and for some sites, that would be enough. Many sites will need more, however, including the ability to associate a physical location or URL, display and manage events using a calendar, allow for online registration, make events recurring, and more. If we put all of this into the base Events recipe it would be too complicated to suit sites that don’t need all of it, and having a base that’s too simple puts the onus on the site builder to know how to add the capabilities their site needs.

Plus, the interface a site builder can use to apply and add to recipes is itself a work in progress, so defining an experience that is both intuitive and realistic for the early versions of Drupal CMS is an ongoing conversation.

TDT [5]: In your session, you did a deep dive into the Event recipe. Can you discuss how it supports features like recurring events, registrations, and agenda management, and how it fits into the larger Starshot initiative?

Martin Anderson-Clutz: For now, the Events recipe in Drupal CMS includes an Event content type, a Location content type, and views to display both kinds of content. We have companion recipes to provide a calendar display, on-site registration, and a permission-based ability to make events recurring. The line that defines which elements are included in the base Events recipe and which need to be added will likely be fluid for some time, so feedback from the community and what site builders commonly require would be very helpful.

TDT [6]: Recipes are positioned to enable rapid site-building across skill levels. How do they address the needs of developers tackling complex event management scenarios while remaining accessible to less experienced users?

In Drupal 7, the community had a single Date module that worked well for simple use cases but also had submodules and add-on modules in the broader ecosystem to help it meet the most complex requirements.

In Drupal 8, the community decided to include date-handling fields in the core, but by design, they were kept simple, which meant that a new ecosystem was needed to help meet the more complex use cases. That has turned out to be somewhat fractious, with a number of competing solutions to meet some common requirements.

One of the impacts of Drupal CMS I expect to see is helping the community to focus on a narrower set of best practices for some common use cases, including event management. I guarantee we won’t get everything right on our first try, so ongoing feedback will be critical to making sure we find the right balance and can adjust as the needs of site builders change over time.

Anyone who wants to weigh in can open an issue on the Drupal CMS project, but some level of discussion in the #starshot channel of Drupal Slack would be a good first step. For anything specific to event management, the #datetime channel is also a great place to throw around ideas.

TDT [7]: In your blog post "Mark Your Calendars," you discuss integrating interactive features into the FullCalendar module, such as drag-and-drop rescheduling and event resizing. How have these enhancements improved user experience in managing events within Drupal, and what challenges did you encounter during their implementation?

Martin Anderson-Clutz: I had the good fortune of being able to draw on the work of people who collaborated on similar features for the Fullcalendar View module, though, of course, I wanted to make some changes like not requiring jQuery, timezone handling, and more. There was a fair bit of trial and error, but in the end I believe we managed to find a path that handles some complex use cases without itself becoming too complicated.

That said, the overall structure of the module still reflects what was previously implemented by earlier maintainers. There is a deeper refactoring I am planning, potentially as soon as the next feature release, especially as we work to maximize performance.

TDT [8]: With recipes still in development, what upcoming features or enhancements are you most excited about, particularly for event-focused site-building?

There are a number of new config actions that will be available in the upcoming Drupal 10.4 and 11.1 releases, particularly around placing blocks and creating views, that I’m excited about. Also, the ability to broadly opt a recipe out of strict config comparisons but then rimpose it selectively will be huge for making it easier to create and maintain recipes.

TDT [9]: Collaboration is at the heart of the Drupal community. How has the feedback or contributions from the community shaped the development of recipes and event-focused tools under Starshot?

Martin Anderson-Clutz: The evolution of recipes has very much been a collaboration, with loads of work from a diverse pool of talented people. The early work of porting Drupal install profiles to recipes was extremely useful in helping to understand what capabilities a robust recipes system would need, but the work since then has really been driven by the broader experience of the community and the use cases they need to satisfy. For myself, I knew from my work on the Event Platform that a flexible way to place blocks would be a major win, so that has been the focus of my code contributions for recipes.

TDT [10]: Based on your current work with the Starshot initiative and your broader Drupal journey, what do you see as the next big opportunity or challenge for improving how Drupal handles event management?

Martin Anderson-Clutz: I’m currently in the planning stages of the next major version of the Event Platform. It was originally built as a set of modules that were conceptually very similar to recipes, but some of them included their own PHP, CSS, and Javascript code. Getting the Event Platform converted into a set of recipes will make it even more flexible, not only as a way to create a website for a Drupal camp or similar event but also to add capabilities to existing sites as their needs grow and evolve over time.

There are functional pieces in the Event Platform, like a tool to bulk generate time slots, and a drag-and-drop interface to schedule sessions to a time slot and room. Those and other elements will need to be moved out to separate module projects, and then they will be appropriately configured by the relevant Event Platform recipes. Turning them into standalone, configurable projects should allow them to be used for a broader set of use cases.

Also, for the Event Platform, I want the next major version to be engineered for handling multiple (e.g. annual) events more gracefully, and I’d love to see a configurable theme available to make it easier for event teams to get a good-looking front-end in place too. I’d like to give a big shout-out to the Florida Drupalcamp organizers for their work, which was really the foundation for the first iteration of the Event Platform. I see that they just gave their site a big design refresh, so hopefully, we can align with them again to amplify their continued amazing work for the benefit of the broader community.

Naturally, there are a variety of improvements I still want to make to Smart Date, FullCalendar, and the broader ecosystem built around them, but I expect a lot of that effort to be guided by the feedback I get from the community and what needs are most in need of new solutions.