WooCommerce Badge Stacking & Lazy-Load Fix

Client: ^[1]
Status: Partially resolved — z-index stacking fixed; lazy-load bug in progress

Overview

The Flynn WooCommerce store uses the Product Labels for WooCommerce plugin to display two custom badges on product cards:

• "Open Box" — applied to products in the Open Box category (client cannot list these as "Sale" with vendors)
• "Sale" — applied automatically to any product with a reduced price

The client had self-edited badge settings, breaking the configuration. This session resolved the badge stacking order but surfaced a separate lazy-loading bug that remains open.

Issue 1: Incorrect Badge Stacking Order (Resolved)

Problem

Both badges were positioned at the same location (top-left). The "Sale" badge was rendering on top of the "Open Box" badge. The client's requirement was the opposite — "Open Box" should always be visible on top when both apply.

Root Cause

The two badges use different badge types (standard vs. advanced/CSS badges), which means they render in separate absolutely-positioned containers. Because they occupy the same stacking context independently, a simple CSS z-index set on one badge does not automatically override the other.

The "Sale" badge had a default z-index of 99. The "Open Box" badge had no explicit z-index, so it rendered beneath.

Resolution

In the Product Labels for WooCommerce plugin settings:

1. Set the "Open Box" badge z-index to 10
2. Set the "Sale" badge z-index to 5

This forces "Open Box" to render on top when both badges are present on the same product card.

Note: The AI diagnostic confirmed that z-index only works reliably here when both badges share the same stacking context. The fix works in practice but may be fragile if the plugin updates its rendering approach. A custom CSS or MU plugin override may be more robust long-term.

Product List Configuration

The "Open Box" badge is applied via a Product List rule in the plugin:

• List Name: Open Box
• Taxonomy: Category → Open Box

This ensures the badge applies to all products assigned to the Open Box category without manual per-product selection.

Issue 2: Badges Not Appearing on Filtered Pages (Unresolved)

Problem

When a user selects a category filter on the shop page (e.g., clicking "Open Box" in the sidebar), badges do not appear on the filtered product cards. They only appear after the user manually refreshes the browser. Badges also do not appear on individual product pages.

Root Cause (Diagnosed)

The badges are injected via JavaScript after the initial page load — they are not present in the server-rendered HTML. This conflicts with WP Rocket's caching layer:

• WP Rocket serves a cached HTML snapshot that does not include the badge markup
• When the shop page re-renders product cards via AJAX (on filter selection), the badge injection script either runs late or not at all
• A hard browser refresh forces a full page load, which triggers the badge JS correctly

This was confirmed by inspecting the raw HTML response — badge elements were absent from the initial document.

Status: In Progress

Mark is using an AI assistant to generate a custom Must Use (MU) plugin to address this. The likely approach is a MutationObserver that watches for dynamically injected product card elements and re-triggers badge rendering after AJAX filter updates.

Next step: ^[1] — Mark to complete and deploy MU plugin.

Additional Context: Client Self-Editing Risk

The original badge configuration was broken by the client editing plugin settings directly in WordPress. Flynn's client contact is technically confident enough to navigate the admin UI but not enough to understand downstream effects.

Recommendation: Communicate clearly that self-edits to badge/plugin settings require agency involvement to diagnose and repair. Each incident of this type has cost ~1 hour of debugging time.

Action Items

• [ ] Complete MU plugin with MutationObserver to fix badge visibility on filtered pages (@Mark Hope)
• [ ] Verify "Open Box" badge renders correctly on individual product pages (@Mark Hope)
• [ ] Communicate client self-editing policy to Flynn contact (@Mark Hope / @Karly Oykhman)

Related

• ^[2] (create if generalizing this fix)
• ^[1]