staging.inyokaproject.org

Hallo, erst mal vielen Dank für die neue Version von Inyoka! (https://ikhaya.ubuntuusers.de/2020/11/05/wartungsarbeiten-am-samstag-7-11-ab-20-uhr/#Update)

Eine Kleinigkeit ist mir aufgefallen. Das Feld Änderungskommentar beim Bearbeiten von Wiki-Artikel hat nun eine clientseitige Validierung (Pflichtfeld). Soweit so gut, allerdings meldet sich dann natürlich auch der Browser, wenn man auf Abbrechen klickt, sprich, das Formular will auch dann einen Änderungskommentar, wenn man gar nichts geändert hat.

 Änderungskommentar: <input type="text" name="note" size="50" required spellcheck="true" maxlength="512" id="id_note" />

Hey,

Danke für die Meldung ich nehme es in den Bugtracker auf ☺

Nehmt euch mal einen Artikel und klickt auf Bearbeiten,

und dann unten auf Abbrechen...

Bei mir moniert er immer wieder ich soll doch einen Titel eingeben... – fürs Abbrechen ???

(Ubuntu Mate, Firefox)

Hej cptechnik,

cptechnik schrieb:

... Bei mir moniert er immer wieder ich soll doch einen Titel eingeben... – fürs Abbrechen ???

stimmt, aber mach 's doch einfach mit "Eine Seite zurück".

Gruß black tencate

Hi!

Ja, scheint ein Fehler in Inyoka zu sein. Ist etwas albern; aber nicht wirklich "schlimm"... Ich schreibe immer "nö" rein, wenn das passiert 😉

so long
hank

Das ist ein bekannter Fehler. Der ist auch im Bugtracker - hat aber sicher keine hohe Priorität.

Das liegt daran, dass der Abbrechen-Button zum selben Formular gehört wie der Speichern-Button. Das das Kommentar-Feld beim Speichern benötigt wird, sollte klar sein. Lösungen könnten IMO sein:

• Kein required-Attribut im HTML, so dass der Browser das Vorhandensein eines Kommentars nicht schon überprüft. Das hat dann ggf. einen zusätzlichen Request zum Server zur Folge, wenn das Feld nicht ausgefüllt wurde. Als Antwort kommt da quasi nur die Fehlermeldung vom Server zurück.

• den Abbrechen-Button komplett entfernen (Browser haben ja die angesprochene Zurück-Taste)

• den lokalen Browsercheck beim Abbrechen per Javascript umgehen

Spontan bin ich ja eher für Abbrechen-Button komplett weg – aber ggf. sehe nur ich das so. Scheinbar wird der Button ja verwendet. ☺

Viele Grüße
Chris

chris34 schrieb:

den lokalen Browsercheck beim Abbrechen per Javascript umgehen

+1

Spontan bin ich ja eher für Abbrechen-Button komplett weg

-1

Hallo,

Scheinbar wird der Button ja verwendet.

Ja, natürlich. Manchmal will / muss man in den Quelltext der Seite schauen, ohne eine Edit zu machen.

Spontan bin ich ja eher für Abbrechen-Button komplett weg

-1

Das akute Risiko, dass ich dabei sehe ist, dass die Leute irgendwelche sinnlosen Edits im Wiki machen (wie ein Leerzeichen dazu oder so), um den Edit zu beenden.

Wie wäre es denn, wenn der Button nicht Teil des Formulars ist und an den Button einfach das (Neu-) Laden der Wikiseite gebunden wird?

Wie was denn früher, also bis zu dem Update geregelt? Da hat's ja funktioniert.

Gruß, noisefloor

noisefloor schrieb:

Wie wäre es denn, wenn der Button nicht Teil des Formulars ist und an den Button einfach das (Neu-) Laden der Wikiseite gebunden wird?

Das wäre in der Tat die beste Lösung. Es könnte auch ein reiner Link sein (<a>), dann darf der Abbrechen-Button auch innerhalb des Formulars sein. Wichtig wäre nur, dass ein "Sind Sie sicher?"-Dialog weiterhin erscheint, wenn der Quelltext vorm Abbrechen editiert wurde, um Frust bei den Autoren zu vermeiden, wenn alle Änderungen weg sind. ☺

Wie was denn früher, also bis zu dem Update geregelt? Da hat's ja funktioniert.

Früher gab's keine clientseitige Validierung, sonder nur serverseitig. Der Server hat dann erkannt, dass "Abbrechen" geklickt wurde und auf einen Änderungskommentar verzichtet ..denk ich mal.

mubuntuHH schrieb:

Es könnte auch ein reiner Link sein (<a>), dann darf der Abbrechen-Button auch innerhalb des Formulars sein.

Wenn es ok ist, dass man immer auf die selbe Seite nach dem Abbrechen kommt, dann ist es IMO das einfachste. (Nebenbei kann man auch auf Servseite die Codelogik für den Abbrechen-Button entfernen)

Wichtig wäre nur, dass ein "Sind Sie sicher?"-Dialog weiterhin erscheint, wenn der Quelltext vorm Abbrechen editiert wurde, um Frust bei den Autoren zu vermeiden, wenn alle Änderungen weg sind. ☺

Das schließt deine Idee mit dem Link nicht aus. Die Meldung erscheint immer, sobald in einem Feld was geändert wurde und man wo anders hin navigiert. (z.B. einfach mal in das Suchfeld etwas eingeben, aber nicht abschicken und dann z.B. vom Wiki zum Portal wechseln.)

noisefloor schrieb:

Wie was denn früher, also bis zu dem Update geregelt? Da hat's ja funktioniert.

Früher gab's keine clientseitige Validierung, sonder nur serverseitig. Der Server hat dann erkannt, dass "Abbrechen" geklickt wurde und auf einen Änderungskommentar verzichtet ..denk ich mal.

Genau.

Viele Grüße
Chris

chris34 schrieb:

mubuntuHH schrieb:

Es könnte auch ein reiner Link sein (<a>), dann darf der Abbrechen-Button auch innerhalb des Formulars sein.

Wenn es ok ist, dass man immer auf die selbe Seite nach dem Abbrechen kommt, dann ist es IMO das einfachste.

Ach so, was ich mit "reinen Link" meinte, ist, dass es kein <button> ist, aber durchaus ein Link mit href-Attribut sein kann. ☺ Als Ziel könnte der Abbruch-Link ja einfach auf den Artikel selbst verweisen. Und wie Du erklärt hast, wird der "Sind Sie sicher?"-Dialog dann immer noch getriggert. Also, genau wie wir's wollen, nicht?

mubuntuHH schrieb:

Als Ziel könnte der Abbruch-Link ja einfach auf den Artikel selbst verweisen.

Joa, auf den Artikel verweisen, ist kein Problem. Auf die zuletzt besuchte Seite zurückgehen, geht damit halt aber z.B. nicht (theoretisch kann man ja auch ersten den Artikel-Log besuchen und ihn dann bearbeiten). Eine Meldung wie „Bearbeiten abgebrochen“ erscheint mit einem Abbruch-Link halt auch nicht.

Also, genau wie wir's wollen, nicht?

Subjektiv muss ich da erst noch Details fragen. 😀

Viele Grüße
Chris

chris34 schrieb:

Auf die zuletzt besuchte Seite zurückgehen, geht damit halt aber z.B. nicht(theoretisch kann man ja auch ersten den Artikel-Log besuchen und ihn dann bearbeiten).

Stimmt, aber ich glaube, es würde niemanden nachhaltig verwirren, wenn er (immer) auf die Artikel-Seite gelangt, wenn er "Abbruch" klickt. ☺

Eine Meldung wie „Bearbeiten abgebrochen“ erscheint mit einem Abbruch-Link halt auch nicht.

Daran habe ich gar nicht gedacht, irgendwas ist ja immer. 🙄 Ich weiß nicht, ob die Sicherheitsexperten jetzt die Hände über den Kopf schlagen (XSS-Gefahr?), aber man konnte dem Link ja einen GET-Parameter mitgeben, z.B. aborted=true oder so. Aber jetzt wird's langsam doch eine größere Sache, als ich zunächst dachte...

Subjektiv muss ich da erst noch Details fragen. 😀

Wen fragen?

mubuntuHH schrieb:

Daran habe ich gar nicht gedacht, irgendwas ist ja immer. 🙄 Ich weiß nicht, ob die Sicherheitsexperten jetzt die Hände über den Kopf schlagen (XSS-Gefahr?), aber man konnte dem Link ja einen GET-Parameter mitgeben, z.B. aborted=true oder so. Aber jetzt wird's langsam doch eine größere Sache, als ich zunächst dachte...

Im Django-Umfeld sind GET-Parameter generell eher ungewöhnlich, da würde man sowas eher mit POST lösen. Ein Formular ist in diesem Fall ja auch da.

Bei einer Meldung ist IMO halt die Frage, ob es die Meldung überhaupt braucht: Auf eine andere Seite gelangt man durch das Anklicken von einem Abbrechen-Link sowieso. Beim Zurück-Button in einem Browser bekommt man ja auch nicht immer eine Meldung darüber.

Subjektiv muss ich da erst noch Details fragen. 😀

Wen fragen?

Ich meinte hier in diesem Thread Details besprechen. „Diskutieren“ wäre wohl auch ein besseres Wort gewesen…

Viele Grüße
Chris