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.
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.
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
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.
Before handing off the site, the long-term maintenance strategy for these pages needs to be resolved. Options include:
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.
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.
| Concern | Language | Reason |
|---|---|---|
| Conditional content rendering | JavaScript | Frontend DOM manipulation |
| WooCommerce/Bookly payment hooks | PHP | WordPress backend hook system |
| Square API tokenization | PHP | Server-side backend integration |