Neuigkeiten
  • Die modified eCommerce Shopsoftware ist kostenlos, aber nicht umsonst.
    Spenden
  • Damit wir die modified eCommerce Shopsoftware auch zukünftig kostenlos anbieten können:
    Spenden
  • Thema: Vermischte Bestellungen [kritisch]

    web0null

    • Experte
    • Beiträge: 1.998
    Re: Vermischte Bestellungen [kritisch]
    Antwort #30 am: 26. März 2015, 01:45:18
    Also manchmal Frage ich mich warum ich Fragen stelle.

    Also, hast du Module verbaut die in den betroffenen Dateien Änderungen verlangt haben, oder Module die mit "Kunden" zu tun haben?

    Die ajax_checkout_actions.php (1 Page Checkout), gehört zu einer Erweiterung die mit Kunden, bzw. Kundendaten zu tun hat.

    Ich weiß ja nicht welche Version du verwendest, ich kenne Versionen wo z. B. solche Sachen drinnen stehen,

    Code: PHP  [Auswählen]
    if ($query0_exe && $query1_exe && $query2_exe && $query3_exe && $query4_exe && $query5_exe && $query6_exe && $query7_exe && $query8_exe && $query9_exe && $query10_exe && $query11_exe && $query12_exe && query13_exe && query14_exe) {
     
    oder
    Code: PHP  [Auswählen]
    campaigns_refID = '".$_SESSION[tracking][refID]."'"
    Das 2. geht zwar durch, aber richtig ist es nicht.

    Da würde es mich nicht wundern wenn da noch andere Fehler versteckt sind.

    Gruß
    Shop Hosting

    GTB

    • modified Team
    • Gravatar
    • Beiträge: 6.225
    • Geschlecht:
    Re: Vermischte Bestellungen [kritisch]
    Antwort #31 am: 26. März 2015, 08:11:14
    Da würde es mich nicht wundern wenn da noch andere Fehler versteckt sind.

    Meine Rede  :thumbs:

    Gruss Gerhard

    webald

    • modified Team
    • Beiträge: 2.791
    Re: Vermischte Bestellungen [kritisch]
    Antwort #32 am: 26. März 2015, 08:14:57
    Mal unabhängig von derAntwort zu /includes/ajax_checkout_actions.php. Warum wird eigentlich die Antwort von xtc_db_perform (create_guest_account.php, ca. Zeile 237) nicht ausgewertet?
    Code: PHP  [Auswählen]
        if (ACCOUNT_DOB == 'true') {
          $sql_data_array['customers_dob'] = xtc_date_raw($dob);
        }
        xtc_db_perform(TABLE_CUSTOMERS, $sql_data_array);

        $_SESSION['customer_id'] = xtc_db_insert_id();

     
    Wenn dabei ein Fehler auftrat, dann wird die letzte ID, und das wäre die vom Kunden zuvor, in die Session geschrieben.

    web0null

    • Experte
    • Beiträge: 1.998
    Re: Vermischte Bestellungen [kritisch]
    Antwort #33 am: 26. März 2015, 13:09:55
    Wie kommst du darauf?
    Stichwort "Verbindungskennung".

    Im schlechtesten Fall kommt maximal "0" raus.
    Gruß

    webald

    • modified Team
    • Beiträge: 2.791
    Re: Vermischte Bestellungen [kritisch]
    Antwort #34 am: 26. März 2015, 13:40:21
    Stimmt, habe ich nicht bedacht, was aber trotzdem bleibt, ist das der Rückgabewert von xtc_db_perform nicht ausgewertet wird.

    Die Frage ist ob xtc_db_insert_id nicht doch eine falsche ID zurückgeben kann. Wir hatten hier doch mal den Fall, dass Datenbankverbindungen nicht geschlossen wurden und irgendwann mal keine neuen mehr geöffnet werden konnten und der Server in die Knie ging. Könnte mysql_insert_id hier auf eine bestehende Verbindung zugreifen und damit die ID aus einer anderen Aktion erhalten? Ich erinnere mich dumpf so etwas mal in einem anderen Zusammenhang mit ODBC und connection-pooling gehabt zu haben.

    Jami

    • Neu im Forum
    • Beiträge: 19
    • Geschlecht:
    Re: Vermischte Bestellungen [kritisch]
    Antwort #35 am: 26. März 2015, 16:36:41
    Also um das nochmal zu durchleuchten und Fragen zu beantworten die ich teilweise nicht vollständig beantworten kann.

    Ich habe den Shop übernommen, mit allen Modulen und Anpassungen von meinem Vorgänger der NICHTS dokumentiert hat und es keinerlei Rückschlüsse gibt was genau er getan hat.
    Rechnungen über diese Arbeiten sind nichtssagend und unvollständig.

    Eine Kommunikation mit diesem ist nicht möglich da... er ist nicht dazu bereit, das ist die Kurzfassung.
    Da der Shop gut besucht ist und es zig Anpassungen gibt ist ein Tipp wie "mach es neu" nicht zielführend, soviel vorab.
    Mir geht es ja hier darum einen möglicherweise generellen Fehler zu finden bzw. zu beheben.
    Bisher las ich fast immer dass Betreiber mit solchen Problemen bei All-Inkl. ihren Shop betreiben.
    Also manchmal Frage ich mich warum ich Fragen stelle.
     
    Die Antwort bzw. die Erläuterung dazu habe ich gerade geliefert.
    Ich bemühe mich möglichst viele Informationen zu liefern, da ich den Shop allerdings nicht von grundauf selber baute ist mir das manchmal nicht in volllem Umfang möglich.

    Da würde es mich nicht wundern wenn da noch andere Fehler versteckt sind.
    Das schließe ich genauso wenig aus, es kann gut sein dass dort Fehler verbaut sind.

    Für mich stellt sich die Frage der Effizienz. Dieser Fehler tritt ca. alle 2-4 Wochen ein Mal auf.
    Der Shop soll wahrscheinlich Ende dieses Jahres komplett überarbeitet und quasi neu gemacht werden.
    Ich möchte gerne dass dieser Fehler entweder verschwindet oder unschädlich gemacht wird.
    Die erste Möglichkeit ist weiter zu spekulieren und zu suchen, möglicherweise mit Ergebnis, möglicherweise ohne. Da der Fehler nicht reproduzierbar ist werde ich es niemals testen können.
    Die zweite Möglichkeit ist den Fehler an der Stelle zu erkennen wo er auftreten MUSS und dort einen Riegel vor zu schieben.

    Ich bin kein Freund von Schmerzmitteln bei Zahnschmerzen denn das behebt den Fehler nicht. In Anbetracht der beschriebenen Umstände sehe ich Weg zwei allerdings als eindeutig den besseren an.
    Wäre das mein privater Shop und ich würde das in meiner Freizeit als Hobby machen, würde ich mich damit auch noch Wochen beschäftigen, sowas wurmt mich. Allerdings muss eine Lösung her mit einem angemessenen Zeitaufwand.

    Ich glaube mich zu erinnern dass in den letzten Fällen kein customer angelegt wurde (vor der Umstellung des Löschen der Gastkonten), für mich ergibt das dann insgesamt einen Sinn. Wodurch das passiert und unter welchen Umständen wüsste ich gerne, kann ich aber nicht beantworten.
    Mein Ansatz ist nun eine Erkennung dieses Fehlers und die dazugehörige Aktion.

    Die Frage ist ob xtc_db_insert_id nicht doch eine falsche ID zurückgeben kann.

    Eine Frage von mir: kann das jemand beantworten? Ganz unabhängig von Modulen oder sonstigem.
    Und dazugehörig: wie würdet ihr in diesem Fall testen?
    Haltet ihr den Ansatz dieses Posts für gut? http://www.modified-shop.org/forum/index.php?topic=32574.msg297445#msg297445

    Für mich scheint es sinnvoll zu testen ob überhaupt ein customer mit den angegebenen Daten angelegt wurde. Sollte das in 1/1000 Fällen nicht passieren (was der Fall zu sein scheint), muss die Bestellung entweder schlicht abgebrochen oder korrigiert werden. Wobei für mich ein Abbruch besser scheint da ansonsten noch mehr Fehlerquellen entständen, was wiederrum nicht schön für den Nutzer ist aber immer noch besser als vermischte Bestellungen.

    Kann mir jemand dazu seine Meinung oder einen weiteren Vorschlag unterbreiten? :)

    web0null

    • Experte
    • Beiträge: 1.998
    Re: Vermischte Bestellungen [kritisch]
    Antwort #36 am: 26. März 2015, 16:49:32
    Genau das ist eine Information womit man sich ein Bild machen kann.  :thumbs:
    Zip mal deine "ajax_checkout_actions.php" die ich als Übeltäter vermute.

    Jami

    • Neu im Forum
    • Beiträge: 19
    • Geschlecht:
    Re: Vermischte Bestellungen [kritisch]
    Antwort #37 am: 26. März 2015, 17:09:00
    Zip mal deine "ajax_checkout_actions.php" die ich als Übeltäter vermute.

    Eine Versionsnummer des Checkouts habe ich bisher nicht finden können.

    Marcus Kreusch

    • Fördermitglied
    • Beiträge: 312
    • Geschlecht:
    Re: Vermischte Bestellungen [kritisch]
    Antwort #38 am: 26. März 2015, 17:35:08
    Ich würde an dieser Stelle gern noch einmal meinen Vorschlag wiederholen, alle Aktionen in einem Log mitzuschreiben. Das gibt wesentlich bessere Daten für die Analyse, als zig Dateien durchzulesen und zu versuchen sich das jeweils mögliche Szenario vorzustellen - da gerät man auch schnell auf den Holzweg.

    Gerade bei dem 1-Page-Ajax-Checkout habe ich gute Erfahrungen mit Logs gesammelt, weil der seine Schwächen hat, die aber schwer zu debuggen sind.

    web0null

    • Experte
    • Beiträge: 1.998
    Re: Vermischte Bestellungen [kritisch]
    Antwort #39 am: 26. März 2015, 18:16:19
    Ist eine gute Empfehlung.

    Alleine wenn ich so etwas sehe,
    Code: PHP  [Auswählen]
    xtc_db_perform(....
     
    Code: PHP  [Auswählen]
    xtc_db_query("update "....
    xtc_db_query("insert into "...
     
    und das innerhalb von 4 Zeilen, muss ich  :-?

    Gruß

    gerdvomabbruch

    • Frisch an Board
    • Beiträge: 81
    Re: Vermischte Bestellungen [kritisch]
    Antwort #40 am: 28. März 2015, 21:09:26
    ... was passieren würde, würde ich die customer_id im address_book auf Unique stellen.
    Das darfst Du nicht machen. Wenn Du das machst, dann kann der Kunde nur genau eine Adresse anlegen. Eine separate Lieferadresse oder eine andere Rechnungsadressse ist dann nicht mehr möglich.

    Darauf legen wir sogar ganz besonderen Wert! Niemals eine abweichende Lieferadresse. Gibt im Jahr 1-2 Kunden der sich deswegen beschwert. Sorgt aber auf der anderen Seite für eine problemlose Abwicklung der Bestellung.

    webald

    • modified Team
    • Beiträge: 2.791
    Re: Vermischte Bestellungen [kritisch]
    Antwort #41 am: 30. März 2015, 07:51:13
    dafür braucht man aber die Datenbank nicht ändern. Im Admin kann man die max Anzahl Adressen doch einstellen.

    DeeOne

    • Neu im Forum
    • Beiträge: 4
    Re: Vermischte Bestellungen [kritisch]
    Antwort #42 am: 14. Dezember 2020, 17:26:40
    Ich würde die Diskussion hier gerne erneut aufgreifen, da ich aktuell an einem sehr ähnlichem Problem nage.

    Unser Kunde betreibt einen relativ erfolgreichen modified Shop (V. 2.0.5.0). Seit Anfang des Monats häufen sich Beschwerden, dass falsche Adressen angegeben sind, bzw. Bestellbestätigungen für nicht aufgegebene Bestellungen verschickt worden sind.

    Es hat sich herausgestellt, dass die Bestellungen tatsächlich aufgegeben wurden, an irgendeinem Punkt im Checkout wurde jedoch die Zuordnung der Bestellung zum Kunden-Account vermischt. Das interessante: Die Versand- & Rechnungsadresse entspricht bei betroffenen Bestellungen dem tatsächlichen Besteller. Beschwert haben sich immer die Personen, zu dessen Account die Bestellung fälschlicherweise zugeordnet wurde.

    Dieser Satz aus einem Beitrag dieses Threads beschreibt das Problem ganz gut:

    [...]
    Der Fehler ansich ist ja auch nicht dass der Shop zwei Bestellungen "einfach so" vermischt sondern viel mehr dass bei der Registration/Bestellung eines Nutzers (bei Gästen) "manchmal"(?!) eine ID doppelt vergeben bzw. in das address_book eine bereits vorhandene ID geschrieben wird.
    [...]

    In unserem Fall gibt es jedoch keine direkte Beziehung zwischen dem vorhergegangenem Besteller und der falsch zugeordneten Bestellung.
    Edit: Bei einer Bestellung war besonders auffällig, dass der Adress-Satz des eigentlichen Bestellers aus der Datenbank dupliziert wurde und zu der Kundin zugewiesen wurde, die im Anschluss die Bestellung fälschlicherweise erhalten hat.

    Da wir bis vor Kurzem aktiv am Shop gearbeitet haben, wird der Fehler am ehesten bei uns liegen. Einen Core-Fehler halte ich an dieser Stelle für ausgeschlossen. Da ich aber den Fehler auch nicht nachstellen kann und es anscheinend keine logische Verknüpfung gibt, komme ich zur Zeit nicht weiter.

    Ich weiß, dass ich jetzt fünf Jahre altes Wissen abfrage, aber auch ich muss zu einem Ergebnis kommen und leider endet der Thread ohne Angabe, ob man eine Lösung gefunden hat.
    Da mir aber außerdem noch auffällig vorkam, dass unser Kunde ebenfalls bei ALL-INKL. gehostet wird, wollte ich doch nochmal ein paar Stimmen aus dem Forum hören:
    - Konnte ein Fehler bei ALL-INKL festgestellt werden, oder hat ALL-INKL zur Lösung beigetragen? (Falls ja können wir nämlich direkt mit dem Hoster kommunizieren)
    - Welche Logs haben Aufschluss über die Lösung gegeben? ("Klassische" PHP-Info- & -Error-Logs wurden nicht geschrieben, DB Log wurde gerade erst aktiviert, da müsste man nun auf das nächste Auftreten des Fehlers warten)
    - Oder ist es vielleicht doch die Session? Wäre es besser, die Option "Session erneuern" zu deaktivieren?

    Falls sich noch jemand an die Lösung dieses Falles erinnern kann, oder mir vielleicht einen Schubser in die richtige Richtung geben kann, darüber würde ich mich riesig freuen.
    Falls Ihr noch Informationen braucht, gebt einfach gerne Bescheid.

    Beste Grüße!

    [EDIT Tomcraft 14.12.2020: Zitierten Beitrag mit Zitatfunktion verlinkt.]

    noRiddle (revilonetz)

    • Experte
    • Beiträge: 13.743
    • Geschlecht:
    Re: Vermischte Bestellungen [kritisch]
    Antwort #43 am: 14. Dezember 2020, 18:22:14
    Hast du irgendwelche Caches aktiviert ?
    Backend => Erw. Konfiguration => Cache Optionen

    Falls ja, alle deaktivieren, die Cache-Funktionen sind im 2.0.5.0 noch buggy, oder auf 2.0.5.1 updaten.
    Ansonsten keine Idee momentan.

    Gruß,
    noRiddle

    DeeOne

    • Neu im Forum
    • Beiträge: 4
    Re: Vermischte Bestellungen [kritisch]
    Antwort #44 am: 15. Dezember 2020, 11:15:16
    Lediglich die Option zur Überprüfung, ob der Cache modifiziert wurde, war aktiviert. Diese Einstellung hat vermutlich keine Wirkung, wenn der Cache an sich deaktiviert ist. Ich habe die Option dennoch deaktiviert.

    Danke für Deine schnelle Reaktion!
    rechtstexte für onlineshop
    0 Antworten
    1738 Aufrufe
    17. Juni 2016, 09:15:22 von lohkaes1
    1 Antworten
    2349 Aufrufe
    09. November 2009, 16:17:08 von koshiro
    3 Antworten
    3375 Aufrufe
    25. Mai 2012, 07:21:18 von Buggyboy
               
    anything