Legacy Conditions Script leaves matched conditional fields hidden

Summary

Conditional fields configured with a Show rule can remain visually hidden after their condition matches when Legacy Conditions Script is enabled. A matching condition is expected to reveal the dependent field, but the field remains unavailable on the product form. Stores using this mode can lose access to product options and their associated selections or pricing.

Customer context

Product / area: PPOM for WooCommerce, frontend conditional fields
Version: Reported after updating from 33.0.14 to PPOM 34.x; confirmed in source through 34.0.8. PPOM Pro 27.0.4 was active.
Environment: WordPress 7.0.2, WooCommerce 10.9.4, PHP 7.4.33, Polish locale, Astra child theme
Integration / third party: PPOM Pro depends on the free PPOM condition engine
Reported error / symptom: Conditional checkbox and option fields disappear from product pages after updating
Impact: Affected product options cannot be selected while the legacy condition mode is active.

Reproduction notes

Reported and source-derived flow:

1. Enable PPOM Settings > Legacy Conditions Script.
2. Assign a PPOM group containing a dependent option field with a conditional Show rule to a product.
3. Use PPOM v33.0.15 or a later inspected release such as v34.0.8.
4. Open the product page and select the controlling value that satisfies the rule.
5. Observe that the dependent field remains visually hidden instead of becoming available.

Support reproduced the affected configuration on staging and confirmed that switching to the current conditions engine restored the fields. No local runtime reproduction was performed during repository inspection.

Diagnosis

Conclusion

The defect is confirmed by the reported staging behavior and a direct mismatch in the inspected source. Fields governed by a Show condition begin with ppom-c-hide. When a legacy condition matches, the legacy script calls .show() and changes lock-state classes but leaves ppom-c-hide in place. Current CSS hides that class through visibility, absolute positioning, and zero height, so changing display does not restore the field's visible layout.

Where this likely occurs

• Frontend product option conditional visibility in the free PPOM repository; PPOM Pro uses this dependency rather than a separate condition engine.
• backend/options.php — PPOM settings definition approx. lines 60–64, ppom_new_conditions, exposes the Legacy Conditions Script mode.
• src/Frontend/PpomFilterHooks.php — PpomFilterHooks::register() lines 26–31 routes legacy mode through ppom_hooks_input_wrapper_class.
• src/Hooks/Callbacks.php — Callbacks::input_wrapper_class() lines 798–827 adds ppom-c-hide to fields using a Show condition.
• js/ppom-conditions.js — ppom_unlock_field_from_condition() lines 285–307 reveals a matched field through .show() and lock-state classes without removing ppom-c-hide.
• css/ppom-style.css — conditional visibility rules lines 208–218 define ppom-c-hide with visibility: hidden, position: absolute, and height: 0.
• js/ppom-conditions-v2.js — ppom_check_conditions() approx. lines 416–483 explicitly adds and removes ppom-c-hide, showing that the current engine follows a different class contract.
• Commit 9d901d6a79176eedbacc7b4847038c463a3d1fc6 changed ppom-c-hide from display: none to the current three-property hiding rule. Git tag containment places the change in v33.0.15 and all inspected tags through v34.0.8; v33.0.14 predates it.

Engineering notes

The inspected failure is limited to the optional legacy conditions engine. The current v2 engine directly manages ppom-c-hide, and disabling the legacy setting restored conditional fields in the reported staging and live workflows. The Pro add-on uses the free plugin's wrapper filters and condition assets, so the defect routes to the free repository even when Pro fields are present. The source history indicates the compatibility break began in 33.0.15 rather than specifically in 34.x.

Test coverage status

tests/e2e/specs/conditions.spec.js, particularly the Conditions suite around lines 44–103, covers a Show condition becoming visible under the default condition mode. ppom-pro/tests/e2e/specs/conditions.spec.js lines 14–74 covers a similar Pro-enabled flow. Neither inspected suite enables ppom_new_conditions or exercises Legacy Conditions Script, so they miss this path. No relevant legacy-mode coverage was found during inspection, and tests were not executed as part of this read-only triage.

What to verify or explore next

• May be worth reproducing the minimal Show condition flow with Legacy Conditions Script enabled on v33.0.14, v33.0.15, and v34.0.8 to confirm the source-derived version boundary.
• If reproducible, checking the existing Playwright condition suites in both free-only and Pro-enabled environments could establish the affected field-type range.
• Compatibility checks may include both Show and Hide rules, All and Any bindings, and nested dependent conditions.

Unknowns / follow-up

The ticket demonstrates affected conditional checkboxes and option fields on one environment. The full range of field types and condition operators affected has not been established by runtime testing.

Confidence

Confidence: 97/100

Direct repository inspection confirms that the legacy conditions engine leaves the active hiding class on matched fields, while the newer engine removes it. The separate Select-image report is not treated as a product defect because native Select rendering has no image option contract and the customer independently reported finding that problem.

---

Source: HelpScout #3394421742
Generated by bug-report-triage (ID: bug-report-triage_6a7590a58769d5.98809969)