Als Technologiepartner und Hoster mit dem betroffenen Kunden habe ich den Fehler nun mal analysiert und hoffe, dass der Fehler dadurch schnell mit einem Hotfix behoben werden kann, das
Ticket geschlossen werden kann und solche Fehler nicht mehr auftreten
@JTL: Bitte an Eure Entwickler weitergeben!
Die Lösung liegt eigentlich schon in den Zeilen, die bbfdesign schon geschickt hatte. Entscheidend sind folgende Zeilen:
"Error: Wrong parameters for Exception([string $message [, long $code [, Throwable $previous = NULL]]]) in"
und
/var/www/virtual/.../htdocs/includes/plugins/jtl_paypal/version/106/paymentmethod/class/PayPalPlus.class.php(569): Exception->__construct('Unhandled payme...', 'approved') #1
Das Plugin schmeisst in der Zeile 569 von htdocs/includes/plugins/jtl_paypal/version/106/paymentmethod/class/PayPalPlus.class.php eine Exception wie folgt:
throw new Exception('Unhandled payment state', $payment->getState());
Der Status des Payment Objektes ist vom Typ String und nicht vom Typ long, weshalb vor der Exception eine andere Exception "Wrong Parameters for Exception" geschmissen wird.
Gemäß "Upgrading to PHP 7, Davey, Shafik, 2016, O'Reilly" (echt gute Lektüre! Sehr empfehlenswert und gratis bei O'Reilly erhältlich) wird auf Seite 37 ff. beschrieben, dass alle internen Klassen (also auch die Exception Klasse) nun eine Exception schmeissen, wenn der Constructor fehlschlägt: Auch bei nicht übereinstimmenden Typen (string != long). Auf Seite 42 wird dies noch etwas vertieft. Auf Seite 42 findet sich dann der Hinweis, dass Standard PHP fatal errors (welcher der o.g. Fehler ist) nun als Exception geschmissen werden und auf Seite 43 dann der Hinweis, dass diese nicht mehr über den set_error_handler() abgefangen werden können.
Lange Rede kurzer Sinn: Vor PHP 7 wurde die Exception in Zeile 569 des o.g. Codes auch schon falsch aufgerufen und der Fehler string != long existierte damit in PHP < 7.0 auch schon. Allerdings führte dies bei PHP < 7.0 nur dazu, dass der Fehler durch den jtlErrorHandler (Zeile 40 htdocs/includes/error_handler.php) geschluckt wurde und nur in den Logdateien zu sehen war.
Das Plugin läuft dadurch an einer Stelle weiter, wo die Entwickler es aber durch den Aufruf der Exception beenden wollten.
Somit ist der hier diskutierte "Fehler" kein PHP 7.1 Fehler, sondern ein PHP >= 7 Fehler, bzw. ein PHP < 7 Fehler - Ab PHP 7 wird ja eine Exception geschmissen, nur nicht die, die die Entwickler eigentlich vorhatten zu schmeissen
.
Lösung des Problems: Korrektur der Zeile 569 in der Datei htdocs/includes/plugins/jtl_paypal/version/106/paymentmethod/class/PayPalPlus.class.php auf
throw new Exception('Unhandled payment state', 4711);
oder ähnliches. Der Parameter 2 des Constructors der Exception Klasse spiegelt nämlich nur einen durch den Entwickler definierbaren Fehlercode wieder, der zusammen mit der Exception-Message für den Entwickler eine schnelle Identifikation der Exception bieten soll. Der Status des Payment-Objektes ist der Exception-Klasse egal! Wenn dem Entwickler der Status wichtig ist, dann wäre so etwas denkbar:
throw new Exception('Unhandled payment state: '.$payment->getState(), 4711);
@JTL: Bitte prüft einmal, ob ihr diesen Fehler auch noch irgendwo anders eingebaut habt. Exceptions werden so selten geworfen, dass diese Fehler fast gar nicht auffallen.
Natürlich ändert das nichts an der Tatsache, dass ihr "created" als Status erwartet und "approved" erhaltet. Aber, wenn Ihr doch wisst, dass Paypal etwas an der Rückgabe verändert habt und "approved" für Euch auch OK ist, dann baut doch als Hoffix 2 in der Zeile davor einfach ein:
if ($payment->getState() != 'created' && $payment->getState() != 'approved') {
Ich hoffe, ich konnte irgendwie helfen und die Kuh ist bald vom Eis
