Fields with showIf dependencies silently not saved when dependency value can't be reconstructed server-side

[adrianbj]

Short description of the issue

A field with a showIf dependency can be silently not saved when editing a page, because ProcessWire re-evaluates the showIf condition server-side during save and—in certain cases—cannot reconstruct the value the browser used to show/hide the field.

When you save a page, a showIf field is pulled out of the normal processing pass (InputfieldWrapper::isProcessable() queues it as a "delayed child") and is only saved if InputfieldForm::processInputShowIf() independently re-derives the condition as true, via selectorMatchesInputfield(). That method reads the dependency field's value to test the condition. This is a completely separate code path from the JavaScript that actually showed/hid the field in the editor, and when the two disagree the dependent field's input is discarded:

if(!$processNow) {
    $child->set('showIfSkipped', true);
    continue;            // processInput() is never called -> value dropped
}

There is no error; isChanged() stays false, so ProcessPageEdit (which only writes changed fields) never saves it. Removing the showIf rule "fixes" it, which is why this looks intermittent.

Expected behavior

A field that was visible (its showIf condition was met in the editor) and edited by the user is saved, regardless of how the dependency field is rendered server-side.

Actual behavior

The dependent field's value is silently discarded—no error, nothing saved—in the two cases below, even though the value is present in the submitted POST data.

The common cases are fine: plain text/checkbox/select dependencies, chained dependencies, and fields nested in fieldsets all re-evaluate correctly server-side. The failures are limited to two situations where the server cannot reconstruct the dependency value:

1. Dependency field not present in the server-side form — it lives in an un-opened AJAX tab (the admin default for multi-tab editing), a conditionally-built form, or was removed. selectorMatchesInputfield() returns null (treated as "no match"), even though the submitted value is available.
2. Dependency present but not processed — it is in a locked or collapsedHidden state, so it retains only its originally-loaded value. If a value was nevertheless submitted for it (e.g. a readonly/hidden mirror input), the server matches the stale loaded value instead of the submitted one.

Optional: Suggestion for a possible fix

Make InputfieldForm::selectorMatchesInputfield() fall back to the actually-submitted value (via $this->getInput()) in both situations, so the server evaluates the same value the browser used. Normally-processed and chained-showIf dependencies are untouched (they keep using their processed/sanitized values). showIf is a UX feature—field editability/access is enforced separately—so deferring to the submitted value here is safe.

// In selectorMatchesInputfield(), wire/modules/Inputfield/InputfieldForm.module

// (1) dependency field not present in the form: fall back to the submitted value
$inputfield = $this->getChildByName($name);
if(!$inputfield) {
    $input = $this->getInput();
    $postValue = $input ? $input->$name : null;
    if($postValue !== null) {
        if(is_array($postValue)) $postValue = implode('|', $postValue);
        return $selector->matches("$postValue");
    }
    if($name != 'collapsed') {
        $this->error("Warning ($debugNote): dependency field '$name' is not present in this form.", Notice::debug);
    }
    return null;
}

$value = $inputfield->attr('value');
$value2 = null;
$matches = false;

// (2) dependency present but in a non-processed (locked/hidden) state: prefer submitted value
static $notProcessedStates = array(
    Inputfield::collapsedHidden,
    Inputfield::collapsedLocked,
    Inputfield::collapsedNoLocked,
    Inputfield::collapsedBlankLocked,
    Inputfield::collapsedYesLocked,
    Inputfield::collapsedTabLocked,
);
if(in_array((int) $inputfield->getSetting('collapsed'), $notProcessedStates, true)) {
    $input = $this->getInput();
    $postValue = $input ? $input->$name : null;
    if($postValue !== null) {
        $value = is_array($postValue) && $subfield !== 'count' ? implode('|', $postValue) : $postValue;
    }
}

Verified on a real install with assertions covering both bug cases plus regressions (text/checkbox/select/chained/nested, multi-value matching, and the .count subfield).

Steps to reproduce the issue

1. Create two fields, e.g. a Page-reference/select/checkbox field dep and a text field sif. Add both to a template.
2. Give sif a visibility dependency: Show this field only if dep=<value>.
3. Put dep on a separate tab in the template (so the admin loads it via AJAX), or set dep's visibility to Locked/Hidden.
4. Edit a page: set dep to the value that makes sif visible, enter a value in sif, and save without opening the tab that contains dep (or with dep locked/hidden).
5. Reload the page edit: sif is empty/unchanged—its value was silently dropped.

Setup/Environment

• ProcessWire version: 3.0.263 (dev); present in current master and earlier versions
• (Optional) PHP version: 8.5

[adrianbj]

@ryancramerdesign - obviously an AI report above, but this is an issue I've had for a very long time. I don't think its description covers are the scenarios. I've had issues with fields not saving when they're on the same tab and not locked/hidden, but maybe the suggested fix will work for my scenario as well. I honestly never figured out exactly what the issue was and also resorted to just removing the showIf condition so I could get things working.

[adrianbj]

Some related issues:
#1889
#1079

[Toutouwai]

I didn't study the whole report in the first post closely so apologies if this isn't what is being suggested, but I wouldn't be in favour of the values of hidden showIf fields being saved. As far as I know, if a populated showIf field is hidden because it fails the showIf condition its value is still present in $input->post, so there has to be some server-side way to ignore the post value and remove any existing saved value.

[adrianbj]

@Toutouwai @ryancramerdesign — good to clarify this, because the fix is narrower than it might read at first.

The change is only to InputfieldForm::selectorMatchesInputfield(), which answers a single question: "is the showIf condition matched (field should be shown)?" The patch doesn't change the save-gating in processInputShowIf() — a field is still processed/saved only when its condition evaluates to true, and when the condition fails it still gets flagged showIfSkipped and is not processed:

if(!$processNow) {            // condition NOT matched
    $child->set('showIfSkipped', true);
    continue;                 // processInput() NOT called → value not saved
}

All the patch does is change which value of the dependency field is used to evaluate that condition: when the dependency field isn't present server-side (un-opened AJAX tab, conditional form) or is present but not processed (locked/hidden), it falls back to the value that was actually submitted — i.e. the same value the browser used to decide show/hide. So it only flips false negatives (field was genuinely shown to the user, but the server misjudged it as hidden and silently dropped the input).

@Toutouwai — I think your concern is about a different path than the one this touches. You're describing the showIf field itself when its condition fails: its value is still in $input->post, and the question is whether the server saves/ignores/clears it. That's the existing showIfSkipped behaviour, which this patch leaves untouched. This change is about the dependency field's value, and it actually pushes things toward client/server consistency (shown→save, hidden→skip, matching the browser) rather than saving hidden fields. No new exposure either — forging a dependency value to force a match was already possible for normally-processed dependencies, and showIf is a UX feature (access/editability is enforced separately).

One honest caveat: the scenario I mentioned earlier — fields not saving when the dependency is on the same tab and not locked/hidden — uses a normally-present, normally-processed dependency, which is a code path this patch does not change. So this likely won't resolve that particular case; it targets the absent-dependency and locked/hidden-dependency divergences specifically. There may be a second root cause behind the same-tab case still worth tracking down (possibly related to #1889 / #1079).

[adrianbj]

@Toutouwai - sorry for the AI reply. I feel guilty every time I post one, but I feel like the pressure to get things done in this era is sending me down this path, even though it's not rewarding and feels very impersonal. We are somewhat losing the human connection of things like the PW forums, Github, StackOverflow etc.

[Toutouwai]

Okay, all good.