Jump to content
xt:Commerce Community Forum

Ranger-Shop.de

Members
  • Content Count

    34
  • Joined

  • Last visited

  1. So sieht es wohl aus. Die version 2.1.2 benötigt wohl zwingend die Shop-Version 4.1, um funktionieren zu können. Sonst würde man das als Update anbieten. Ansonsten "bräuchte man nur" die Shop-Version 4.1 herunterladen und das PayPal-Plugin daraus extrahieren.
  2. Genau auf dieser Seite steht immer nur "Aktuelle Version: 2.0.2"! Nun schaut ja nicht jeder bei den Downloads nach, ob dort vielleicht eine neuere Version vorhanden ist... Version 4.1 ist bei uns noch in der Testphase, ob unsere selbst geschriebenen Plugins damit auch kompatibel sind. Da bin ich ja mal gespannt...
  3. Hallo, dann muss ich jetzt mal fragen, welche Versionsnummer das aktuelle PayPal-Modul denn hat? Sollte es nämlich die Version 2.0.2 sein, die auf der xt-commerce.com Webseite zu finden ist unter den Plugins, dann muss ich sagen: das hilft nicht. Denn diese Version habe ich bereits seit Monaten installiert und der Fehler tritt trotzdem mehrmals am Tag auf. Das habe ich aber auch schon in meinem Post vom 23.01.2013 geschrieben. Wir haben inzwischen etwa 10 bis 15 mal pro Woche im Callback-Log diesen Fehler "INVALID responce but invoice and Customer matched". Von all diesen Callbacks habe ich Logs, sowohl von den Daten, die an PayPal geschickt wurden als auch von denen, die von dort zurück kamen. Bei einigen sind tatsächlich Umlaute drin, bei denen der Eintrag in der Callback-Log Tabelle dann auch abgeschnitten wurde. Es gibt aber auch Callbacks, bei denen kommt nicht ein einziger Umlaut drin vor. Einzig und allein an Umlauten (äöüÄÖÜ und auch das ß - beliebt bei dem Wort Straße ;-) ) kann es also nicht liegen. PayPal läßt mit ihrer Antwort auf meine Anfrage, mir doch einmal die Rohdaten für die Fehlertransaktionen zukommen zu lassen, leider immer noch auf sich warten. Bis dahin bleibt uns weiterhin nur täglich unser Abfrageskript (ja, wir haben schon extra ein Skript geschrieben, das alle Bestellungen und deren Status überprüft und fehlerhafte über die PayPal-API gegencheckt) aufzurufen und die dann manuell zu korrigieren (das wollte ich dem Skript nicht auch noch überlassen ;-) ) MFG, Ranger-Shop.de PS: Bitte den Sarkasmus nicht persönlich nehmen ;-) Der spiegelt nur unseren Frust bzgl. dieses Themas wider.....
  4. Das / Zeichen ist in Textfeldern immer mal wieder ein Problem :-) Bin gespannt, ob es bei Euch zum Erfolg führt. Wir haben zwar keine Tags im Produktnamen oder in anderen Feldern, aber das Zeichen kann durchaus mal auftauchen. Danke für den Hinweis, ich schau mal, ob ich da Parallelen finden kann zwischen den betroffenen Bestellungen.
  5. Wenn klar ist, in welchem Format übermittelt wird, dann braucht man bei PayPal ja nur das gleiche einzutragen. Dann wäre die Ursache schonmal weg. Aber auch ich bin der Meinung, dass das nicht das eigentliche Problem ist. Seit der Anpassung haben die Fehler zwar bei uns abgenommen, weg sind sie aber noch nicht. Alle ein bis zwei Wochen kommt wieder mal ein Fall vor, bei dem ein INVALID zurück kommt. Ich bin noch dran das Ganze zu analysieren und melde mich wieder, wenn es etwas Neues gibt. Leider habe ich gerade ein paar wichtigere Dinge zu tun, so dass mir für das Problem nicht viel Zeit bleibt.
  6. Hallo, ich muss die Arbeit an diesem problem auf Anfang nächste Woche verschieben, da mir ein paar andere Aufträge dazwischen gekommen sind. Sobald ich mich wieder damit befasse, melde ich mich hier wieder. mfg
  7. Hmmm, Post tauchte doppelt auf nach Antworten.
  8. Hallo, wir hatten jetzt gerade auch wieder einen Fall, den ich gleich zum PayPal Support geschickt habe. Jetzt sagte man mir, es läge an dem Eintrag "DHL (DE)", den wir als Versandartikel mitschicken und zwar an den Klammern, die ja maskiert als %28 und %29 im Request-String enthalten sind. Wären die direkt als Klammer enthalten, bekäme man ein Verified zurück. Das kann aber nicht das Problem sein, weil dieser Artikel fast immer dabei ist und der Fehler nur ab und zu mal auftaucht. Ich lasse mir jetzt von PayPal mal deren Strings zu dem Problemtransaktionen schicken, so dass ich die vergleichen kann. Vielleicht finde ich dann heraus, wo das Problem liegt. Dann könnte ich das im PayPal-Modul beheben und den Bugfix dann an XTC schicken, so dass sie dann ein Update für das Modul erstellen können. Wir verwenden seit 2 Tagen die Version 2.0.2, zuvor hatten wir die 1.2.6. Shop Version ist 4.0.14. Wie ist es bei Euch?
  9. Hallo, die option findet man, indem man sich in das PayPal-Konto einloggt, dann auf "Mein Profil" geht, dort links auf "Verkauf/Händler" und dann findet man ganz unten unter "Weitere Verkaufstools" den Punkt "Sprachliche Kodierung von PayPal-Buttons". Dahinter verbirgt sich die Seite "Sprachcodierung", wo man den Button "Weitere Optionen" anklickt und so auf die Seite "Weitere Codierungsoptionen" kommt. Dort kann man dann die Codierung getrennt für die Webseite und den Datenversand per Mail oder IPN einstellen. Wünsche viel Glück, dass es weiter hilft :-) Über ein Feedback, ob es etwas gebracht hat, würden wir uns freuen.
  10. Hallo, wir hatten das Problem auch. PayPal sagte uns dann, es läge an der Codierung der IPN Nachrichten. Wenn der Shop eine andere als die voreingestellte Codierung verwendet, dann muss das bei PayPal in den Einstellungen unter API angepasst werden. Unser Shop läuft mit UTF-8, bei PayPal war aber etwas anderes eingestellt. Das Problem sollen Umlaute und Sonderzeichen auslösen. Seit der Anpassung ist der Fehler nur noch einmal aufgetreten, vorher hatten wir pro Woche mehrere mit einem Fehler, obwohl alles ok war.
  11. Vielen Dank für die Antwort! (War bis diese Woche im Urlaub, lese das also erst jetzt) Das könnte uns weiterhelfen - ich werde das mal auf unserem Testsystem ausprobieren mit einer anderen Datenbank.
  12. Hallo, danke für die Antwort. Allerdings hilft sie mir leider nicht weiter. Ich wollte wissen, ob man wie bei der Shop-Version 3 die Session Speicherung statt in der Datenbank auch als Dateien auf der Festplatte des Servers ablegen kann. Wir haben momentan Probleme mit der Datenbank und möchten das Session-Management zumindest kurzzeitig auslagern. Was die DB Hooks angeht, genau diese Beschreibung steht auch im Veyton Praxixbuch, war mir also auch schon bekannt. Ich würde aber gerne wissen, WAS GENAU diese Funktion macht, nicht, wann man sie einstellen soll und wann nicht. Unser Server ist mit 32 Kernen und 64GB Ram ausgestattet und So optimiert, dass auch eine Verteilung auf die Kerne stattfindet. Das sollte also ein "starker" Server sein ;-)
  13. Hallo, ich kann grad nicht mit Bestimmheit sagen, warum ich die Antwort auf meine Frage nirgends finden kann - aber vielleicht kann mir jemand einen Anstoß geben: Wo stelle man in Veyton ein, wo die Sessions gespeichert werden (Datenbank, Dateisystem)? In XTC3.xx ist es ja die Datei configure.php, bei Veyton kann ich es ums Verrecken nicht finden, weder in Config-Dateien noch in irgendwelchen Feldern in der Datenbank oder im Backend. Achja - bei der Suche bin ich noch auf etwas anderes gestossen: Für was genau ist die Einstellung "Datenbank Hooks verwenden"? In der Doku und im Praxisbuch steht nur, dass man das für kleine Shops aktiviert lassen soll und dass sonst irgendwo ein Verzeichnis files bei plugins erstellt wird?!?!? Irgendwie sagt das aber nicht wirklich etwas über die eigentliche Funktion aus. Wäre also dankbar, wenn das jemand erläutern könnte. Vielen Dank! Bitte helft mir, Community, Ihr seid meine letzte Hoffnung ;-)
  14. Hier ein Beispiel, wie man (mittels Javascript) dem Bestell-Button seine Aktion entnimmt, so dass man mit ihm keine weitere Bestellung abschicken kann: HTML im Template /shop/templates/xt_default/xtCore/pages/checkout/subpage_confirmation.html: . . . {literal} <script type="text/javascript"> function send_order() { document.getElementById('send_order').innerHTML = document.getElementById('send_order').getElementsByTagName('a')[0].innerHTML; document.getElementById('sendform').submit(); } </script> <style type="text/css"> #send_order {display:inline-block; cursor:pointer;} </style> {/literal} . . . {form type=form id=sendform name=process action='checkout' method=post conn=SSL} . . . <div id="send_order"> <a href="javascript:send_order();"> {button text='Kaufen' btn_template='tpl_button_1.gif' file='button-kaufen.gif'} </a> </div> {form type=formend} . . . Damit wird das um das erzeugte <img> - Tag herum liegende <a> - Tag entfernt, wodurch der Button nicht mehr als link funktioniert. Mittels CSS wird der Cursor aber trotzdem so aussehen, als wenn es noch ein Link ist und man kann beliebig oft draufklicken, ohne dass etwas passiert.
  15. Weiterer Nachtrag: Ich hatte eben solch ein Lag beobachtet. Während dieses Lags konnte man z.B. die Startseite des Shops öffnen. Produktseiten allerdings nicht. Alle Produktseiten, die ich parallel in unterschiedlichen Tabs im Browser geöffnet habe, warteten alle gemeinsam auf Antwort vom Server. Als der Lag vorbei war, wurden plötzlich alle Produktseiten gleichzeitig angezeigt. Vielleicht liegt es an einer bestimmten Tabelle in der Datenbank. Auf unserer Startseite wird nicht auf die xt_products zugegriffen (wir beziehen die Daten aus einer anderen Tabelle auf dieser Seite). Die Produktseiten hingegen greifen auf diese Tabelle zu. Allerdings ließ sich die Tabelle über ein PHPMyAdmin öffnen, wodurch schonmal eine Sperre der Tabelle ausgeschlossen ist. Vielleicht liegt es ja an einer anderen Tabelle. Ich werde die alle mal durchprobieren, sobald ich wieder ein Lag sehe.
×
×
  • Create New...