Ungetrimmte Werte werden in die DB geschrieben

Moin :slight_smile:

Mir scheint, als ob ungetrimmte Werte in die DB geschrieben werden, wenn man Adressen speichert.

Ich hatte grad einen Fall, wo ein Kunde seine PLZ mit angehängtem Space speichern konnte und der DPD-Server die Lieferung an die (natürlich falsche) PLZ verweigerte.

Mal abgesehen davon, dass sowohl das DPD-Modul als auch der API-Server sowas abfangen sollte … dürfte es eigentlich gar nicht erst in der Datenbank landen.

[QUOTE=wolkenkrieger;189450]dĂĽrfte es eigentlich gar nicht erst in der Datenbank landen[/QUOTE]

Doch klar. Warum nicht? Postleitzahlen können in verschiedenen Ländern völlig unterschiedlich aussehen. Wenn der Shop im UK in den Einsatz kommt (vor dem Brexit…), muss er auch mit “IM6 SX8” klar kommen.

GruĂź

Ă„hm, Marco? Du weisst, was trimmen bedeutet?

Auch der in GB eingesetzte Shop muss NICHT mit Postleitzahlen klarkommen, die vorne und/oder hinten ein Space in der DB stehen haben … denn exakt das hat bei mir das Problem verursacht: der Kunde kann eine 6stellige Postleitzahl eingeben, die aus 5 Ziffern puls angehängtem Leerzeichen besteht.

Ja kann ich bestätigen. In OXID 4.10.5 habe ich auch teilweise whitespaces bei Vor/Nachname am Ende.
Aber Du kannst sicher ein Modul schreiben, das die Eingaben trimmt. *lach

Sehr ärgerlich, dass das in einem so gereiften Produkt noch passieren kann, ist doch etwas verstörend.

@wolkenkrieger
man könnte auf Basis dieses Projektes ein Modul schreiben, das den Ortsnamen ergänzt wenn PLZ (teilweise) ausgefüllt:
http://rawgit.com/plzTeam/web-snippets/master/plz-suche/index.html

Allerdings sind tpl-Ă„nderungen erforderlich:
z.B. muss das Land [B]vor [/B]der Adresse ausgewählt werden
-> ansonsten würde einem Kunden aus Wien (AT - PLZ 1040) -> Prenzlauer Berg - Berlin angeboten …

Interesse an solch einem Modul?

Moin patch :slight_smile:

Ich weis jetzt nicht, was das mit dem eigentlichen Problem zu tun hat?!

Das ungetrimmte Speichern von Benutzereingaben in die DB ist meiner Meinung nach ein Bug, der ausdrĂĽcklich nicht durch ein Modul zu beheben ist, sondern im Core.

Ich hab heute mit dem Support bei DPD geschrieben - der hat ganz recht damit, wenn er schreibt, dass die API mitnichten dafür zuständig ist, auf die syntaktische Korrektheit der übermittelten Daten zu prüfen. Das hat die sendende Anwendung zu erledigen.

Heisst für mich im Moment: ich muss Hand an das DPD-Modul anlegen, da nicht nur ich im Backend die Meldung bezüglich einer falschen PLZ bekomme, sondern der Kunde bei der Adressprüfung im Bestellvorgang auch (und sich absolut nicht erklären kann, warum seine PLZ falsch sein soll … selbst ich habe zwei Stunden gebraucht, bis mir das Whitespace aufgefallen war!).

[QUOTE=wolkenkrieger;189503]…
Das ungetrimmte Speichern von Benutzereingaben in die DB ist meiner Meinung nach ein Bug, der ausdrĂĽcklich nicht durch ein Modul zu beheben ist, sondern im Core.
…[/QUOTE]
Vollkommen richtig!

i.A wird ja - je nach Land - eine Formatvorgabe fĂĽr die PLZ im Shop vorgegeben - fĂĽr D zB 99999
Im Quelltext sieht das dann so ähnlich aus wie (für D):

<input class=“form-control” type=“text” name=“invadr[oxuser__oxzip]” pattern=“[0-9]{5}”>

und natĂĽrlich muss dieses Format fĂĽr jeder Land spezifisch definiert sein (so macht es zB osCommerce)
Damit werden falsche Zeichen in der PLZ vermieden.

Aber das ist wie ich meine nur die halbe Miete!
-> gleich die richtige PLZ + Ort vorschlagen und in die DB eintragen
-> deshalb das Modul

Aso :slight_smile:

Naja … ob so ein Modul sinnvoll ist, kann ich grad nicht sagen … wenn du Langeweile hast, nur zu^^

Allerdings: ich bin immer wieder einen von denen, die von diesen Ortsvorschlägen anhand der PLZ bisweilen ziemlich genervt ist, weil:

unsere PLZ gehört zu einer Gemeinde, die aus mehreren Ortsteilen besteht und ausgerechnet mein Ortsteil scheint in keiner der gängigen Datenbank zu existieren (das geht sogar soweit, dass meine Wetter-App auf dem Handy nur den Nachbarortsteil auf der anderen Seite der Bundesstrasse kennt) - heisst: ich muss dann immer von Hand mein Ortsteil eintragen. Wenn siech das eintragen lässt, dann ist das ok - ich hatte letzte Woche den Fall, dass es ein read only Feld war :frowning:

In Zeiten von “Formulardaten merken” ala Chrome, Firefox & Co. halte ich ein extra Modul nicht unbedingt für lebenswichtig. Weisst, was ich meine? Nice to have, ja …

Der Bug muss dennoch asap gefixt werden.

http://forum.oxid-esales.com/showthread.php?p=189521#post189521

Das Problem mit der Validierung ist, dass einige Kunden versuchen 12345-D oder - DE oder -AT in die Postleitzahl einzugeben, weil sie es ihr ganzes Leben lang schon so gemacht haben.
Oder Leute aus Dresden, deren Plz mit 0 anfängt, wollen diese 0 weglassen.

Die Validierung muss entweder so gut sein, dass der Kunde erfährt, warum genau die Postleitzahl ungültig ist, sei es zu lang oder zu kurz oder Buchstaben etc. So eine Validierung ist so kompliziert, dass man es nur individuell umsetzen kann.
Sonst weiĂź der Kunde nicht, was der shop will und bricht ab.
Oder eben dem Kunden die Freiheit lassen, die Plz so einzugeben, wie er will.

Ich sehe das so:
Die Aufgabe des Shops ist, möglichst einfach und unkompliziert die Bestellung zu erfassen. Den Kunden zu zwingen, die Eingaben genau so zu machen, wie es einem Versand Dienstleister von vielen in einem Land von vielen passt, gehört dabei eindeutig nicht zu dieser Aufgabe.

DafĂĽr gibt es Adressbereinigung, da kann man fĂĽr paar Cent die Adresse gegen die Datenbank der Post abgleichen und falsch abgekĂĽrzte Ortsnamen etc berichtigen.

Sehe ich anders, vt :slight_smile:

Es geht ja im vorliegenden Fall nicht darum, eine Validierung auf ein gĂĽltiges Format durchzufĂĽhren, sondern schlicht darum, einen Fall abzufangen, der in JEDEM Szenario ein fehler ist.

Es gibt schlicht keine Postleitzahlen etc. die mit einem Whitespace beginnen oder enden. Auf der ganzen Welt nicht. Das ist schlicht und ergreifend ein Fehler. Punkt.

Dein Beispiel mit den -D oder -AT oder der fehlenden Null der Dresdner (btw. ich hab einige von denen in meiner Reallife-Freundesliste … von denen würde keiner auf die Idee kommen, die Null wegzulassen … was kennst du für Leute dort?^^) ist geradezu perfekt gewählt.

In meinem Fall meldet die DPD-API “Eine Zustellung an diese Postleitzahl ist nicht möglich oder falsches Format der Postleitzahl.” - da sollte jeder, der bis 3 zählen kann selber merken, woran es liegen könnte.

Aber: wenn hinter seiner 12345 noch ein Whitespace hängt … guckt der Käufer genauso ungläubig auf die Meldung, wie ich es getan habe. Und das ganz ohne Not - der Fall würde schlicht nie auftreten, wenn der Bug nicht wäre … der Shop kann/muss Whitespaces trimmen - er kann in gar keinen Fall etwas dabei falsch machen und Daten verfälschen.

das mit den whitespaces trimmen sehe ich ja genau so wie du, mein Text war nur auf die erweiterte Validierung bezogen, dass der Shop prĂĽfen soll, ob die PLZ zum Ort passt und PLZ-Format zum Land etc.

Achso … :smiley:

So. Macht nun jemand einen Bug auf dazu?

GruĂź

https://bugs.oxid-esales.com/view.php?id=6693

Ich hoffe, das reicht so.

Bis zum Fix kannst es mit dem Anhang versuchen, getestet, geht. Wegen der genutzten private Methods kein Modul. Den Trimmer kann jemand ja umsetzen, wenn er Lust hat.

[QUOTE=wolkenkrieger;189516]
Ich hoffe, das reicht so.[/QUOTE]

Ja, toll - ist schon acknowledged. Danke!