Branching funktioniert nicht – Summe > 10 springt nicht zu Abbruch

Question

Ich berechne einen Index aus 11 VHI-Items (V202_01 … V202_11).
Jede Antwort soll um 1 reduziert und in V203_01 … V203_11 gespeichert werden.
Wenn die Summe der recodierten Werte > 10 ist, soll der Fragebogen sofort auf die Seite Abbruch springen.
Stattdessen landet der Pretest immer auf der Standard-Endseite.

PHP-Code

$input  = 'V202';
$output = 'V203';
$items  = getItems($input, 'all');

foreach ($items as $item) {
    $orgCode = value(id($input, $item));
    if ($orgCode > 0) {
        $newCode = $orgCode - 1;
    } else {
        $newCode = $orgCode;          // Missing beibehalten
    }
    put(id($output, $item), $newCode);
}

$sum1 = valueSum('V203', '01-11');

if ($sum1 > 10) {
    return 'go:Abbruch';
}

Setup

•	Seite 4 enthält die 11 Items V202.
•	Seite 5 enthält obigen PHP-Block (zwei getrennte Elemente direkt untereinander) und danach weitere Fragen.
•	Die Variablen V203_01 … V203_11 und V204_01 sind in der Variablenansicht angelegt (V203 = versteckt, numerisch).
•	PHP-Elemente stehen aktuell auf „Beim Seitenaufruf ausführen“.
•	Im Pretest wähle ich überall Code 5 (sollte => 4, Summe 44). Trotzdem keine Weiterleitung.

Fehlersymptom

V203_xx steht nach Seite 5 auf −9 (missing) und V204_01 auf −9.
Es sieht aus, als würde das Re-Coding gar nicht greifen bzw. valueSum() keine Werte finden.

Fragen an die Community

1.	Positionierung: Ist „Beim Seitenaufruf“ der falsche Trigger, weil die Seite noch unbeantwortete Pflichtfelder enthält?
2.	valueSum(): Muss die Funktion nach put() zwingend in ein separates Post-Processing-Element verschoben werden?
3.	Alternative: Würde ein einzelnes PHP im <postprocessing> von Seite 4 das Problem lösen (Recode + Summe + Branching direkt nach dem Klick auf Weiter)?
4.	Sonstige Stolperfallen bei return 'go:Abbruch'; (Groß-/Kleinschreibung, Seitencode, …)?

Vielen Dank für jeden Hinweis!

Comments

Wo haben Sie denn diese Zeilen her?

if ($sum1 > 10) {
    return 'go:Abbruch';
}

Und warum haben Sie oben eine FOR-Schleife verwendet, um Werte umzukodieren?

---

1.    Die fraglichen Zeilen stehen im zweiten PHP-Block direkt auf der Folgeseite zur VHI-Skala (zurzeit „Beim Seitenaufruf“).
2.    Die foreach-Schleife stammt von einem Kollegen; damit werden alle 11 Items generisch verarbeitet, ohne jede Variable einzeln anzusprechen.

Den Routing-Fehler habe ich inzwischen gefunden: Eine deaktivierte Filterfrage (PS34/F1) hat die Seite Abbruch trotz return 'go:Abbruch'; ausgeblendet. Nach Entfernen des Filters funktioniert das Sprungziel wie gewünscht.

Würden Sie den PHP-Block anders oder eleganter formulieren – etwa mit valueTransform() oder einer Ein-Schritt-Lösung ohne separate V203-Variablen? Hinweise zu Performance und Lesbarkeit sind willkommen.

Answer 1

Würden Sie den PHP-Block anders oder eleganter formulieren

Ja, und zwar entsprechend der Anleitung zu valueSum()

if (valueSum('V203', '01-11') > 10) {
  goToPage('Abbruch');
}

Missings behandelt valueSum() automatisch, deshalb ist die Schleife m.E. nicht erforderlich.

Comments

Danke für die Rückmeldung!
Ich verwende die Schleife, weil ich die rekodierten Werte in V203_01 … V203_11 im Datensatz speichern will – also nicht nur zum internen Weiterleiten, sondern auch zur späteren Auswertung.
Deshalb war der Zwischenschritt für mich nötig.
Die verkürzte Variante mit valueSum() ist aber definitiv hilfreich für rein interne Filterlogik – danke für den Hinweis!

---

Vielleicht haben Sie Lust, ein brandneues Feature auszuprobieren. Sehen Sie sich doch mal "Neue Frage" -> Funktionale Bausteine -> "Variablen umkodieren" an.