Queen of San Diego — Tech Blog

Under the hood at queenofsandiego.com

Building and Deploying 6 Themed Artist Event Pages with Modal Booking Integration

Overview

The Rady Shell summer concert series includes 10 artists across the season, but only 5 had dedicated event pages on queenofsandiego.com. We needed to create pages for Wynonna & Melissa Etheridge, Sarah McLachlan, Buddy Guy, Weird Al Yankovic, and Mariachi Usa—each with artist-specific theming and a unified booking modal that accepts payment and contact information. This post details the technical implementation of 6 new artist pages, infrastructure provisioning, and the correction of existing "Reserve Now" button behavior across all 10 artist pages.

What Was Done

  • Created 5 new themed artist pages for missing Rady Shell events
  • Implemented booking modals on all 6 new pages and retrofitted 4 existing pages
  • Provisioned AWS infrastructure: Route53 DNS, CloudFront distributions, S3 buckets, and ACM certificates for each subdomain
  • Wired all "Reserve Now" and "Book Now" CTA buttons to invoke the same modal behavior
  • Updated Google Apps Script for unified pricing configuration across all 10 artist pages
  • Deployed all pages to production and validated end-to-end functionality

Technical Architecture

Page Template Structure

We followed the existing pattern established by the Bob Dylan page. Each artist page lives at a subdomain like wynonnamelissa.queenofsandiego.com and is deployed to an S3 bucket named queenofsandiego-artistname-event. The source files live in /Users/cb/Documents/repos/sites/queenofsandiego.com/rady-shell-events/ alongside a shared RadyShellEvents.gs Google Apps Script file that handles all booking logic.

Each page includes:

  • Artist-specific HTML structure with concert details, pricing, and seating info
  • Custom CSS theming that matches the artist's brand (color palettes, typography, imagery)
  • A booking modal that opens when any CTA button is clicked
  • JavaScript that validates form input and submits to the GAS endpoint

Booking Modal Implementation

The modal was the critical piece that needed to work identically across all pages. Rather than having each page manage its own modal logic, we created a shared modal structure that accepts concert-specific metadata as parameters. The modal accepts:

  • Concert date and artist name (populated via data attributes)
  • Passenger contact information (name, email, phone)
  • Payment information (ticket quantity, pricing tier)
  • Form validation to ensure required fields are populated before submission

The modal submission sends data to the Google Apps Script endpoint, which validates the request, writes to Google Sheets for record-keeping, and returns a success/failure response.

Infrastructure Provisioning

DNS and SSL/TLS Setup

For each new artist subdomain, we needed to:

  1. Create an A record in Route53 (zone: queenofsandiego.com) pointing to the CloudFront distribution
  2. Request an ACM certificate for the subdomain (e.g., wynonnamelissa.queenofsandiego.com)
  3. Wait for DNS validation or use email validation to confirm domain ownership
  4. Attach the certificate to the CloudFront distribution's default SSL/TLS settings

We initially created a wildcard certificate for *.queenofsandiego.com to cover all artist subdomains, but a stray pending certificate was accidentally left in the account. We deleted it to clean up and used the wildcard cert instead.

S3 Buckets and Static Hosting

Each artist page is deployed to its own S3 bucket:

  • queenofsandiego-bobdylan-event
  • queenofsandiego-paulsimon-event
  • queenofsandiego-koolandthegang-event
  • queenofsandiego-gypsykings-event
  • queenofsandiego-brandcarlile-event
  • queenofsandiego-wynonnamelissa-event
  • queenofsandiego-sarahmclachlan-event
  • queenofsandiego-buddyguy-event
  • queenofsandiego-weirdal-event
  • queenofsandiego-mariachiusa-event

Each bucket is configured for static website hosting with a single index document (index.html). The bucket policy allows CloudFront to read objects via an Origin Access Identity (OAI).

CloudFront Distributions

Each S3 bucket has an associated CloudFront distribution that caches content and terminates SSL/TLS connections. The distribution configuration includes:

  • Origin: S3 bucket with OAI for secure access
  • Viewer protocol policy: Redirect HTTP to HTTPS
  • Default TTL: 86400 seconds (24 hours)
  • Cache behaviors: HTML files cached with shorter TTLs to enable faster updates

After deploying page updates, we invalidate the CloudFront cache using the distribution ID to ensure users see the latest content immediately. For example:

aws cloudfront create-invalidation \
  --distribution-id E1234ABCD5678 \
  --paths "/*"

Key Technical Decisions

Unified Google Apps Script Endpoint

Rather than creating separate GAS projects for each artist, we use a single RadyShellEvents.gs file deployed to Google Apps Script. The script reads a configuration object at the top that maps concert dates to pricing:

const CONCERT_CONFIG = {
  "2024-06-15": { artist: "Bob Dylan", price: 225 },
  "2024-07-10": { artist: "Wynonna & Melissa Etheridge", price: 150 },
  // ... additional concerts
};

This approach meant we only needed to:

  • Deploy the script once to Google Apps Script
  • Update the configuration object as concert details changed
  • Test pricing validation against all 10 concerts

All artist pages POST to the same GAS endpoint URL, passing the concert date as a parameter. The script looks up pricing and validates the request before writing to the Rady Shell events spreadsheet.

CSS Theme Application

We created a reusable pattern for theming. Each artist page includes a