Ich habe das ebenfalls in Benutzung.
Bisher habe ich zwei Dinge festgestellt:
Mit einem Full-SSL-Shop mit ENABLE_SSL = false wird das Logo nicht übertragen, dazu muss Zeile 97 in /includes/classes/paypal_checkout.php von
if(ENABLE_SSL == true) {
zu
if(ENABLE_SSL == true || HTTP_SERVER == HTTPS_SERVER) {
geändert werden.
Das zweite:
Mit Hilfe von Logging an verschiedenen Stellen und einem manuellen Error-Reporting habe ich dann doch etwas festgestellt:
das Affiliatemodul aus dem Forum (
http://www.modified-shop.org/forum/index.php?topic=3720.0) enthält diese Anweisung in /lang/german/german.php:
require(DIR_WS_LANGUAGES . $_SESSION['language'].'/'.'affiliate_german.php');
weil aber die Variable ($_SESSION['language']) über ipn.php nicht gesetzt wird, wird versucht /lang//affiliate_german.php zu laden, was es natürlich nicht gibt. Einen entsprechenden Post werde ich gleich im Modul verfassen.
Das hat die ipn.php komplett blockiert und zwar an einem Punkt BEVOR normalerweise die PayPal-Daten zu Testzwecken in eine Datei geschrieben werden. Weil aber die ipn.php beim direkten Aufruf eine weiße Seite zeigen SOLL, fällt niemandem dabei auf, dass es ja eine "weiße Seite" zeigt
Der nächste Punkt ist dann aber auch schon wieder eine Frage:
Der direkte Aufruf der Datei fördert jetzt einen Fehler in der xtc_php_mail.php zu Tage, nämlich
Class 'Smarty' not found in ... /inc/xtc_php_mail.inc.php on line 30
In der /includes/application_top_callback.php wurde die Zeile
require(DIR_WS_CLASSES . 'Smarty_2.6.22/Smarty.class.php');
Auskommentiert (und das gleich zweimal)
- ich habe da jetzt einfach
require_once (DIR_WS_CLASSES.'Smarty_2.6.27/Smarty.class.php');
eingefügt, wie es in der normalen /includes/application_top.php schon der Fall ist,
ist das so okay?
Jetzt kann auch die Email über den IPN-Fehler (PayPal IPN Invalid Process - entsteht bei ungültigen Daten wie bspw einem direkten Aufruf) verschickt werden.