Earlier this year I made the difficult decision to step down as Events Recipe track lead in the Starshot initiative. Having successfully delivered the requirements for a 1.0 release of Drupal CMS, I decided my skills and expertise could have more impact elsewhere.
I loved the opportunity to collaborate with so many of the best minds in the Drupal community. But there was important work needed on a different initiative, the Drupal Event Platform.
What is the Event Platform?
The Event Platform initiative was created by the Event Organizers Working Group to reduce the effort and resources required to plan and deliver a Drupal camp. Recognizing both the importance and the resources needed for a quality event website, the initiative aims to provide a common platform organizers can leverage and collaboratively improve.
Some will remember the Conference Organizing Distribution, which was popular among Drupal camp organizers, but unfortunately never got upgraded from its Drupal 7 compatibility. In March of 2021 the discussions started around what the Event Platform should include, what approach we should take for development, and more. The challenges imposed by distributions have since been well articulated as driving the need for the Recipes initiative, but even before that was announced, I pushed for a more composable approach.
At one of the early meetings, Mike Herchel joined to suggest that we use the newly rebuilt Florida Drupalcamp website as a starting point for the Event Platform. It had a number of the features we had discussed, so I cloned a copy of the FLDC 2022 website, and started working to make it a configurable starting point camp organizers could use and adapt for their own events.
Recipes didn’t yet exist as a concept, but I had been working on a set of modules I called Configuration Kits, that similarly provided sets of configuration that could be used together to quickly deliver on common site building needs. We divided the extensive configuration from the FLDC site into submodules for sessions, sponsors, and more.
I wanted a central place for a camp organizer to provide the critical information about their event, so I created a Config Page where all the content could be collected, and then displayed in different places throughout the site.
By design, the initial scope of the Event Platform was kept tight. Ideally a camp could drop some or all the submodules into an existing site, as their needs dictated. I envisioned that most camps would want to build a custom theme, but I created an event_platform_olivero submodule to act as a guide for where blocks were intended to be placed.
The first alpha release of the Event Platform was on Feb 6, 2022, a little under two weeks before FLDC 2022 itself. There were a variety of updates throughout 2022, including a first beta release on August 28. The first event I know of that built their site on the Event Platform was Drupal Dev Days 2023 in Vienna, and it has since been used by other prominent camps like NEDCamp, DrupalCamp NJ, Pacific Northwest Drupal Summit, and DrupalCamp Berlin. A Drupal Users Group meetup even included a presentation about using the Event Platform for an academic conference unrelated to Drupal.
Adding features
Since those early days I’ve added features where I could see an opportunity to make the website more useful for camp organizers or attendees. The Event Platform now has a submodule for Flag integration, that allows people to create their own personalized camp schedule by choosing which sessions they’re interested in attending.
One of the tedious parts of setting up the Event Platform was creating taxonomy terms for all the time slots in which sessions would get scheduled, so I created a tool that could bulk generate them based on the camp dates and a provided set of start times. Scheduling sessions by assigning them time slots and rooms in the edit interface of each session also seemed laborious, so I created a drag-and-drop interface to quickly (and visually) assemble a schedule of accepted sessions.
To address feedback from camps that have used the Event Platform, we have also built in better support for multilingual sites, made the permissions given to speakers for creating sessions more nuanced, and more. Thanks to the tremendous power and flexibility of the ECA: Event - Condition - Action module we have been able to reduce the number of modules needed, and build even more automation into the features camp organizers get out of the box.
In my discussions with camp organizers, I noticed that camps used a variety of tools to collaboratively evaluate the proposed sessions and decide which to accept. Recent versions of the Event Platform include a webform designed to allow session moderators to score each session using Likert scales. This makes it very easy for a camp to customize the criteria on which they will score the sessions. Moderators can then see a filterable list of proposed sessions ranked by average score, and then bulk accept or reject them. The users who submitted the sessions will be automatically sent an email notification of the camp’s decision.
A desire to have tabs generated automatically for the schedule pages led to the creation of the Views Summary Tabs module, and has led to new and improved features in other modules like Webform, Smart Date and Moderation State Condition. In a previous blog post I wrote about how the need for more flexible menu navigation inspired the creation of Smart Menu Links. Seeing that Recipes held the promise of a much more flexible future for the Event Platform, I pushed for the addition of configuration actions to place blocks in default or admin themes, without needing to know the specific name of either.
Although the usage numbers for Event Platform don’t indicate a large number of sites currently using it, the work in the initiative has had a much broader impact in the Drupal ecosystem. And of course, local camps play an important role in creating grassroots enthusiasm for the Drupal community, which ultimately feeds the success of higher profile events like DrupalCon.
A multi-event architecture
An issue raised in the early discussions about the Event Platform was how it would work year after year for annual camps. Some camps manually reset the content of their site. Other camps create a new site for each year. Another potential approach discussed was documenting the steps to use a solution like Tome to create a static archive after a camp was over, so that the content could be reset within Drupal but preserved for posterity.
At Florida Drupal Camp 2025 I got talking with one of the COD maintainers, who made a persuasive argument for a multi-event architecture, a more complex approach that allows a single site to keep content for multiple iterations. He also pointed out that the DrupalCon website uses this approach, which became a source of inspiration for how it could be implemented.
The 2.0 branch of Event Platform released two months ago implements this new architecture. Events are now stored as taxonomy terms, partly because Drupal core has the most robust support in views for contextual arguments that are taxonomy terms. Sessions and other kinds of content now contain an entity reference to a specific event, but in most cases the fields are hidden from everyone but site administrators, and automatically populated using ECA. The end result is a very similar user experience for end users.
Handling sponsors proved to be a little more complex. It would have been easy enough to associate a sponsor with one or more events, but I could foresee that a particular sponsor might choose different sponsorship levels (e.g. platinum, gold, etc) in different years. I had to create a new relationship entity, called Sponsoship, that references one sponsor, and one or more events.
Event planning workflow
I also realized that many camps follow a similar pattern in their planning:
- Dates announced - Announcing when and where the upcoming camp will be. Typically sponsor outreach begins here, and often camps will work on securing keynote speakers and sometimes other, featured speakers too. Some camps also start working on the trainings here as well
- Call for session proposals - Potential speakers are invited to submit ideas for sessions. Some camps list the proposed sessions, with or without listing the person who proposed it
- Session deadline - After the deadline has passed, a team will evaluate the sessions and decide which to accept. After confirming with the selected speakers, the sessions are organized into a schedule
- Schedule announced - The schedule is now publicly available, and some events provide an ability for users to “like” sessions they want to attend
- Underway - once a camp has started, the key information is often how to get to the venue, and the current day’s schedule
- Complete - Once a camp is finished, most camps direct people to view the session recording, post thank yous to the sponsors and attendees, and so on
With events as terms, we could create a moderation workflow with stages that reflect the structure above. Knowing that the communication and functional priorities change based on the stage, could the website automatically surface and promote the relevant pieces? I collaborated with a number of event organizers to collect feedback on this idea, what the stages should be called, and what a reasonable set of priorities might be as a starting point.
I found a module called Moderation State Condition which allows blocks to define their visibility based on the moderation state of the content being viewed. Unfortunately, it didn’t work with taxonomy terms, but I was able to provide a patch to add that, which has now been included in a feature release. Smart Menu Links were built to include an ability to limit their visibility to specific workflow states.
From its early versions, the Event Platform included a CTA (call to action) custom block that displayed link information managed in the event config page. Now, multiple CTAs can be created and managed as Storage entities, and in the configuration of the CTA block a camp organizer can specify what CTA to display in the site header at each stage of the workflow.
The Event Platform has always defined a speaker role, with permissions to create and edit their own sessions. Thanks to the new workflow, the Event Platform has now implemented the Access Policy API to only grant an ability to submit sessions during the stage of the event workflow in which the call for session proposals is active.
Best of all, the transitions in the event planning workflow were easy to automate. From the outset the Event Platform captured information on the event dates and the session submission deadline. By adding fields for the start of the call for session proposals and the date on which the schedule should be published, an ECA model can now automatically move an event to the appropriate stage in the workflow. This in turn triggers updates to the site information displayed, leaving camp organizers to focus on other work.
Behold the Event Horizon
In the conversation with camps that have used the Event Platform, it became clear that some camps don’t have the resources to create a custom theme for their website. A couple have minimally tweaked Olivero to act as their site’s front end. In conversations at Florida Drupal Camp this year, it also became clear a number of camps were also using lightly edited forks of newer versions of the Florida Drupal Camp website. The challenge became rolling out updates to what were now completely separate code repositories.
I talked to Bernardo Martinez about it and we agreed to make the newly updated FLDC theme into a contrib theme that could receive updates in one place, and those changes would be available to any camp using the theme. Knowing that some camps only need to customize a few elements, we gave the theme configuration options for primary and secondary colours, as well as an ability to upload graphic elements that help to give a local flavour.
We sprinted on the project at DrupalCon Atlanta, and someone at our table used AI to suggest potential names for our new contrib theme. Event Horizon was clearly the best option, and now the theme has an alpha release, with hopes to have a first beta release in the near future.
The road ahead
What’s next for the Event Platform? There are a few things on my list of priorities:
- Session confirmation - Update the last stage of the session acceptance workflow to be labelled “Confirmed” instead of “Published” and provide an ability for the speaker to confirm in the site that they will be able to deliver the session, moving it to the appropriate stage. The scheduling and other session listings can then focus on sessions that are confirmed
- Move to recipes - In their original form, the Event Platform submodules were very similar to Drupal recipes. Ideally some or all of them could be moved to recipes, to take advantage of the power and flexibility of the recipes system
- Create a site recipe - Some feedback from camps that have used the Event Platform indicated that they expected a more “ready to use” site. The Event Platform hasn’t been opinionated about optimizations for SEO, social media, and overall user experience, but we could create a site recipe (and potentially a composer project template) to make it even faster to get a site based on the Event Platform ready to launch
- Create a site template - The technical specification of what will constitute an official Drupal site template (and therefore available within the upcoming marketplace) has yet to be announced, so it’s impossible to know what will be the level of effort required to make the Event Platform available as a site template yet
- Available on Drupal Forge - The team at Drupal Forge have set up an excellent system that allows even non-technical users to try out specific flavours of Drupal, including Drupal CMS. We’ve already had discussions with them about having the Event Platform as an option that could be spun up in seconds
- Fancier email - The Easy Email module and its companion recipe have made it easier than ever to have a Drupal send out nicely formatted HTML emails, instead of the plain default for Drupal. Event Platform should add this extra level of professionalism to its communication
- Welcoming our robot overlords - I have already thought about a few ways that AI could help camp organizers, for example as an initial review of proposed sessions for spammy or inappropriate content. I would love to develop more ideas about how AI could enhance the Event Platform, however, so I welcome any suggestions
See it in action
I recently gave an in-depth talk and live demo of the Event Platform at Drupal MidCamp, so check out the recording if you’d like to see how it works. That said, even since that presentation there has been some notable progress in the recent 2.0.0-beta4 release. Here's an updated demo that features all the latest features and improvments:
I will also be giving an updated presentation in July at Drupal Camp Asheville. I hope I’ll see you there! And if you have any ideas on how the Event Platform could be even better, I would love to hear from you. Please open an issue or join us for one of our monthly initiative meetings.
Comments