MODUL: PayPal PLUS & PayPal Checkout Zahlungsmodule für modified eCommerce Shopsoftware

[borwerbung]

Während ich noch fleißig geschrieben habe kam schon die PP+ V1.26 raus, daher hat sich Antwort #1423 erledigt. Habe die neue Version eingespielt und alles läuft prefekt.
Einen großen Dank an Torsten, noRiddle und GTB für die schnelle Lösung +++
(ich bin erleichtert und freue mich riesig)

[Timm]

Danke fürs Update.

@GTB
Seit dem Update auf Version 1.26 läuft das mod_notice log wieder voll.

Innerhalb von 2 Stunden sind es schon 44 Dateien a 1MB. Die anderen Tage davor war nichts.

Allerdings geht es da hauptsächlich um undefined variable: request type, current domain und http_domain was in Verbindung mit dem SEO Images Tool steht, wo du eine Lösung für mich gefunden hast, die aber im Produktivshop noch nicht eingepflegt ist. Dennoch kam das ja vorher nicht mehr.

Soll das so sein?

Gruß Timm

[GTB]

/includes/error_reporting.php

suche:

Code: PHP  [Auswählen]

      if (($error_reporting == '_error_reporting.admin' && defined('RUN_MODE_ADMIN'))
          || ($error_reporting == '_error_reporting.shop' && !defined('RUN_MODE_ADMIN'))
          )
      {

ersetze mit:

Code: PHP  [Auswählen]

      if (($error_reporting == 'admin' && defined('RUN_MODE_ADMIN'))
          || ($error_reporting == 'shop' && !defined('RUN_MODE_ADMIN'))
          )
      {

Gruss Gerhard

[Tomcraft]

Ich habe diese Korrektur aus oben stehendem Beitrag bzw. r12067 mit in Modulversion 1.26 aus Beitrag 1 mit aufgenommen. Da sich an der Funktionalität der PayPal Module dadurch nichts ändert und es auch nur die Module für Shopversion 2.x betrifft, hat sich die Modulversion diesmal nicht erhöht.

Wer bereits eine ältere Version des Moduls installiert hatte, der lädt bitte einfach den Inhalt des Ordners "NEW_FILES" erneut in seinen Shop.

Zusätzlich sind seit der letzten Modulversion noch folgende Dateien aus dem Ordner "CHANGED_FILES" zu bearbeiten:

Für Shopversion 2.0.0.0 rev 9678, 2.0.1.0 rev 10403, 2.0.2.0 rev 10591, 2.0.2.1 rev 10607, 2.0.2.2 rev 10690, 2.0.3.0 rev 10907, 2.0.4.0 rev 11204, 2.0.4.1 rev 11327 & 2.0.4.2 rev 11374

• /includes/error_reporting.php

Da hier davon ausgegangen wird, dass der Shopbetreiber an diesen Dateien keine Änderungen vorgenommen hat, können die Dateien aus dem Ordner "CHANGED_FILES" für die genannten Shopversionen einfach in den Shop kopiert werden.

Grüße

Torsten

[Timm]

Wichtig!!!

Nach dem Update auf die neueste Version bzw. auch schon ein paar Versionen früher muss unbedingt das PayPal Profil gelöscht und neu angelegt werden und als Standard definiert bzw. in den einzelnen PayPal Produkten als Standardprofil zugewiesen werden.

Ansonsten kann man weiterhin die Adressen nachträglich bei PayPal ändern und hat z.B. deutsche Versandkosten berechnet und bekommt aber eine ausländische Adresse von PayPal zurück und müsste theoretisch an diese liefern.

Ein bloßes kontrollieren der Einstellungen hilft nicht. Selbst ein bereits als Standard hinterlegtes Profil lässt die Änderungen bei PayPal noch zu.

Danach mit Classic und Plus testen. Auch ob die Logogröße passt. Es muss dann bei PayPal stehen, dass die Adresse nur noch im Shop direkt änderbar wäre.

Gruß Timm

[EDIT Tomcraft 08.08.2019: Hinweis in Beitrag 1 ergänzt.]

[woodpecker]

@Tomcraft
vielen Dank für das Update.

@FräuleinGarn
vielen Dank für deinen Tipp.

Grüße
Rene

[Timm]

Hallo Team,

2 Probleme:

1)

Code: XML  [Auswählen]

[12-08-2019 16:28:57] PayPal\Core\PayPalHttpConnection : ERROR: Got Http response code 400 when accessing https://api.paypal.com/v1/payments/payment/PAYID-XXXXXXXXXXXXX/execute. {"name":"TRANSACTION_REFUSED","message":"The request was refused","information_link":"https://developer.paypal.com/docs/api/payments/#errors","debug_id":"d50511ec3b71c"}
5130

Wenn ich mir in dem angegebenen Link die Anmerkungen zur Fehlermeldung Transaction Refused angucke, dann kommen nur mögliche Fehler in Zusammenhang mit einer Rückzahlung und eine mögliche Quelle mit irgendwelchen Limits. Die Fehlermeldung entstand aber bei einem Kunden der den Warenkorb gefüllt hat und dann ganz normal den checkout durchlaufen hat und mit PayPal Plus zahlen wollte. Was er davon ausgewählt hat kann ich nicht sagen, weil man das im access Log nicht nachvollziehen kann. Jedenfalls hat das doch nichts mit refund zu tun.

Hatte das nun 3 mal in den letzten paar Tagen im Shop meiner Mum. Ob es vor der 1.26 schon vorkam kann ich nicht sagen, da ich die error Logfiles gelöscht habe übers Backend, beim Update des Moduls da es so viele waren.

Das ganze führt dann auch zu unschönen Bestellnummernsprüngen. (Das Hatte ich ja schonmal hier im Thread erwähnt, aber es wurde als normales Verhalten angesehen, was auch verständlich ist. Allerdings gab es da auch eine klare Fehlermeldung)

2)
Jeder Aufruf der account_checkout_express.php mit leerem Warenkorb führt zu folgender Fehlermeldung.

Code: XML  [Auswählen]

[12-08-2019 20:01:25] PayPal\Core\PayPalHttpConnection : ERROR: Got Http response code 400 when accessing https://api.paypal.com/v1/payments/payment. {"name":"VALIDATION_ERROR","details":[{"field":"transactions[0].amount","issue":"Amount cannot be zero"}],"message":"Invalid request - see details","information_link":"https://developer.paypal.com/docs/api/payments/#errors","debug_id":"5c812f5eabdc3"}

Könnte man das nicht unterbinden? Gibt ja öfter mal Kunden, die sich ihre Accounteinstellungen angucken und dann auf "Mein Schnellkauf" klicken. Dadurch passiert scheinbar nichts außer der Fehlermeldung. Aber für die Fehlersuche bei anderen Problemen wie dem aus Nr.1 macht das das log unübersichtlich.

Braucht's dafür ein Ticket?

Gruß Timm

[Tomcraft]

[...]
Braucht's dafür ein Ticket?
[...]

Ja, denn hier wird es unter gehen, falls es wirklich ein Fehler im Modul ist.

Grüße

Torsten

[Timm]

Habe dafür Ticket #1664 angelegt.

Zusätzlich wird nur Paypal Classic in mein Schnellkauf als Paypal angezeigt. Paypal Plus wird nicht angezeigt.

Dafür habe ich Ticket #1665 angelegt.

Gruß Timm

P.S. Wäre schön, wenn noch jemand vom Team etwas zu meinem Punkt 1 aus meinem letzten Post sagt. Eventuell muss dafür auch ein Ticket angelegt werden.

[Tomcraft]

[...]
P.S. Wäre schön, wenn noch jemand vom Team etwas zu meinem Punkt 1 aus meinem letzten Post sagt. Eventuell muss dafür auch ein Ticket angelegt werden.

Dazu schrieb ich doch bereits:

[...]
Braucht's dafür ein Ticket?
[...]

Ja, denn hier wird es unter gehen, falls es wirklich ein Fehler im Modul ist.
[...]

Was war denn daran nicht zu verstehen?

Ticket #1665 ist bereits geschlossen.

Grüße

Torsten

[Timm]

[...]
Was war denn daran nicht zu verstehen?
[...]

Jeder liest Texte anders. 

Für mich bezog sich "Braucht's dafür ein Ticket" nur auf Punkt 2. Zu Punkt 1 hätte eine Erklärung vielleicht gereicht. Will ja auch nicht Tickets schreiben, die dann gleich auf won't fix gestellt werden. 

Gruß Timm

[Tomcraft]

Tickets zu bearbeiten ist doch für uns kein Problem! Da geht wenigstens nichts unter!

Grüße

Torsten

[Baschtl]

Ist vielleicht 'ne blöde Frage, aber warum ist im Download Package modified-shop_2.0.4.2-r11374 nicht bereits v1.26 enthalten und immer noch v1.1?

[Tomcraft]

Weil wir bereits veröffentlichte Shopversionen nicht mehr nachträglich ändern!
Eine bereits veröffentlichte Shopversion hat immer den selben Dateistand und das wird bei uns auch immer so bleiben.
Wer soll da sonst noch den Überblick drüber haben, welche Dateien in einer Shopversion von uns noch nachträglich aktualisiert wurden?

Grüße

Torsten

[Baschtl]

Alles klar... wird dann aber sicher in der nächsten Vollversion enthalten sein, oder?