At Liip, we often work with clients who have complex content management needs. One recent project was the new website for the Museum für Gestaltung in Zurich, the leading Swiss design museum with a diverse and active public program. A key requirement was a flexible event management system that could support a wide range of event types.
Understanding the requirements
In addition to its permanent and temporary exhibitions, the museum hosts a broad spectrum of events: from guided tours and school visits to multi-day workshops and the occasional concert or film screening.
These events take place at three different locations and cater to different audiences: individual visitors, families, friend groups, and school classes. Some events are free, while others require paid registration. Many are offered in multiple languages.
Managing this complexity required a system that could support:
- Recurring events with complex schedules
- Variable durations (from 2-hour visits to multi-day workshops)
- Multiple locations
- Audience segmentation and targeting
- Participant limits (minimum and maximum)
- Automated visitor communication (e.g., reminders)
In short, the museum required more than just a simple event list and a calendar.
Evaluating Drupal solutions
With Drupal, the motto is “there’s a module for that.” With over 53,000 contributed modules available, it was natural to begin our search there.
After evaluating several options, we identified the Recurring Events module as the most promising starting point.
Why Recurring Events?
Pros:
- It is the most comprehensive module for managing events in Drupal.
- It provides strong functionality out of the box, in some areas even exceeding our requirements.
Cons:
- Not all the museum’s requirements were covered.
- Some existing features didn’t align with the museum’s use cases and would need to be modified.
Identifying feature gaps
The Recurring Events module met many of our needs, but not all of them. This is a common challenge in software development: existing solutions often get you most of the way there, but rarely tick every box.
Here are some key features required by the Museum für Gestaltung that were not available at the time:
Multilingual support
In addition to the three national languages of Switzerland, the museum regularly offers events in English for international visitors. Full multilingual handling for event content and registration workflows is essential.
Group registrations
Most visits occur in groups, ranging from families and friend circles to school classes and tour groups. The system needed to support registering entire groups at once. If an event does not have sufficient remaining capacity to accommodate the whole group, the group should be put on a waitlist.
Default capacity per event type
Some event types (such as guided tours) recur frequently and always have the same fixed capacity. Setting a default value per event type would streamline content entry and reduce the risk of manual errors.
Locked event dates
In our use case, once an event is published and publicly visible, its dates must not be changed. However, at the time, the Recurring Events module allowed dates to be changed or deleted at any time. To avoid confusion and dissatisfaction with visitors, the dates should be locked once published online.
Tailored email communication by registrant type
Depending on whether the visitor is a private group or a school class, different teams are responsible for managing the event, and different email templates need to be used.
Deciding the right approach
The question now becomes whether to extend what’s available or build a custom solution from scratch. Let’s look at the options:
Option 1: Build a custom solution
This would give us complete control and flexibility.
Pros:
- Tailored exactly to the museum’s requirements without any compromises.
Cons:
- High upfront development cost.
- Reinventing features already available in existing modules.
Option 2: Fork the Recurring Events module
This is a pragmatic approach, especially in the short term, but it is difficult to maintain in the long term.
Pros:
- We adapt the module to meet all specific needs. Remove what we don’t need, change what is necessary.
- The fastest to implement during initial development.
Cons:
- Long-term maintenance burden: we’d need to track and integrate upstream changes continuously for the whole duration of the project.
- High risk that future changes to the module will collide with our own.
- Our improvements wouldn’t benefit the community, nor receive community improvements in return.
Option 3: Override the module with custom code
Use the module as is, and build the missing functionality alongside it using Drupal's APIs, which are designed to adapt existing features to a project’s specific needs.
Pros:
- We can make use of the existing features of the module.
- Clean separation between contributed code and project-specific logic.
Cons:
- Still requires ongoing maintenance of our custom code.
- A smaller risk of conflicts if the module’s feature set evolves over time.
- Our planned additions might be useful for other users of the module, but they wouldn’t be contributed back.
Option 4: Contribute to the Recurring Events module
Work collaboratively with the module maintainers to integrate new features directly into the module.
Pros:
- Aligns with Drupal’s open-source philosophy.
- Ensures long-term compatibility and community support.
- Features are reviewed and improved by other experienced developers.
- Reduces maintenance effort for our team in the long run.
Cons:
- Contributions must meet high standards for code quality and documentation.
- Contributions need to be reviewed and tested by the community. It is possible that contributions are rejected or take a long time to be reviewed.
- Requires additional communication and coordination during development.
A collaborative success
We chose Option 4: to work closely with the maintainers of the Recurring Events module and contribute the features that were missing for our use case. Over the course of several months, we actively collaborated through the issue queue, contributed code, and reviewed patches. This effort led to one of our developers being onboarded as a co-maintainer of the module.
The result was a success. We were able to deliver a powerful, flexible event management system that met the museum’s needs. It is built entirely on open source principles. Several of our contributions are included in the latest releases of the module, and additional improvements are still in progress.
At Liip, we strongly believe in strengthening the tools we use, not just for us and our clients, but for the entire Drupal open source community. If you're interested in improving event management in Drupal, we invite you to join the conversation and collaborate with us in the Recurring Events issue queue.
