The Web is filled with complicated problems looking for solutions. Two of the more complicated problems we've recently encountered at Palantir deal with repeating events and moving content between sites in scenarios more complex than from one point to another.

These two problems came together in a project for the Balboa Park Online Collaborative, an organization that helps the 20 museums and cultural institutions located in San Diego's Balboa Park work together to create shared technology solutions.  This project resulted in 12 new modules that we either wrote or collaborated on and then contributed back to the Drupal project.

We'll be providing more details on those modules in future posts, but for now, we'd like to dive into a couple of the more complicated problems that we faced:

Repeating Events

Doesn't Drupal's Date module already provide repeating events? Haven't they been around in the Event module for years? The answer to these is "sort of". Basic repeating events have been around for years. If you wanted to have a repeating event every Wednesday for the next year you could have it. You could even exclude a few dates from the list of dates.

But, if you wanted to get more complicated than that you were out of luck. And, if you wanted to have custom details for an instance of an event you were also out of luck. Creating a system that handles complex rules is well, complex.

There are lots of use cases for more complicated events. For example, a museum may have an event every Tuesday and Thursday at 2 p.m. and 4 p.m. On occasion they may cancel the event, have a one-off special showing, or have special details for an instance of the repeating event.

It's a complicated enough issue that the Date module has not solved it in the two and a half years since an issue was first posted about it.

Pushing Content Between Sites

Moving content between sites seems like a simple enough task, right? Drupal already has the ability to move content between sites using Feeds. If you want to deploy content from one site to another there is the Deploy module. If we go back to our event use case and want to move large numbers of event instances between sites we run into weaknesses with both of these approaches.

One site could have a feed of events and another site could subscribe to it. But, what if the first site has hundreds of events? How long will the feed need to be? What if an event has changed that is no longer on the feed because there are so many events? Can you have a feed for potentially hundreds, if not more, events? Scaling up events is where standard feeds start to fall short.

While Deploy was designed for content staging, that really is not our use case with Balboa Park. Balboa Park has several sites, each with their own calendars, as well as a master site that aggregates these.

Solving Both Problems in a Reusable Way

Through the use of 12 new modules, leveraging some great existing modules, and collaborating with others in the Drupal community we solved both these problems. Balboa Park asked that what was built could be contributed to and reused by the community. Not only is it contributed and reusable, but the different parts are independent enough from each other that they can be used in other applications or cleanly swapped out, as is the case with the repeating event UI.

Stay tuned over the next few weeks as we share the details of how we solved these problems and the modules that power the solutions.