v1.0.3

• Added: "View details" link on the Plugins page opening a modal with Description, Installation, FAQ, and Changelog tabs parsed from README.md.
• Added: "Requires Gravity Forms" line in the plugin details sidebar.

v1.0.2

• Fixed: Fatal error when does NOT contain operator receives a null field value (e.g. unsubmitted radio/checkbox fields evaluated during gform_pre_render).

v1.0.1

• Fix: Bottom border on the active accordion was missing when either the "Advanced Conditional Logic" or the native "Conditional Logic" accordion was selected.

v1.0.0

• Breaking: Removed in CSV and not in CSV operators. The same logic can be expressed with multiple OR groups using the standard is / is not operators. Existing saved rules using these operators will be silently ignored.

• Architecture: Frontend evaluation now delegates per-rule matching to Gravity Forms' native gf_get_field_action() engine. IfOnly only adds the OR-of-groups layer on top. This aligns with the approach from David Smith's original snippet and ensures third-party operators registered via GF hooks work inside IfOnly groups.

• Improvement: The does NOT contain operator implementation now mirrors the Gravity Wiz reference approach: whitelisted via gform_is_valid_conditional_logic_operator, evaluated server-side via gform_is_value_match, and uses jQuery-based field value reading on the frontend.

v0.9.9

• Fix: Frontend field visibility was broken — fields with IfOnly logic remained hidden even when the user selected matching values. Root cause: GF renders radio button choices inside a <ul id="input_FORMID_FIELDID"> container; getFieldValue() found this <ul> via getElementById and tried to read .value on it (which is undefined), so radio field values always evaluated as empty. Fixed by checking the element's tag name and only reading .value from actual form elements (input, select, textarea).
• Fix: On initial page load, IfOnly fields could have the wrong visibility state because GF's conditional logic init script evaluates rules before the IfOnly filter is registered. A re-evaluation is now triggered immediately after filter registration.

v0.9.8

• Fix: Changing the field dropdown in an IfOnly rule to a choice-based field (radio, select, etc.) displayed the first choice in the value dropdown, but the underlying state kept an empty string — so the saved rule targeted "" instead of the visible choice. Root cause: after re-rendering, the browser auto-selects the first of the new , but no change event fires, leaving the state stale. Both the settings-page and form-editor scripts now sync state from the actual DOM values after every re-render. Fix: IfOnly-enabled confirmations were always displayed regardless of whether conditions were met. Root cause: clearing native conditionalLogic (v0.9.6) caused GF's update_confirmation() to evaluate null logic as "always true," selecting the IfOnly confirmation before the gform_confirmation filter ran. The old maybe_override_confirmation() could only add a confirmation, never reject one GF already picked. Rewritten to (a) detect when GF wrongly selected an IfOnly confirmation whose conditions are not met and fall back to the default, (b) properly handle both message and redirect confirmation types via a new format_confirmation() helper. Fix: Native Conditional Logic and IfOnly could both be active simultaneously on the same notification or confirmation, causing unpredictable behavior (native CL is evaluated first by GF and can silently override IfOnly). When IfOnly is enabled, native CL is now automatically hidden and disabled on the settings page. On save, native conditionalLogic data is cleared to prevent server-side conflicts.

v0.9.5

• Fix: Notifications were still sent even when IfOnly conditions were not met. Root cause: the gform_notification filter fires inside GFCommon::send_notification(), but Gravity Forms does not re-check isActive after the filter — the email proceeds regardless. Replaced the isActive = false approach with a two-hook strategy: gform_notification now flags the notification (ifonly_suppress), and a new gform_pre_send_email callback sets abort_email = true for flagged notifications, which is the documented GF mechanism to cancel delivery.

• Fix: On notification and confirmation settings pages, IfOnly rules appeared to be lost after clicking the save button (they were actually saved — a page refresh showed them correctly). Root cause: GF's settings framework builds the field HTML before running process_postback(), and for existing items it does not redirect after save, so the rendered page contained stale data. The POST fallback now always reads from $_POST on a save postback instead of only when $ifonly was empty.

• Fix: The delete (−) button was missing on the sole rule of a group when multiple groups existed, making it impossible to remove an entire group. The button is now shown whenever deletion is meaningful: when the group has more than one rule, or when there is more than one group.

• Fix: Translated operator labels containing apostrophes (e.g. French "n'est pas") were rendered as HTML entities (') in the rule editor dropdowns. Replaced esc_html__() with __() for all strings serialized into the JavaScript configuration object — HTML-escaping is inappropriate for values passed through wp_json_encode().

v0.9.1

• Fix: After saving the form with the Advanced Logic flyout open, the rule groups were visually cleared (rules disappeared). Groups are now correctly re-rendered when loadField() is called while the flyout is already open.

v0.9.0

• Initial public release
• New: Grouped conditional logic (AND within groups, OR between groups)
• New: Support for fields, Next button, Submit button, confirmations, and notifications
• New: Extra operators: does NOT contain, in CSV, not in CSV
• New: Server-side logic re-evaluation during submission
• New: GitHub auto-update support
• New: French translation