Dynamic Product Pages — Custom JavaScript Implementation

Overview

Some WordPress product pages use custom JavaScript to conditionally render different content — images, descriptive text, pricing, and call-to-action links — based on which variation button a user selects. This approach keeps all service variations under a single URL rather than creating separate pages per variant.

This pattern was identified and discussed during a ^[1] technical review. The Vampire Facial product page is the primary example: three variation buttons each trigger a distinct set of rendered content without changing the URL.

How It Works

Single URL (e.g., /vampire-facial)
│
├── Button A selected → render Image A + Text A + Book Now link A
├── Button B selected → render Image B + Text B + Book Now link B
└── Button C selected → render Image C + Text C + Book Now link C

The JavaScript listens for button click events and conditionally swaps:
- Hero/product image
- Descriptive text / procedure info
- Price display
- "Book Now" button onclick target (redirects to the appropriate booking flow)

The code is embedded via Elementor templates (accessible through Edit with Elementor on the single product page). It is not a standard WooCommerce product variation — it is fully custom scripting layered on top of the page builder.

Key Implications

Updates Require a Developer

This is not a drag-and-drop WordPress edit. Because content is conditionally rendered by JavaScript logic, any change to copy, images, or booking links requires modifying the underlying script. A non-technical user cannot safely update these pages through the WordPress admin UI alone.

"This is not, we tell Roxy, oh yeah, click these three buttons and you can update this text, no problem. This is a developer that is modifying code in order to update things."
— Kimberly Gehrmann, technical review call

Adding New Variations = Code Change

Duplicating a product page and adding a new variation button is not a self-service operation. Each new variation requires a corresponding branch in the JavaScript conditional logic.

Maintenance Ownership Must Be Defined

Before handing off the site, the long-term maintenance strategy for these pages needs to be resolved. Options include:

1. Keep custom JS, developer-maintained — acceptable if a developer remains engaged post-launch
2. Refactor to standard WooCommerce variations — more maintainable by non-developers, but requires rework
3. Rebuild with a no-code-friendly pattern — e.g., separate URLs per variation, or an Elementor dynamic content approach

Where to Find the Code

1. Log into WordPress admin
2. Navigate to the product page (e.g., search "Vampire Facial" in Pages or via the front-end admin bar)
3. Click Edit with Elementor
4. Locate the custom HTML / JavaScript widget within the Elementor template

Note: Cloudflare caching on the staging environment can interfere with loading the Elementor editor. Retry or temporarily bypass cache if the editor fails to load.

PHP vs. JavaScript Split

On these product pages, the rendering logic is JavaScript (frontend). This is distinct from the payment and booking integration work, which requires PHP for backend WordPress/WooCommerce hooks. See ^[2] for that context.

Action Items (as of 2026-04-05)

• [ ] Kimberly Gehrmann — Review the variation page JavaScript via Elementor; email Isahaque/Melissa if blocked
• [ ] Melissa Cusumano — Hold off on product page content updates until Kimberly's code review is complete
• [ ] Team — Decide on long-term maintenance strategy before site handoff

Related

• ^[3]
• ^[4]
• ^[2]
• ^[5]