From 998c38f51956a4825c838425406c50d28e2d8031 Mon Sep 17 00:00:00 2001 From: sebingel Date: Fri, 3 Apr 2026 19:00:43 +0000 Subject: [PATCH] =?UTF-8?q?Fix=20multiEditCore.php:=20align=20isOrdeable?= =?UTF-8?q?=20=E2=86=92=20isOrderable=20with=20JS=20return=20value?= MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit The rename of the elementOptions key from "ordeable" to "orderable" (part of #1584) updated handleElementOptions() in settings_utils.js to return the property as isOrderable. However, multiEditCore.php still destructured the old name isOrdeable from that return value (line 139). Because JavaScript object destructuring resolves properties by name, isOrdeable would silently evaluate to undefined — no runtime error, just a broken binding. The bug was masked because isOrdeable is not referenced after destructuring in the current code of multiEditCore.php. The incorrect binding would become a functional regression as soon as that code path is extended to actually consume the orderable flag (e.g. to conditionally apply select2 sorting in the multi-edit form). Changes: - front/multiEditCore.php:139 — isOrdeable → isOrderable Aligns the destructured property name with the renamed return key of handleElementOptions() so the binding resolves to the correct boolean value instead of undefined. All 35 previously updated files already use the correct spelling; this was the single remaining inconsistency. After this commit, grep for "isOrdeable" and "ordeable" across front/ and server/ returns zero results. --- front/multiEditCore.php | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/front/multiEditCore.php b/front/multiEditCore.php index 4995460f..99be41cb 100755 --- a/front/multiEditCore.php +++ b/front/multiEditCore.php @@ -136,7 +136,7 @@ inputType, readOnly, isMultiSelect, - isOrdeable, + isOrderable, cssClasses, placeholder, suffix,