What RSVP-System Recipes Handle — And What They Don't

The RSVP-System Cookbook is built around a simple promise: spin up a fully-featured community calendar and reservation platform by applying a set of Drupal Recipes. No manually clicking through the admin UI, no hunting for which modules need which config. You run the recipes, you get the system.

That promise holds. But there are three areas where the recipes deliberately stop short — not because we couldn't automate them, but because they involve credentials, external services, and infrastructure that are specific to your environment. This post documents those three areas honestly, so you know what you're getting into before you start.

What the Recipes Handle

First, the good news. The rsvp-system/rsvp-requirements metapackage handles your entire Composer dependency tree — 30+ modules including ECA, Smart Date, Search API, Solr, Facets, Gin, and everything else the platform needs. One line in your composer.json and Composer resolves the rest.

"rsvp-system/rsvp-requirements": "^1.0"

On top of that, the cookbook recipes build out:

• Community taxonomy and Community Landing content types
• Resource, Reservation, Event, Calendar, and Calendar Month content types
• ECA workflow rules — status transitions, conflict detection, moderation handoffs
• User profile fields with Primary Community and Secondary Affiliations
• Calendar display with community-scoped resource filtering
• Blackout period management
• The full stepped booking form

That's a significant amount of Drupal configuration that would take days to build by hand, applied in minutes.

What the Recipes Don't Handle

1. Solr and Full-Text PDF Indexing

RSVP-System uses Apache Solr for search and faceted discovery. The rsvp_search recipe configures your Search API index, defines your facets, and sets up the Views that power the content dashboards. What it can't do is stand up and connect to a Solr server — that's infrastructure.

For local development, DDEV makes this straightforward:

ddev add-on get ddev/ddev-solr
ddev restart

DDEV spins up a Solr container and RSVP-System's config points to it automatically. For production, you'll need a Solr instance — either self-hosted (we run ours on Linode) or a managed service.

The second piece is full-text PDF indexing via Tika. If your community uses the File Cabinet feature to store and search document attachments, you need Tika running alongside Solr to extract text from PDFs before they're indexed. DDEV's Solr add-on includes Tika, but you'll need to:

1. Confirm the Tika server is running and accessible
2. Enable the search_api_attachments module
3. Set the extraction method to Tika server in Search API settings
4. Reindex your content and verify PDFs are returning results

This is a test you need to run manually. Index a PDF, search for text inside it, confirm it surfaces. It takes ten minutes but it's not something a recipe can verify for you.

2. Google OAuth / OpenID Connect

RSVP-System ships with drupal/openid_connect as a dependency and the rsvp_auth recipe configures the Drupal side of the authentication flow. What requires manual setup is the Google Cloud Console side.

Here's what you need to do once per environment:

In Google Cloud Console:

1. Create or select a project
2. APIs & Services → Credentials → Create OAuth 2.0 Client ID
3. Application type: Web application
4. Add your authorized origins and redirect URIs:
   • Origin: https://yourdomain.com
   • Redirect URI: https://yourdomain.com/openid-connect/google
5. Copy the Client ID and Client Secret

For local DDEV development, use your DDEV URL:

• Origin: https://rsvp-core.ddev.site
• Redirect URI: https://rsvp-core.ddev.site/openid-connect/google

Google allows .ddev.site URIs for development since they resolve to localhost. DDEV's built-in HTTPS (via mkcert) satisfies Google's HTTPS requirement.

In Drupal: Configuration → OpenID Connect → Google → paste Client ID and Client Secret.

Keep your development and production credentials separate. It takes two minutes to create a second OAuth client in Google Cloud Console and it means you can lock down the production credentials without affecting local development.

The recipe configures the Drupal module. The credentials are yours to manage.

3. Environment-Specific Configuration

A few settings that the recipes intentionally leave at defaults, which you should review and configure for your environment:

Email rerouting. If you're running a non-Live environment, make sure reroute_email is configured to catch outgoing email before it reaches real users. The right pattern catches everything that isn't production:

if (defined('PANTHEON_ENVIRONMENT') && PANTHEON_ENVIRONMENT === 'live') {
  $config['reroute_email.settings']['enable'] = FALSE;
} else {
  $config['reroute_email.settings']['enable'] = TRUE;
  $config['reroute_email.settings']['address'] = '[email protected]';
}

File storage. The default Drupal public/private file system paths work for most setups, but if you're on a platform with ephemeral storage or a CDN, you'll need to configure this before uploading documents.

Cron. ECA's stale Tentative reservation timeout (default: 72 hours) runs on cron. Make sure cron is configured and running in your environment.

The Honest Summary

The recipes get you 90% of the way there. The remaining 10% is integration work that requires your credentials, your infrastructure, and a few manual verification steps. This is by design — a recipe that tried to provision a Solr server or register an OAuth client would be overstepping.

If you want help with the integration work, or you'd rather hand the whole setup to someone who's done it before — that's what Gluebox.com is for.

RSVP-System is an open-source Drupal platform for community reservation and event management. The cookbook and metapackage are available on GitLab and Packagist.