LaMarie Service Page JavaScript Customization — Maintenance Risk

Overview

Service pages on the La Marie Beauty WordPress site (e.g., the Vampire Facial page) use custom JavaScript to conditionally render content based on user button selection. While this achieves the desired UX — multiple service variants under a single URL — it creates a significant maintenance bottleneck: content updates require a developer, not a content editor.

This pattern is worth documenting as a general WordPress risk: when front-end interactivity is implemented via custom JS embedded in Elementor templates, the site's content model effectively becomes code-dependent.

How It Works

The Vampire Facial page presents multiple service variants (e.g., different treatment tiers or add-ons) via a set of buttons. When a user clicks a button, JavaScript:

1. Swaps the displayed image to match the selected variant
2. Replaces descriptive text (price, procedure info) with variant-specific content
3. Redirects the "Book Now" button to the appropriate Bookly/WooCommerce booking destination

The URL does not change between variants — all variants live under a single page slug (e.g., /vampire-facial). The conditional logic follows a pattern like:

if button A selected → render image A, text A, booking link A
else if button B selected → render image B, text B, booking link B
else → render image C, text C, booking link C

The code is accessible via Elementor → Edit Page → Custom JS on the relevant product/service page template.

The Maintenance Problem

Standard WordPress content editing (drag-and-drop, inline text editing, image swaps via media library) does not apply to content managed by this JavaScript. To update any variant's image, copy, or booking destination, someone must:

• Locate the custom JS block in Elementor
• Understand the conditional structure
• Edit the correct string or URL within the code
• Test that no other variants broke

This is a developer task, not an editor task. Roxana Lopez (LMB's internal ops contact) cannot self-serve these updates via the WordPress admin UI as she would for standard page content.

Scalability Concern

Adding a new service variant to an existing page — or building a new service page with the same pattern — requires duplicating and modifying the JS block. There is no templated or CMS-driven way to do this without touching code.

"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, project lead (client-side)

Current Status (as of meeting)

• Custom JS for the Vampire Facial page variants is already written by Isahaque Mahmud (Asymmetric developer)
• Kimberly Gehrmann has been granted WordPress staging site access to review the code
• No new process for managing these updates has been defined yet
• Kimberly intends to assess complexity before determining whether LMB can self-maintain, requires ongoing Asymmetric retainer work, or needs a different architectural approach

Action Items

Architectural Alternatives to Consider

If this pattern is used across many service pages, the following approaches could reduce the developer dependency:

• ACF (Advanced Custom Fields) + PHP template: Store variant data (image, text, booking URL) as structured field groups; render conditionally via template logic. Editors update fields, not code.
• WooCommerce product variations: If variants map cleanly to WooCommerce product attributes, native variation handling may replace the custom JS.
• Separate pages per variant: Simpler to maintain individually; loses the single-URL UX but makes content editing trivial.

Each option involves trade-offs in scope, rebuild cost, and UX. The right choice depends on how many pages use this pattern and LMB's long-term content management capacity.

Related

• ^[1]
• ^[2]
• ^[3]