Ich will das Thema noch mal neu aufsetzen, weil der Ursprungs-Thread schon etwas länglich ist. Basis ist dieser Thread von Manfred vom 30.9.2014: http://www.gambio-forum.de/threads/...tätigungs-Mail?p=138534&viewfull=1#post138534 PHP: Seit ca. vorgestern steht in den Mails von PP in den Artikelbeschreibungen so´n Zeuch drin:"xxxBASE64_STARTxxxQmFtYmVyZ2VyIEjDtnJuY2hlbgxxxBAS E64_ENDxxx"... und darunter (richtig) die Artikel-Nummer. In den letzten Tagen musste ich mich mit PayPal intensiver befassen, und habe so das Problem direkt erlebt. Es kann doch wohl nicht sein, dass dieses Problem von Gambio/PayPal nun seit 5,5 Monaten(!) nicht gelöst werden konnte! Diese PayPal-Mails sehen absolut unprofessionell aus. Ich sach mal so: 1 Tag gemeinsames Debugging der PayPal-Abläufe durch Gambio und PayPal würde sicher ausreichen, das Problem zu erkennen und zu lösen. Zunächst mal die Frage: wer hat dieses Problem schon bei seinem Shop festgestellt? So kann das jedenfalls nicht bleiben! Ich bin auch gerne bereit, hier beim debuggen zu helfen, falls notwendig, da ich jetzt 2 Shops habe, bei denn das Problem auftritt. Da ich das Problem eher bei PayPal ansiedele, solltte Gambio auch mal nachdrücklich die Behebung dieses Problems einfordern. Auf geht's! Wäre doch gelacht, wenn man das Problem nicht kurzfristig lösen kann.
Sachstand unverändert! Nach ausgesprochen dusseligen Antworten des PP-Telefonservice und Null-Reaktion auf Mails => entnervt aufgegeben!
Bei uns auch gelegentlich bei einigen Artikeln. Wenn ich mich recht entsinne waren es die Artikel die Umlaute usw. im Namen haben oder wie war das bei euch Manfred?
Hi, das Problem ist bekannt, und ja es ist blöd, wir hätten das auch gerne aus der Welt. Ich spreche Anfang der kommenden Woche nochmal mit PayPal darüber, wenn sich etwas neues sagen lässt melde ich mich zu Wort.
Quersch denen mal die Eier, vielleicht klappt es dann Das Problem existiert fast ein halbes Jahr.... Das geht gar nicht. Vor allem weil man das sicher in kurzer Zeit lösen kann.
Bevor ich jetzt wieder 6 Monate warte, bis sich jemand erbarmt, das zu lösen, mache ich das mal lieber selbst.... Das Problem ist ja anscheinend, dass es bei Artikelnamen mit Umlauten (sonderzeichen) diese Probleme gibt. Was liegt also näher, als diese sonderzeichen so an PayPal zu übermitteln, dass es keine Probleme damit gibt. Mein erster Ansatz war, die Sonderzeichen durch ihre entsprechenden HTML-Entities zu ersetzen... Der Name "10 Stück 5mm Led Halter Schwarz für Ihre 5mm Leds" wurde dabei zu "10 Stück 5mm Led Halter Schwarz für Ihre 5mm Leds" konvertiert. Das hat leider nicht funktioniert, anscheinend wandelt PayPal diese HTML-Entities wieder um, und hat dann das Ursprungsproblem wieder. Dann blieb eigentlich nur übrig, die Umlaute in ihre alternative Schreibweise zu konvertieren (Ä=>Ae, usw). Der Name "10 Stück 5mm Led Halter Schwarz für Ihre 5mm Leds" wurde dabei zu "10 Stueck 5mm Led Halter Schwarz fuer Ihre 5mm Leds" konvertiert. (Ist jetzt zwar nicht sooo schön, aber allemal besser als PHP: xxxBASE64_STARTxxxMTAgU3TDvGNrIDVtbSBMZWQgSGFsdGVyIFNjaHdhcnogZsO8ciBJaHJlIDVtbSBMZWRzxxxBASE64_ENDxxx. ) Und siehe da, das mag PayPal dann wieder! Was ist zu tun? In "gm\classes\GMPayPal.php" in "public function prepareExpressCheckout()" PHP: $itemDetails->Name = $this->transcodeOutbound($quantity_prefix . $item['name']); $itemDetails->Number = $this->transcodeOutbound($item['model']); ändern zu PHP: //Avenger $itemDetails->Name = $this->transcodeOutbound($quantity_prefix . $item['name'],false); $itemDetails->Number = $this->transcodeOutbound($item['model'],false); //Avenger In "protected function _makePaymentDetailsItemArray($p_order)" PHP: $itemDetails->Name = $this->transcodeOutbound($qty_prefix . $product['name'] . $attributes_suffix,false); $itemDetails->Number = $this->transcodeOutbound($product['model'],false); ändern zu PHP: //Avenger $itemDetails->Name = $this->transcodeOutbound($qty_prefix . $product['name'] . $attributes_suffix,false); $itemDetails->Number = $this->transcodeOutbound($product['model'],false); //Avenger PHP: public function transcodeOutbound($string) { if($this->_localEncodingIsLatin1()) { $output = utf8_encode($string); } else { $output = $string; } return $output; } ändern zu PHP: //Avenger public function transcodeOutbound($string,$is_normal_transcode=true) { if ($is_normal_transcode) { if($this->_localEncodingIsLatin1()) { $output = utf8_encode($string); } else { $output = $string; } } else { if (mb_detect_encoding($string, 'UTF-8', true)) { $string=utf8_decode($string); } $string=html_entity_decode_wrapper($string); $output=str_replace(array("Ä", "Ö", "Ü", "ä", "ö", "ü", "ß"), array("Ae", "Oe", "Ue", "ae", "oe", "ue", "ss"), $string); } return $output; } //Avenger Das löst allerdings im Moment nur die Probleme mit Umlauten und "ß". Zeichen wie "é" werden weiterhin Probleme bereiten, die kommen aber nicht soo oft vor.... Da das Problem anscheinend nur bei Artikelnamen existiert, und nicht bei anderen Elementen (z.B. "Mönchengladbach") habe ich diese spezielle Konvertierung nur auf die Artikelnamen und Artikelnummern beschränkt. Wie immer gilt: Anwendung auf das ausschließliche Risiko des Shopbetreibers. Es gibt keinerlei Gewährleistung. Erst in einem Testshop testen. Cache leeren.
Hi, nochmal eine Frage meinerseits: Habt ihr alle in eurem PayPal Profil die richtige Sprachkodierung eingestellt ? Pfad dorthin: Einloggen => "Zahnrad" (oben rechts: Mein Profil)=> Verkäufer/Händler => Sprachliche Kodierung von PayPal-Buttons => Weitere Optionen => UTF8 Haben wir hier Händler, bei denen das korrekt gesetzt ist und bei denen trotzdem das Problem auftritt ?
Bei mir war 2x windows-1252 eingestellt. Habe jetzt beide Optionen auf UTF-8 gestellt und werde berichten...
Also du hast danach neue Bestellungen bekommen und das Problem besteht trotzdem ? Kannst du mir so eine daneben gegangene Mail dann als exemplarisches Anschauungsstück nochmal weiterleiten ? Schick das bitte an w.haase@gambio.de, ich gehe dann morgen wieder ins Gespräch mit PayPal damit.
Diese Erfahrung spricht m.E. dafür, dass das nichts damit zu tun hat.... Denn selbst wenn ich HTML-Entities statt der Sonderzeichen verwende, gibt es das Problem. Und. das Problem tritt nur bei den Artikelnamen auf. Städte- und Eigennamen werden sauber auch mit Umlauten richtig in der Mail wiedergegeben, so dass es kein generelles Problem mit der Codierung geben kann. Auch andere Shop-Systeme sind betroffen: http://www.modified-shop.org/forum/index.php?topic=31339.0 http://support.ecomponents.de/respo...er-zahlungseingang-mit-xxxbase64-start-fehler http://forum.shopware.com/allgemein-f25/paypal-warnung-sofortige-zahlungsbestatigung-t23529.html PHP: - Loggen Sie sich in Ihr PayPal-Konto ein- Oeffnen Sie dann diese Seite: https://www.paypal.com/cgi-bin/custo...guage-encoding- Klicken Sie auf "Weitere Optionen"- Bei "Codierung" sollte "ISO-8859-15" ausgewaehlt sein; wenn nicht, bitte auf diesen Wert umstellen- Bei "Soll diese Codierung auch für Daten verwendet werden..." sollte "Nein, diesen Code verwenden" ausgewaehlt sein und das Dropdown-Feld muss "ISO-8859-15" anzeigen Im letzten POST gibt PayPal übrigens eine andere Empfehlung für die einzustelelnde Codierung_ "ISO-8859-15" statt "UTF-8"....
Unter http://forum.shopware.com/allgemein-f25/paypal-warnung-sofortige-zahlungsbestatigung-t23529.html gibt PayPal einen anderen Rat bezüglich der Codeeinstellung, nämlich den Code "ISO-8859-15". einzustellen.... Unser Kunde hatte es vorher auf "ISO-8859-15" => funktioniert nicht... Nach Umstellung auf "UTF-8" => funktioniert nicht... Das ist einfach ein PayPal-Bug.... Aber da PayPal ja bekanntlich keine Fehler macht.....
Danke Manfred, ich hab deine Mail vor der Nase Ich klemme mich für euch alle gerade wieder dahinter, mal sehen was sich erreichen lässt.
Sage, denen, Avenger hat gesagt, dass das ganz alleine ihr Problem ist, und sie endlich mal in die Hufe kommen sollen.... Ist schon peinlich, so ein Problem 6 Monate lang nicht zu lösen.