[3.3] [CDB] LF who was here 2 (Wer war da?)

[LukeWCS]

2.1.3 wurde gestern in der CDB freigegeben, keinerlei Beanstandungen.

[LukeWCS]

Update 2.1.4 auf GitHub veröffentlicht.

Ich bedanke mich bei Kirk für Rückmeldungen, Verbesserungsvorschläge und Fehlerberichte.

Ein besonderer Dank geht ebenfalls an Kirk für seine Toggle-Lösung welches bereits in 3 meiner Exts implementiert wurde. Ich habe das Toggle CSS in angepasster Form von seinem Style Changer übernommen und gemeinsam haben wir das CSS weiter optimiert und standardisiert, damit das auch von anderen Ext Codern bei Bedarf problemlos in eigene Exts integriert werden kann. In diesem Zusammenhang auch Danke an chris1278, Scanialady und Mike-on-Tour für Rückmeldungen bez. den Toogles.

Details wie immer im Changelog.

[IMC]

Sehr schöner Togglebutton.

Etwas durchgängiger wäre es wenn die inaktiven Eingabeelement nicht nur mit opacity kenntlich gemacht werden, sondern auch mit dem Attribut disabled außer Funktion gesetzt würden.

[LukeWCS]

Hi Thorsten

Wegen Toggle, ich sag mal Danke als Udo&Patrick.

Wegen Disable: Das war eine bewusste Design-Entscheidung. Mit der Abblend-Funktion will ich dem Admin nur signalisieren, dass abgeblendete Einstellungen "gerade" keine Relevanz haben. Ich will/muss ihn jedoch nicht zwingend davon abhalten, die abgeblendeten Einstellungen weiterhin ändern zu können.

Es gibt aber noch einen wesentlich besseren Grund, warum ich nicht deaktiviere: Form-Controls mit der Eigenschaft disabled haben eine tückische/fiese Nebenwirkung: sie werden vom Browser beim Abschicken des Formulars schlicht als nicht-existent behandelt und werden somit gar nicht in den POST Request gepackt. Genau das ist mir vor Jahren schon mal zum Verhängnis geworden und es hat ne Weile gebraucht, bis ich rausfand, warum plötzlich etliche Einstellungen meiner Ext komplett gelöscht waren.

Das kann man zwar handhaben, braucht dafür aber entweder zusätzlichen JS Code der den Submit abfängt und alle Controls vorher aktiviert (brrrrr ^^), oder aber man muss den Request Code im Modul enstprechend anpassen. Macht man das nicht, löscht man sich effektiv Einstellungen in der Ext. Probiers mal in einer deiner Exts aus. Setz einfach mal per Dev Tools im Browser bei einem Control die Eigenschaft disabled und schick das Formular ab. Ich würde das aber nur mit einem Control testen, wo du nicht gerade irgendwelchen Text hinterlegen kannst, weil der ist dann weg. Nimm also was, was dir nicht weh tut wenns weg ist.

In jedem Fall aber, ist der Aufwand im Code höher wenn man deaktiviert und das Risiko das was schiefgeht ebenfalls. Ergo: ist die Sache nicht wert.

[IMC]

Da habe ich wieder etwas dazu gelernt. Danke!

In der Tat habe ich eine Extension in der ich Radiobutton deaktiviere. Das von dir beschriebene Problem ist mir nie aufgefallen da in dem Zustand von dem Formular der Defaultwert übertragen werden soll. Eben der Wert, der im PHP Code gesetzt wird wenn über den POST Request nichts ankommt.

Um sauber zu sein aktiviere ich jetzt die Radiobutton mit dem onSubmit Event. Optisch gefällt mir das jedoch nicht, da man beim Senden des Formulars sieht, dass die Button aktiv werden. Dazu werde ich aber noch eine Lösung finden.

[LukeWCS]

Das von dir beschriebene Problem ist mir nie aufgefallen da in dem Zustand von dem Formular der Defaultwert übertragen werden soll. Eben der Wert, der im PHP Code gesetzt wird wenn über den POST Request nichts ankommt.

Eben. Und so wird aus einer Einstellung die vorher auf "Ja" war, ein "Nein", sofern das der Standardwert ist den du definiert hast UND der Ja-Radio Button ausgewählt UND deaktiviert war. Böse Falle. Und je nachdem wie du deinen Request Code verdrahtet hast, kann es dir passieren, dass du dann im Formular bei der betreffenden Ja/Nein Einstellung gar nichts mehr hast, wenn das Formular wieder aufgerufen wird. Es ist dann also weder Ja noch Nein ausgewählt. Noch böser, weil das dann für den Admin wie "kaputt" aussieht.

Um sauber zu sein aktiviere ich jetzt die Radiobutton mit dem onSubmit Event. Optisch gefällt mir das jedoch nicht, da man beim Senden des Formulars sieht, dass die Button aktiv werden.

Deswegen meinte ich ja "brrrrr" ^^. Ist gar nicht nötig mit JS solch "abenteuerliche" Aktionen durchzuführen. Guckst du:

https://area51.phpbb.com/docs/code/3.3. ... s_set_post

Damit kannst sauber abfragen, ob ein Element im POST Paket vorhanden ist oder nicht. Und das nimmst dann als Bedingung für die Speicherung der Einstellung. Sprich, wenn das false liefert, speicherst du die Einstellung schlicht nicht. Auf diese Weise kannst deaktivierte Controls verwenden und bist trotzdem auf der sicheren Seite. Den Tipp hatte ich Udo mal gegeben, guck dir seine Sidebar Ext an, da hast dann ein Beispiel.

Aber wie gesagt, das ist eben zusätzlicher Aufwand und zumindest bei LFWWH nicht nötig. Wenn bei abgeblendeten Einstellungen etwas geändert wird, hat das keinerlei Auswirkung. Also besteht auch kein Grund das sperren zu müssen.

[IMC]

Damit kannst sauber abfragen, ob ein Element im POST Paket vorhanden ist oder nicht.

Habe ich eingefügt. Funktioniert sehr gut. Danke für den Tipp.

[LukeWCS]

Funktioniert sehr gut. Danke für den Tipp.

Gerne, so pusht man sich gegenseitig. Dein Fund im phpBB Source bezüglich erweitertem Rückgabewert bei is_enableable() hat mich auch weiter gebracht und speziell bei EMP dafür gesorgt, dass das wieder ein Stück besser wurde. Darüberhinaus hat die Erkenntnis ja auch schon die Runde gemacht, weil es hier und da schon genutzt wird, also auch ausserhalb von deinen oder meinen Exts.

[LukeWCS]

2.1.4 wurde gestern in der CDB freigegeben, keine Beanstandungen.

[LukeWCS]

Version 2.1.5 online

Freigegeben für PHP 8.2, Details im Changelog.