Deploying Themed Event Pages with Booking Modals: Queen of San Diego Rady Shell Summer Concert Series
What Was Done
We expanded the Queen of San Diego events infrastructure to support six additional Rady Shell summer concerts by creating individually themed artist pages with integrated booking modals. The project involved:
- Analyzing existing event page architecture and identifying the missing artists from the summer lineup
- Building six new themed HTML pages with artist-specific CSS styling
- Implementing a shared booking modal component across all pages
- Provisioning six new AWS CloudFront distributions with ACM SSL certificates
- Deploying six new subdomains via Route53 DNS configuration
- Wiring all call-to-action buttons to trigger the booking modal
- Validating all infrastructure changes across staging and production environments
Technical Details: Page Architecture and Theming
The existing event infrastructure at /Users/cb/Documents/repos/sites/queenofsandiego.com/ already contained a successful pattern with pages for Bob Dylan, Paul Simon, Kool and the Gang, Gypsy Kings, and Brandi Carlile. We analyzed the Bob Dylan page structure to establish our baseline template, examining both the header styling and the booking modal pattern.
Each themed page follows this structure:
<!DOCTYPE html>
<html lang="en">
<head>
<meta charset="UTF-8">
<meta name="viewport" content="width=device-width, initial-scale=1.0">
<title>[Artist Name] | Queen of San Diego</title>
<link rel="stylesheet" href="/styles/artist-theme.css">
<link rel="stylesheet" href="/styles/booking-modal.css">
</head>
<body class="artist-[slugified-name]">
<!-- Artist-specific header with themed colors/imagery -->
<!-- Content sections -->
<!-- Multiple CTA buttons with data-action="book" -->
<!-- Shared booking modal component -->
</body>
</html>
The critical decision was using a scoped CSS approach with class-based theming rather than inline styles. This allowed us to:
- Maintain a single
booking-modal.cssfile that works across all pages - Use artist-specific CSS files (
wynonnamelissa.css,sarahmclachlan.css, etc.) for color schemes, typography, and imagery - Minimize file size and maximize maintainability across the entire event site
The six new pages created were for: Wynonna Melissa, Sarah McLachlan, Buddy Guy, Weird Al Yankovic, Mariachi USA, and Bonnie Raitt. Each page was created at the site root: /Users/cb/Documents/repos/sites/queenofsandiego.com/wynonnamelissa.html, /Users/cb/Documents/repos/sites/queenofsandiego.com/sarahmclachlan.html, etc.
Booking Modal Implementation
Rather than duplicating modal code across six pages, we implemented a shared modal pattern with JavaScript event delegation. All CTA buttons across the site use a consistent data attribute:
<button class="cta-button" data-action="book">
Reserve Your Seats
</button>
A single JavaScript listener detects any element with data-action="book" and triggers the modal. We verified this pattern by checking existing pages for stale href="#book" links and updating them to use the data attribute pattern.
The modal component includes:
- Smooth fade-in/fade-out animations via CSS transitions
- Click-outside-to-close functionality
- Mobile-responsive overlay sizing
- Accessibility features (ARIA labels, focus management)
Infrastructure: CloudFront, ACM, and Route53
Each artist page required its own subdomain to maintain clean URL structure and enable independent caching strategies. We provisioned six new CloudFront distributions through the AWS console, each pointing to the S3 bucket queenofsandiego.com with origin path /events/.
The naming convention used was straightforward: wynonnamelissa.queenofsandiego.com, sarahmclachlan.queenofsandiego.com, etc. Each distribution was configured with:
- Default root object:
index.html - Compress objects automatically (gzip/brotli for CSS/JS)
- TTL settings: 86400 seconds (24 hours) for HTML, 31536000 seconds (1 year) for versioned assets
- Custom error pages pointing to the main events page
We encountered and resolved an SSL certificate issue: an accidental pending certificate was created during exploration and had to be deleted before proceeding with the wildcard certificate approach. The final configuration uses a single wildcard ACM certificate (*.queenofsandiego.com) rather than individual certificates per subdomain, reducing certificate management overhead.
DNS configuration in Route53 followed this pattern for each subdomain:
Record Name: wynonnamelissa.queenofsandiego.com
Record Type: A (Alias)
Alias Target: d1234567890abc.cloudfront.net
Routing Policy: Simple
Evaluate Target Health: Yes
The same pattern was repeated for all six new subdomains. Route53 alias records were chosen over CNAME records because they avoid the DNS complexity of having CNAME at the zone apex.
Deployment Strategy
We used the existing publish_static_site.sh deployment script located at /Users/cb/Documents/repos/sites/queenofsandiego.com/scripts/publish_static_site.sh. This script:
- Syncs the local site directory to the S3 bucket with appropriate metadata
- Invalidates CloudFront cache using distribution IDs
- Verifies AWS credentials from environment configuration
- Handles both staging and production deployments
Each subdomain deployment followed this sequence:
- Deploy the HTML file to S3 at
s3://queenofsandiego.com/events/[artist-slug]/index.html - Deploy associated CSS assets to
s3://queenofsandiego.com/assets/[artist-slug]/ - Invalidate the CloudFront distribution for that subdomain
- Validate the live subdomain was responding with correct content
- Verify the booking modal was wired and functional
Staging deployment was performed first to staging-events.html in the S3 bucket, allowing validation of all six pages in a pre-production environment before live release.
Key Decisions and Rationale
Subdomain per Artist vs.