flyman30 Posted July 22, 2019 Share Posted July 22, 2019 Bonjour, suite à la mise à jour 1.7.5.2 -> 1.7.6.0 le module bancaire E-transaction plantait, en corrigeant la table ps_currency le module transmet les données à la banque, hélas la banque ne retourne pas la réponse "accepté ou non" donc PrestaShop ne mets pas à jour le paiement des commandes et les mails ne partent pas. J'ai regardé les logs de transaction et voilà ce que ça indique : Citation AH01071: Got error 'PHP message: PHP Fatal error: Uncaught Error: Call to a member function get() on null in /var/www/vhosts/pierre-sempe.com/httpdocs/classes/Tools.php:801\nStack trace:\n#0 /var/www/vhosts/pierre-sempe.com/httpdocs/classes/Tools.php(773): ToolsCore::getContextLocale(Object(Context))\n#1 /var/www/vhosts/pierre-sempe.com/httpdocs/classes/PaymentModule.php(421): ToolsCore::displayPrice(9.6, Object(Currency), false)\n#2 /var/www/vhosts/pierre-sempe.com/httpdocs/modules/etransactions/etransactions.php(925): PaymentModuleCore->validateOrder(1190, '2', 17.1, 'E-Transactions', 'Le paiement a \\xC3...', Array, NULL, false, '01e083d45ca21d3...')\n#3 /var/www/vhosts/pierre-sempe.com/httpdocs/modules/etransactions/classes/ETransactionsController.php(241): ETransactions->onMixedIPNSuccess(Object(Cart), Array)\n#4 /var/www/vhosts/pierre-sempe.com/httpdocs/modules/etransactions/index.php(69): ETransactionsController->ipnAction()\n#5 {main}\n thrown in /var/www/vhosts/pierre-sempe.com/httpdocs/classes/Tools.php on line 801\n' Une idée du problème? Ça commence à saouler grave ces mises à jour foireuses... Link to comment Share on other sites More sharing options...
tdf-mep Posted July 22, 2019 Share Posted July 22, 2019 Bonjour, Nous avons le même problème avec le module cmcicpaiement lors d'un paiement. Après mise à jour manuel de la table ps_currency ( numeric_iso_code & precision cf : https://github.com/PrestaShop/PrestaShop/issues/14608 ) qui à permis de résoudre une bonne partie des autres problèmes : Une erreur est levée lors de l'appel à ToolsCore::displayPrice => ToolsCore::getContextLocale(Object(Context)) [Mon Jul 22 11:03:34.953382 2019] [php7:error] [pid 1792] [client XX.XX.XX.XX:37428] PHP Fatal error: Uncaught Error: Call to a member function get() on null in /xxxxxxxxxxxx/public_html/classes/Tools.php:801\nStack trace:\n#0 /xxxxxxxxxxxx/public_html/classes/Tools.php(773): ToolsCore::getContextLocale(Object(Context))\n#1 /xxxxxxxxxxxx/public_html/classes/Notification.php(133): ToolsCore::displayPrice(31.35, Object(Currency), false)\n#2 /xxxxxxxxxxxx/public_html/classes/Notification.php(57): NotificationCore::getLastElementsIdsByType('order', '20821')\n#3 /xxxxxxxxxxxx/public_html/zzzzzzz/ajax.php(125): NotificationCore->getLastElements()\n#4 {main}\n thrown in /xxxxxxxxxxxx/public_html/classes/Tools.php on line 801, referer: https://www.yyyyyyyyyy.com/zzzzzzz/index.php?controller=AdminStats&token=2cf9909b77f74d62ff078e389febe409 [...] [Mon Jul 22 11:09:31.457138 2019] [php7:error] [pid 10243] [client XX.XX.XX.XX:43994] PHP Fatal error: Uncaught Error: Call to a member function get() on null in /xxxxxxxxxxxx/public_html/classes/Tools.php:801\nStack trace:\n#0 /xxxxxxxxxxxx/public_html/classes/Tools.php(773): ToolsCore::getContextLocale(Object(Context))\n#1 /xxxxxxxxxxxx/public_html/classes/PaymentModule.php(421): ToolsCore::displayPrice(4.9, Object(Currency), false)\n#2 /xxxxxxxxxxxx/public_html/modules/cmcicpaiement/validation.php(123): PaymentModuleCore->validateOrder(123246, '2', '9.60', 'CM-CIC P@iement', 'TPE: 6600893<br...', NULL, 1, true, 'd67985d7118f76f...')\n#3 {main}\n thrown in /xxxxxxxxxxxx/public_html/classes/Tools.php on line 801 [Mon Jul 22 11:09:33.208743 2019] [php7:error] [pid 10205] [client XX.XX.XX.XX:43996] PHP Fatal error: Uncaught Error: Call to a member function get() on null in /xxxxxxxxxxxx/public_html/classes/Tools.php:801\nStack trace:\n#0 /xxxxxxxxxxxx/public_html/classes/Tools.php(773): ToolsCore::getContextLocale(Object(Context))\n#1 /xxxxxxxxxxxx/public_html/classes/order/OrderHistory.php(513): ToolsCore::displayPrice(9.6, Object(Currency), false)\n#2 /xxxxxxxxxxxx/public_html/classes/order/OrderHistory.php(468): OrderHistoryCore->sendEmail(Object(Order), Array)\n#3 /xxxxxxxxxxxx/public_html/modules/cmcicpaiement/validation.php(109): OrderHistoryCore->addWithemail(true, Array)\n#4 {main}\n thrown in /xxxxxxxxxxxx/public_html/classes/Tools.php on line 801 Link to comment Share on other sites More sharing options...
flyman30 Posted July 22, 2019 Author Share Posted July 22, 2019 C'est quand même un scandale de publier des mises à jours de versions de Prestashop qui empêchent les paiements bancaires de fonctionner ! Les marchands ont autre choses à faire que d'installer des rustines sur les nouvelles versions de Prestashop. 2 Link to comment Share on other sites More sharing options...
flyman30 Posted July 22, 2019 Author Share Posted July 22, 2019 Suite à mes rapports de bugs, ceci devrait être réglé par la version 1.7.6.1 a venir... Je vais donc rétro pédaler vers la version 1.7.5.2 qui elle permet de vendre normalement Link to comment Share on other sites More sharing options...
tdf-mep Posted July 23, 2019 Share Posted July 23, 2019 La 14608 ne corrige qu'une partie des problèmes. La 14813 est clôturée (Duplicate of #14648) et la 14648 ne semble pas embarqué, pour l'instant, dans la 1.7.6.1 : https://github.com/PrestaShop/PrestaShop/milestone/56 J'espère que çà sera le cas (et qu'il n'y aura pas confusion entre ces différents rapport de bug) car ont est plutôt sur un bug majeur là ! NB : le module cmcicpaiement est développé par Prestashop Link to comment Share on other sites More sharing options...
digeek Posted July 23, 2019 Share Posted July 23, 2019 Bonjour, Nous avons aussi des soucis le Sogenactif 2.0 qui ne valide plus les commandes (statut inexistant malgré paiement ok) en 1.7.6.0 (je passe le soucis de la table ps_currency...) On essaie de débugger de notre côté. Link to comment Share on other sites More sharing options...
SuperPseudo1234 Posted July 23, 2019 Share Posted July 23, 2019 Bonjour à tous, Je rencontre les mêmes difficultés avec E-transaction (Crédit Agricole / Paybox). Après avoir corrigé la table ps_currency, je peux désormais passer des commandes mais ces dernières ne sont jamais validé. Et ce malgré le fait que les paiements sont bien effectués. Voici un lien vers mon topic: Link to comment Share on other sites More sharing options...
c00lsp0t Posted July 23, 2019 Share Posted July 23, 2019 (edited) Bonjour, Je viens de test avec le module de paiement cllicandpay du groupe crédit du nord et je n'ai pas de soucis. En regardant la ligne 801 (du fichier classes/Tools.php) entre la nouvelle versionne prestashop 1.7.6 et les ancienne version c'est du à la suppression de la librairie CLDR. Le display price en version 1.7.5 se retournait de cette manière $cldr = self::getCldr($context); return $cldr->getPrice($price, is_array($currency) ? $currency['iso_code'] : $currency->iso_code); Alors qu'en 1.7.6 c'est de cette manière : $locale = static::getContextLocale($context); $currencyCode = is_array($currency) ? $currency['iso_code'] : $currency->iso_code; return $locale->formatPrice($price, $currencyCode); en clair il retourne un prix formater suivant la locale de la nouvelle fonction getContextLocale. Pour un fix temporaire et dégueu il faudrait peut etre remplacer le $locale = static::getContextLocale($context); par un $locale = $context->getCurrentLocale(); Mais ca ne pourrait peut etre marcher que sur les boutique mono langue vu que la locale serait celle de la boutique et qu'un site multilangue prendrait la currentlocale et pas la contextLocale et donc ca merderai pour ces site la. Je vous avoue que je ne peut tester mes dire (vu que je n'ai pas ce soucis la) donc à prendre avec des pincettes mais peut etre que ca pourra vous avancer un peu Edited July 23, 2019 by c00lsp0t (see edit history) Link to comment Share on other sites More sharing options...
c00lsp0t Posted July 23, 2019 Share Posted July 23, 2019 Sinon j'approuve certain d'entre vous ce bug est proprement scandaleux et hélas ca donne du grain à moudre à ceux qui conseille de ne jamais mettre à jour son prestashop sauf à faire une refonte lors de version majeur (basculement de 1.6 a 1.7 par exemple) 1 Link to comment Share on other sites More sharing options...
flyman30 Posted July 24, 2019 Author Share Posted July 24, 2019 Il y a 7 heures, c00lsp0t a dit : Bonjour, Je viens de test avec le module de paiement cllicandpay du groupe crédit du nord et je n'ai pas de soucis. En regardant la ligne 801 (du fichier classes/Tools.php) entre la nouvelle versionne prestashop 1.7.6 et les ancienne version c'est du à la suppression de la librairie CLDR. Le display price en version 1.7.5 se retournait de cette manière $cldr = self::getCldr($context); return $cldr->getPrice($price, is_array($currency) ? $currency['iso_code'] : $currency->iso_code); Alors qu'en 1.7.6 c'est de cette manière : $locale = static::getContextLocale($context); $currencyCode = is_array($currency) ? $currency['iso_code'] : $currency->iso_code; return $locale->formatPrice($price, $currencyCode); en clair il retourne un prix formater suivant la locale de la nouvelle fonction getContextLocale. Pour un fix temporaire et dégueu il faudrait peut etre remplacer le $locale = static::getContextLocale($context); par un $locale = $context->getCurrentLocale(); Mais ca ne pourrait peut etre marcher que sur les boutique mono langue vu que la locale serait celle de la boutique et qu'un site multilangue prendrait la currentlocale et pas la contextLocale et donc ca merderai pour ces site la. Je vous avoue que je ne peut tester mes dire (vu que je n'ai pas ce soucis la) donc à prendre avec des pincettes mais peut etre que ca pourra vous avancer un peu Tu veux dire que c'est ce changement qui fait qu'on ne reçoit pas les validations de la banque ??? Link to comment Share on other sites More sharing options...
digeek Posted July 24, 2019 Share Posted July 24, 2019 Je viens de tester ton idée de fix (boutique mono langue), cela ne résout pas le soucis de validation des commandes. On a mis des logs un peu partout lors de la validation bancaire mais tout semble ok. Quelques éléments remarqués dans les logs lors d'une transaction. [Tue Jul 23 12:46:46.407490 2019] [:error] [pid 163123:tid 140027266819840] [client 160.92.133.135:19330] FastCGI: server "/home/clients/e4cb1ca1a4bb2cef9b6243f15067ebaeaz/.config/apache/www.domain.tld/.fpm/php5.external" stderr: PHP message: PHP Fatal error: Uncaught Error: Call to a member function get() on null in /home/clients/e4cb1ca1a4bb2cef9b6243f15067ebaeaz/www.domain.tld/www/classes/Tools.php:801 [Tue Jul 23 12:46:46.407519 2019] [:error] [pid 163123:tid 140027266819840] [client 160.92.133.135:19330] FastCGI: server "/home/clients/e4cb1ca1a4bb2cef9b6243f15067ebaeaz/.config/apache/www.domain.tld/.fpm/php5.external" stderr: #3/home/clients/e4cb1ca1a4bb2cef9b6243f15067ebaeaz/www.domain.tld/www/modules/worldline/validation.php(179): Worldline->validate('465', '2', 37.95) [Tue Jul 23 12:46:46.407517 2019] [:error] [pid 163123:tid 140027266819840] [client 160.92.133.135:19330] FastCGI: server "/home/clients/e4cb1ca1a4bb2cef9b6243f15067ebaeaz/.config/apache/www.domain.tld/.fpm/php5.external" stderr: #2/home/clients/e4cb1ca1a4bb2cef9b6243f15067ebaeaz/www.domain.tld/www/modules/worldline/worldline.php(762): PaymentModuleCore->validateOrder('465', '2', 37.95, 'Worldline', NULL, Array, NULL, false, '6c6619596a6b4e1...') Et les éléments loggués lors du test de ce matin 2019-07-24 08:33:24 : Data : captureDay=0|captureMode=AUTHOR_CAPTURE|currencyCode=978|merchantId=XXXXXXXXXXX|orderChannel=INTERNET|responseCode=00|transactionDateTime=2019-07-24T08:33:23+02:00|transactionReference=XXXXXXX|keyVersion=1|acquirerResponseCode=00|amount=925|authorisationId=12345|guaranteeIndicator=Y|cardCSCResultCode=4D|panExpiryDate=202101|paymentMeanBrand=MASTERCARD|paymentMeanType=CARD|[email protected]|customerIpAddress=XXX.XXX.XXX.XXX|maskedPan=5100##########00|holderAuthentRelegation=N|holderAuthentStatus=3D_SUCCESS|tokenPan=XXXXXXX|transactionOrigin=INTERNET|paymentPattern=ONE_SHOT|customerMobilePhone=null|mandateAuthentMethod=null|mandateUsage=null|transactionActors=null|mandateId=null|captureLimitDate=20190724|dccStatus=null|dccResponseCode=null|dccAmount=null|dccCurrencyCode=null|dccExchangeRate=null|dccExchangeRateValidity=null|dccProvider=null|statementReference=null|panEntryMode=MANUAL|walletType=null|holderAuthentMethod=NOT_SPECIFIED 2019-07-24 08:33:24 : Data : --== STATUT ==-- : $statut = 2 2019-07-24 08:33:24 : Data : --== responseCode = 00 ==-- : $statut = 2 2019-07-24 08:33:24 : Data : 3302855 ; 2 ; 925 2019-07-24 08:33:24 : Data : --== public function validate == $id_cart=330 ; $id_cart_key=330 2019-07-24 08:33:24 : Data : --== public function validateOrder == 2019-07-24 08:33:24 : Data : $id_cart = 330 | $id_order_state = 2 | $amount_paid = 9.25 | $this->displayName = Worldline | $this->displayName = Worldline | $customer->secure_key = XXXXXXXXXXXXXXXXXXXXXXXXXXXX Link to comment Share on other sites More sharing options...
flyman30 Posted July 24, 2019 Author Share Posted July 24, 2019 A c00lsp0t Peut-tu confirmer que la validation des paiement bancaire cllicandpay fonctionne pour toi après l'update 1.7.5.2 -> 1.7.6.0 ??? Si c'est le cas ce module fonctionne t'il avec PayBox ? Car si ce n'est pas le cas c'est peut-être PayBox le souci ... cmcicpaiement Sogenactif 2.0 E-Transaction Sont contrôlés par PayBox. Link to comment Share on other sites More sharing options...
c00lsp0t Posted July 24, 2019 Share Posted July 24, 2019 (edited) Bonjour, J'ai parlé un peu vite concernant mon module de paiement clicandpay. J'ai une errreur de notification d'url de retour (FAILED_SERVER_500_ERROR) qui m'a été envoyé par mon module de paiement à mon adresse email "technique" de mon site. Par contre lors du processus de commande par le client tout va bien c'est à dire qu'il peut faire le paiement et qu'il peut retourner à la boutique sans erreur en ayant finaliser sa commande. Il reçoit un email de confirmation de paiement par mon module de paiement mais pas de confirmation de commande. Et dans le backoffice j'ai bien la nouvelle commande avec le bon montant mais elle n'a pas de statut "confirmé". Il faut que je la passe manuellement à ce statut. Bref en fait j'ai le même problème que vous tous Edited July 24, 2019 by c00lsp0t (see edit history) Link to comment Share on other sites More sharing options...
Howie Posted July 24, 2019 Share Posted July 24, 2019 Bonjour, j'ai un problème de quelques commandes qui ne remontent pas dans le BO depuis quelques jours sur des paiements Paypal et CB (via Monetico CIC) sur un PS 1.7.5.2 : "PaymentModule::validateOrder - Secure key does not match" J'ai bien mes alertes dans le log du BO avec mes identifiants panier et date d'erreur. Pouvez-vous me dire quelle(s) méthode(s) vous utilisez pour logger les erreurs autrement que via le BO ? Les fichiers de log PHP ? Les logs via le site du mode de paiement ? Merci pour votre aide. Link to comment Share on other sites More sharing options...
c00lsp0t Posted July 24, 2019 Share Posted July 24, 2019 (edited) 1 hour ago, flyman30 said: A c00lsp0t Peut-tu confirmer que la validation des paiement bancaire cllicandpay fonctionne pour toi après l'update 1.7.5.2 -> 1.7.6.0 ??? Si c'est le cas ce module fonctionne t'il avec PayBox ? Car si ce n'est pas le cas c'est peut-être PayBox le souci ... cmcicpaiement Sogenactif 2.0 E-Transaction Sont contrôlés par PayBox. La validation de paiement se fait mais j'ai une erreur de retour de notification qui entraine sur mon back office prestashop un mauvais switch de status de la commande. Cependant lors du processus de paiement le client ne voit aucune erreur et peut payer normalement. Edited July 24, 2019 by c00lsp0t (see edit history) Link to comment Share on other sites More sharing options...
flyman30 Posted July 24, 2019 Author Share Posted July 24, 2019 J'ai fait une installation neuve de Prestashop j'ai juste ajouté le module E-Transaction, il se produit le même bug ! Une fois qu'on a rentré ses donnée de carte bancaire la banque affiche un ticket avec paiement accepté, puis une page PrestaShop affiche "attente de validation" puis cette page fait 10 tentative et enfin le front-office la boutique s'ouvre... Conclusion: Pas de commandes validé en paiement dans le BO, pas de mail au client, pas de mail au marchand. Tout va bien madame la marquise. Link to comment Share on other sites More sharing options...
flyman30 Posted July 24, 2019 Author Share Posted July 24, 2019 il y a 36 minutes, Howie a dit : Bonjour, j'ai un problème de quelques commandes qui ne remontent pas dans le BO depuis quelques jours sur des paiements Paypal et CB (via Monetico CIC) sur un PS 1.7.5.2 : "PaymentModule::validateOrder - Secure key does not match" J'ai bien mes alertes dans le log du BO avec mes identifiants panier et date d'erreur. Pouvez-vous me dire quelle(s) méthode(s) vous utilisez pour logger les erreurs autrement que via le BO ? Les fichiers de log PHP ? Les logs via le site du mode de paiement ? Merci pour votre aide. Monetico te signale que les clés de sécurité ne correspondent pas !!! Link to comment Share on other sites More sharing options...
flyman30 Posted July 24, 2019 Author Share Posted July 24, 2019 (edited) D'après les développeurs de PrestaShop ce serai nos modules qui seraient en cause... Ils m'ont demandés si le module e-transaction que j'utilisais était le module officiel vendu 200€ sur addon... Alors que celui fourni par le Crédit Agricole qui est gratuit à toujours fonctionné jusqu’à ce fameux update vers 1.7.6.0.... Je les soupçonne d'avoir modifié un truc qui empêche les modules non officiels de fonctionner. Ils ont testés : ps_wirepayment ps_checkpayment COD PayPal Avec succès Donc j'ai peu d'espoir de résolution. Edited July 24, 2019 by flyman30 (see edit history) Link to comment Share on other sites More sharing options...
c00lsp0t Posted July 24, 2019 Share Posted July 24, 2019 3 minutes ago, flyman30 said: D'après les développeurs de PrestaShop ce serai nos modules qui seraient en cause... Ils m'ont demandés si le module e-transaction que j'utilisais était le module officiel vendu 200€ sur addon... Alors que celui fourni par le Crédit Agricole qui est gratuit à toujours fonctionné jusqu’à ce fameux update vers 1.7.6.0.... Je les soupçonne d'avoir modifié un truc qui empêche les modules non officiels de fonctionner. Ils ont testés : ps_wirepayment ps_checkpayment COD PayPal Avec succès Donc j'ai peu d'espoir de résolution. Lol c'est du foutage de gueule. Mon module de paiement est fourni par ma banque sur leur site officiel et il n'est pas présent sur la boutique addon prestashop. Devoir faire un rollback en version 1.7.5.2 serait assez chiant parce que je perdrait 10 jours d'ajout de chose sur la base de données (modification de produits, etc...) Bref ce n'est pas envisageable. Quant à leur si je comprend bien c'est un test par paypal et deux paiement qui ne passe pas par des service tiers de banque (paiement cheque et virement bancaire). En plus c'est pas comme si un seul module merdait (et quand tu contacte les prestataire des module ils te disent bien que c'est pas eux mais prestashop le soucis vu qu'ils n'arrivent pas a envoyer la reponse sur ton prestashop et que chez eux ca se passe bien), mais la plupart des module de paiement merde. 1 Link to comment Share on other sites More sharing options...
digeek Posted July 24, 2019 Share Posted July 24, 2019 2 hours ago, Howie said: Bonjour, j'ai un problème de quelques commandes qui ne remontent pas dans le BO depuis quelques jours sur des paiements Paypal et CB (via Monetico CIC) sur un PS 1.7.5.2 : "PaymentModule::validateOrder - Secure key does not match" J'ai bien mes alertes dans le log du BO avec mes identifiants panier et date d'erreur. Pouvez-vous me dire quelle(s) méthode(s) vous utilisez pour logger les erreurs autrement que via le BO ? Les fichiers de log PHP ? Les logs via le site du mode de paiement ? Merci pour votre aide. Tu peux logguer tes données dans un fichier txt $logData = '--== hookOrderConfirmation ==--'; file_put_contents('debug_'.date("Ymd").'.txt', PHP_EOL.date("Y-m-d H:i:s").' : Data : '.$logData, FILE_APPEND); Link to comment Share on other sites More sharing options...
c00lsp0t Posted July 24, 2019 Share Posted July 24, 2019 Je viens un peu de check les log : En prestashop 1.7.5 les log d'un paiement réussi sont comme cela *INFO* v1.7.5.2 2019/06/27 - 20:31:39: Server call process starts for cart #74. *INFO* v1.7.5.2 2019/06/27 - 20:31:39: Payment accepted for cart #74. New order state is 2. *INFO* v1.7.5.2 2019/06/27 - 20:31:39: Create order for cart #74. *INFO* v1.7.5.2 2019/06/27 - 20:31:42: Order #15 created successfully for cart #74. *INFO* v1.7.5.2 2019/06/27 - 20:31:42: Save payment information for cart #74. *INFO* v1.7.5.2 2019/06/27 - 20:31:42: Payment information with ID(s) 24 saved successfully for cart #74. Alors qu'un paiement en 1.7.6 : *INFO* v1.7.6.0 2019/07/24 - 00:41:16: Server call process starts for cart #108. *INFO* v1.7.6.0 2019/07/24 - 00:41:16: Payment accepted for cart #108. New order state is 2. *INFO* v1.7.6.0 2019/07/24 - 00:41:16: Create order for cart #108. *INFO* v1.7.6.0 2019/07/24 - 00:41:26: User return to shop process starts for cart #108. *INFO* v1.7.6.0 2019/07/24 - 00:41:26: Order already registered for cart #108. *INFO* v1.7.6.0 2019/07/24 - 00:41:26: The current state for order corresponding to cart #108 is (0). *WARNING* v1.7.6.0 2019/07/24 - 00:41:26: Unknown order state ID (0) for cart #108. Managed by merchant. *INFO* v1.7.6.0 2019/07/24 - 00:41:26: Payment success for cart #108. Redirect to success page. En clair il y a un probleme dans le processus de creation de commande dans le BO apres le paiement du panier. Lorsque je vais dans le fichier validation.php de mon module j'ai cette fonction la qui correspond a des entré de mes log $logger->logInfo("Payment accepted for cart #$cart_id. New order state is $new_state."); $order = $clicandpay->saveOrder($cart, $new_state, $response); Et apres ca plus de log OK. C'est dans la creation de sauvegarde qu'il y a un pb depuis la 1.7.6. Lorsque je vais sur la methode saveOrder de mon module j'ai $this->logger->logInfo("Create order for cart #{$cart->id}."); // retrieve customer from cart $customer = new Customer((int)$cart->id_customer); $currency = ClicandpayApi::findCurrency($response->get('currency')); $decimals = $currency->getDecimals(); // PrestaShop id_currency from currency iso num code $currency_id = Currency::getIdByIsoCode($currency->getAlpha3()); // real paid total on gateway $paid_total = $currency->convertAmountToFloat($response->get('amount')); if (number_format($cart->getOrderTotal(), $decimals) == number_format($paid_total, $decimals)) { // to avoid rounding issues and bypass PaymentModule::validateOrder() check $paid_total = $cart->getOrderTotal(); } // call payment module validateOrder $this->validateOrder( $cart->id, $state, $paid_total, $response->get('order_info'), // title defined in admin panel and sent to gateway as order_info null, // $message array(), // $extraVars $currency_id, // $currency_special true, // $dont_touch_amount $customer->secure_key ); // reload order $order = new Order((int)Order::getOrderByCartId($cart->id)); $this->logger->logInfo("Order #{$order->id} created successfully for cart #{$cart->id}."); $this->createMessage($order, $response); $this->savePayment($order, $response); return $order; Donc le premier message de log est bien appellé dans mes log mais pas ce qui suit le $this->validateOrder. A savoir que cette méthode validateOrder correspond à la classe abstraite parente que mon module étend et qui est "/classes/PaymentModule.php Je pense que le soucis vient de cette méthode la depuis la 1.7.6. Mais j'avoue que j'ai pas de moyen facile pour faire un debug de ce methode Link to comment Share on other sites More sharing options...
c00lsp0t Posted July 24, 2019 Share Posted July 24, 2019 En faisant un comparatif de la méthode validateOrder du fichier de la classe PaymentModule.php on s'aperçoit que 2 grosse partie ont été réécrite : la première partie sur la construction de l'objet Order et la deuxième concernant les taxes. Il faudrait voir peut etre que si on mettait l'ancienne façon de valider la commande ca pourrait peut etre temporairement corriger ce bug. Ou tout du moins se limiter à la premiere partie qui concerne la construction de la commande. J'ai mis en PJ deux fichier : - La méthode validateOrder en 1.7.6 => file-new.php - La méthode validateOrder en 1.7.5.2 => file-old.php Et je pense que c'est cette partie qui doit merder avec nos module de paiement : Prestashop 1.7.5.2 : foreach ($package_list as $id_address => $packageByAddress) { foreach ($packageByAddress as $id_package => $package) { /** @var Order $order */ $order = new Order(); $order->product_list = $package['product_list']; if (Configuration::get('PS_TAX_ADDRESS_TYPE') == 'id_address_delivery') { $address = new Address((int) $id_address); $this->context->country = new Country((int) $address->id_country, (int) $this->context->cart->id_lang); if (!$this->context->country->active) { throw new PrestaShopException('The delivery address country is not active.'); } } $carrier = null; if (!$this->context->cart->isVirtualCart() && isset($package['id_carrier'])) { $carrier = new Carrier((int) $package['id_carrier'], (int) $this->context->cart->id_lang); $order->id_carrier = (int) $carrier->id; $id_carrier = (int) $carrier->id; } else { $order->id_carrier = 0; $id_carrier = 0; } $order->id_customer = (int) $this->context->cart->id_customer; $order->id_address_invoice = (int) $this->context->cart->id_address_invoice; $order->id_address_delivery = (int) $id_address; $order->id_currency = $this->context->currency->id; $order->id_lang = (int) $this->context->cart->id_lang; $order->id_cart = (int) $this->context->cart->id; $order->reference = $reference; $order->id_shop = (int) $this->context->shop->id; $order->id_shop_group = (int) $this->context->shop->id_shop_group; $order->secure_key = ($secure_key ? pSQL($secure_key) : pSQL($this->context->customer->secure_key)); $order->payment = $payment_method; if (isset($this->name)) { $order->module = $this->name; } $order->recyclable = $this->context->cart->recyclable; $order->gift = (int) $this->context->cart->gift; $order->gift_message = $this->context->cart->gift_message; $order->mobile_theme = $this->context->cart->mobile_theme; $order->conversion_rate = $this->context->currency->conversion_rate; $amount_paid = !$dont_touch_amount ? Tools::ps_round((float) $amount_paid, 2) : $amount_paid; $order->total_paid_real = 0; $order->total_products = (float) $this->context->cart->getOrderTotal(false, Cart::ONLY_PRODUCTS, $order->product_list, $id_carrier); $order->total_products_wt = (float) $this->context->cart->getOrderTotal(true, Cart::ONLY_PRODUCTS, $order->product_list, $id_carrier); $order->total_discounts_tax_excl = (float) abs($this->context->cart->getOrderTotal(false, Cart::ONLY_DISCOUNTS, $order->product_list, $id_carrier)); $order->total_discounts_tax_incl = (float) abs($this->context->cart->getOrderTotal(true, Cart::ONLY_DISCOUNTS, $order->product_list, $id_carrier)); $order->total_discounts = $order->total_discounts_tax_incl; $order->total_shipping_tax_excl = (float) $this->context->cart->getPackageShippingCost((int) $id_carrier, false, null, $order->product_list); $order->total_shipping_tax_incl = (float) $this->context->cart->getPackageShippingCost((int) $id_carrier, true, null, $order->product_list); $order->total_shipping = $order->total_shipping_tax_incl; if (!is_null($carrier) && Validate::isLoadedObject($carrier)) { $order->carrier_tax_rate = $carrier->getTaxesRate(new Address((int) $this->context->cart->{Configuration::get('PS_TAX_ADDRESS_TYPE')})); } $order->total_wrapping_tax_excl = (float) abs($this->context->cart->getOrderTotal(false, Cart::ONLY_WRAPPING, $order->product_list, $id_carrier)); $order->total_wrapping_tax_incl = (float) abs($this->context->cart->getOrderTotal(true, Cart::ONLY_WRAPPING, $order->product_list, $id_carrier)); $order->total_wrapping = $order->total_wrapping_tax_incl; $order->total_paid_tax_excl = (float) Tools::ps_round((float) $this->context->cart->getOrderTotal(false, Cart::BOTH, $order->product_list, $id_carrier), _PS_PRICE_COMPUTE_PRECISION_); $order->total_paid_tax_incl = (float) Tools::ps_round((float) $this->context->cart->getOrderTotal(true, Cart::BOTH, $order->product_list, $id_carrier), _PS_PRICE_COMPUTE_PRECISION_); $order->total_paid = $order->total_paid_tax_incl; $order->round_mode = Configuration::get('PS_PRICE_ROUND_MODE'); $order->round_type = Configuration::get('PS_ROUND_TYPE'); $order->invoice_date = '0000-00-00 00:00:00'; $order->delivery_date = '0000-00-00 00:00:00'; if (self::DEBUG_MODE) { PrestaShopLogger::addLog('PaymentModule::validateOrder - Order is about to be added', 1, null, 'Cart', (int) $id_cart, true); } // Creating order $result = $order->add(); if (!$result) { PrestaShopLogger::addLog('PaymentModule::validateOrder - Order cannot be created', 3, null, 'Cart', (int) $id_cart, true); throw new PrestaShopException('Can\'t save Order'); } // Amount paid by customer is not the right one -> Status = payment error // We don't use the following condition to avoid the float precision issues : http://www.php.net/manual/en/language.types.float.php // if ($order->total_paid != $order->total_paid_real) // We use number_format in order to compare two string if ($order_status->logable && number_format($cart_total_paid, _PS_PRICE_COMPUTE_PRECISION_) != number_format($amount_paid, _PS_PRICE_COMPUTE_PRECISION_)) { $id_order_state = Configuration::get('PS_OS_ERROR'); } $order_list[] = $order; if (self::DEBUG_MODE) { PrestaShopLogger::addLog('PaymentModule::validateOrder - OrderDetail is about to be added', 1, null, 'Cart', (int) $id_cart, true); } // Insert new Order detail list using cart for the current order $order_detail = new OrderDetail(null, null, $this->context); $order_detail->createList($order, $this->context->cart, $id_order_state, $order->product_list, 0, true, $package_list[$id_address][$id_package]['id_warehouse']); $order_detail_list[] = $order_detail; if (self::DEBUG_MODE) { PrestaShopLogger::addLog('PaymentModule::validateOrder - OrderCarrier is about to be added', 1, null, 'Cart', (int) $id_cart, true); } // Adding an entry in order_carrier table if (!is_null($carrier)) { $order_carrier = new OrderCarrier(); $order_carrier->id_order = (int) $order->id; $order_carrier->id_carrier = (int) $id_carrier; $order_carrier->weight = (float) $order->getTotalWeight(); $order_carrier->shipping_cost_tax_excl = (float) $order->total_shipping_tax_excl; $order_carrier->shipping_cost_tax_incl = (float) $order->total_shipping_tax_incl; $order_carrier->add(); } } } Prestashop 1.7.6 : foreach ($package_list as $id_address => $packageByAddress) { foreach ($packageByAddress as $id_package => $package) { $orderData = $this->createOrderFromCart( $this->context->cart, $this->context->currency, $package['product_list'], $id_address, $this->context, $reference, $secure_key, $payment_method, $this->name, $dont_touch_amount, $amount_paid, $package_list[$id_address][$id_package]['id_warehouse'], $cart_total_paid, self::DEBUG_MODE, $order_status, $id_order_state, isset($package['id_carrier']) ? $package['id_carrier'] : null ); $order = $orderData['order']; $order_list[] = $order; $order_detail_list[] = $orderData['orderDetail']; } } Sachant que la nouvelle méthode prestashop 1.7.6 "createorderFromCart fait ceci : protected function createOrderFromCart( Cart $cart, Currency $currency, $productList, $addressId, $context, $reference, $secure_key, $payment_method, $name, $dont_touch_amount, $amount_paid, $warehouseId, $cart_total_paid, $debug, $order_status, $id_order_state, $carrierId = null ) { $order = new Order(); $order->product_list = $productList; if (Configuration::get('PS_TAX_ADDRESS_TYPE') == 'id_address_delivery') { $address = new Address((int) $addressId); $context->country = new Country((int) $address->id_country, (int) $cart->id_lang); if (!$context->country->active) { throw new PrestaShopException('The delivery address country is not active.'); } } $carrier = null; if (!$cart->isVirtualCart() && isset($carrierId)) { $carrier = new Carrier((int) $carrierId, (int) $cart->id_lang); $order->id_carrier = (int) $carrier->id; $carrierId = (int) $carrier->id; } else { $order->id_carrier = 0; $carrierId = 0; } $order->id_customer = (int) $cart->id_customer; $order->id_address_invoice = (int) $cart->id_address_invoice; $order->id_address_delivery = (int) $addressId; $order->id_currency = $currency->id; $order->id_lang = (int) $cart->id_lang; $order->id_cart = (int) $cart->id; $order->reference = $reference; $order->id_shop = (int) $context->shop->id; $order->id_shop_group = (int) $context->shop->id_shop_group; $order->secure_key = ($secure_key ? pSQL($secure_key) : pSQL($context->customer->secure_key)); $order->payment = $payment_method; if (isset($name)) { $order->module = $name; } $order->recyclable = $cart->recyclable; $order->gift = (int) $cart->gift; $order->gift_message = $cart->gift_message; $order->mobile_theme = $cart->mobile_theme; $order->conversion_rate = $currency->conversion_rate; $amount_paid = !$dont_touch_amount ? Tools::ps_round((float) $amount_paid, _PS_PRICE_COMPUTE_PRECISION_) : $amount_paid; $order->total_paid_real = 0; $order->total_products = (float) $cart->getOrderTotal(false, Cart::ONLY_PRODUCTS, $order->product_list, $carrierId); $order->total_products_wt = (float) $cart->getOrderTotal(true, Cart::ONLY_PRODUCTS, $order->product_list, $carrierId); $order->total_discounts_tax_excl = (float) abs($cart->getOrderTotal(false, Cart::ONLY_DISCOUNTS, $order->product_list, $carrierId)); $order->total_discounts_tax_incl = (float) abs($cart->getOrderTotal(true, Cart::ONLY_DISCOUNTS, $order->product_list, $carrierId)); $order->total_discounts = $order->total_discounts_tax_incl; $order->total_shipping_tax_excl = (float) $cart->getPackageShippingCost($carrierId, false, null, $order->product_list); $order->total_shipping_tax_incl = (float) $cart->getPackageShippingCost($carrierId, true, null, $order->product_list); $order->total_shipping = $order->total_shipping_tax_incl; if (null !== $carrier && Validate::isLoadedObject($carrier)) { $order->carrier_tax_rate = $carrier->getTaxesRate(new Address((int) $cart->{Configuration::get('PS_TAX_ADDRESS_TYPE')})); } $order->total_wrapping_tax_excl = (float) abs($cart->getOrderTotal(false, Cart::ONLY_WRAPPING, $order->product_list, $carrierId)); $order->total_wrapping_tax_incl = (float) abs($cart->getOrderTotal(true, Cart::ONLY_WRAPPING, $order->product_list, $carrierId)); $order->total_wrapping = $order->total_wrapping_tax_incl; $order->total_paid_tax_excl = (float) Tools::ps_round((float) $cart->getOrderTotal(false, Cart::BOTH, $order->product_list, $carrierId), _PS_PRICE_COMPUTE_PRECISION_); $order->total_paid_tax_incl = (float) Tools::ps_round((float) $cart->getOrderTotal(true, Cart::BOTH, $order->product_list, $carrierId), _PS_PRICE_COMPUTE_PRECISION_); $order->total_paid = $order->total_paid_tax_incl; $order->round_mode = Configuration::get('PS_PRICE_ROUND_MODE'); $order->round_type = Configuration::get('PS_ROUND_TYPE'); $order->invoice_date = '0000-00-00 00:00:00'; $order->delivery_date = '0000-00-00 00:00:00'; if ($debug) { PrestaShopLogger::addLog('PaymentModule::validateOrder - Order is about to be added', 1, null, 'Cart', (int) $cart->id, true); } // Creating order $result = $order->add(); if (!$result) { PrestaShopLogger::addLog('PaymentModule::validateOrder - Order cannot be created', 3, null, 'Cart', (int) $cart->id, true); throw new PrestaShopException('Can\'t save Order'); } // Amount paid by customer is not the right one -> Status = payment error // We don't use the following condition to avoid the float precision issues : http://www.php.net/manual/en/language.types.float.php // if ($order->total_paid != $order->total_paid_real) // We use number_format in order to compare two string if ($order_status->logable && number_format($cart_total_paid, _PS_PRICE_COMPUTE_PRECISION_) != number_format($amount_paid, _PS_PRICE_COMPUTE_PRECISION_)) { $id_order_state = Configuration::get('PS_OS_ERROR'); } if ($debug) { PrestaShopLogger::addLog('PaymentModule::validateOrder - OrderDetail is about to be added', 1, null, 'Cart', (int) $cart->id, true); } // Insert new Order detail list using cart for the current order $order_detail = new OrderDetail(null, null, $context); $order_detail->createList($order, $cart, $id_order_state, $order->product_list, 0, true, $warehouseId); if ($debug) { PrestaShopLogger::addLog('PaymentModule::validateOrder - OrderCarrier is about to be added', 1, null, 'Cart', (int) $cart->id, true); } // Adding an entry in order_carrier table if (null !== $carrier) { $order_carrier = new OrderCarrier(); $order_carrier->id_order = (int) $order->id; $order_carrier->id_carrier = $carrierId; $order_carrier->weight = (float) $order->getTotalWeight(); $order_carrier->shipping_cost_tax_excl = (float) $order->total_shipping_tax_excl; $order_carrier->shipping_cost_tax_incl = (float) $order->total_shipping_tax_incl; $order_carrier->add(); } return ['order' => $order, 'orderDetail' => $order_detail]; } file-old.php file-new.php Link to comment Share on other sites More sharing options...
flyman30 Posted July 24, 2019 Author Share Posted July 24, 2019 Il y a 1 heure, c00lsp0t a dit : Lol c'est du foutage de gueule. Mon module de paiement est fourni par ma banque sur leur site officiel et il n'est pas présent sur la boutique addon prestashop. Devoir faire un rollback en version 1.7.5.2 serait assez chiant parce que je perdrait 10 jours d'ajout de chose sur la base de données (modification de produits, etc...) Bref ce n'est pas envisageable. Quant à leur si je comprend bien c'est un test par paypal et deux paiement qui ne passe pas par des service tiers de banque (paiement cheque et virement bancaire). En plus c'est pas comme si un seul module merdait (et quand tu contacte les prestataire des module ils te disent bien que c'est pas eux mais prestashop le soucis vu qu'ils n'arrivent pas a envoyer la reponse sur ton prestashop et que chez eux ca se passe bien), mais la plupart des module de paiement merde. Alors après bien des palabres sur github, ils ont enfin testé le module e-transaction que je leur ai fourni et bingo ils arrivent à la même constatation que nous, par contre pas de solutions pour le moment. regarde : https://github.com/PrestaShop/PrestaShop/issues/14648#issuecomment-514604816 Link to comment Share on other sites More sharing options...
c00lsp0t Posted July 24, 2019 Share Posted July 24, 2019 Bon finalement c'est peut etre pas ca non plus. En comparant la méthode createOrderFromCart avec la partie faisant la même chose en 1.7.5.2 c'est stricto la même chose. La seul différence est sur la ligne $amount_paid = !$dont_touch_amount ? Tools::ps_round((float) $amount_paid, 2) : $amount_paid; qui correspond en 1.7.6 : $amount_paid = !$dont_touch_amount ? Tools::ps_round((float) $amount_paid, _PS_PRICE_COMPUTE_PRECISION_) : $amount_paid; Ou la précision qui était inscrit en dur à 2 passe par la constance défini "_PS_PRICE_COMPUTE_PRECISION_" Bref je sèche me concernant. Si quelqu'un aurait une autre piste ? Link to comment Share on other sites More sharing options...
flyman30 Posted July 24, 2019 Author Share Posted July 24, 2019 Si je savais faire ça fait longtemps que je t'aurais aidé Link to comment Share on other sites More sharing options...
c00lsp0t Posted July 24, 2019 Share Posted July 24, 2019 5 minutes ago, flyman30 said: Si je savais faire ça fait longtemps que je t'aurais aidé J'ai un message en cours de validation modérateur se rapportant plus en détail à ce que j'ai recherché. C'est dommage je sens qu'on est pas loin du problème mais j'arrive pas à mettre la main dessus Link to comment Share on other sites More sharing options...
flyman30 Posted July 24, 2019 Author Share Posted July 24, 2019 Il y a quand même un peu d'espoir car le topic est passé en bug Majeur... Link to comment Share on other sites More sharing options...
c00lsp0t Posted July 24, 2019 Share Posted July 24, 2019 (edited) Dire que j'ai fait cette MAJ de version mineure parce que je voulais profiter du nouveau module d'avis client. Finalement peut etre bien que la règle des MAJ prestashop c'est : Pour une version 1.x vers 1.x+1 => Ne jamais mettre à jour, il faut faire une refonte complète Pour une version 1.x.y vers 1.x.y+1 => Procéder à la MAJ après 3 à 6 mois après la sortie ou du moins attendre une version 1.x.y+1.1 Pour une version 1.x.y.z vers 1.x.y.z+1 => On peut faire une MAJ sans sourciller vu que ce n'est que des correctif de bug. 🤣 Edited July 24, 2019 by c00lsp0t (see edit history) 1 1 Link to comment Share on other sites More sharing options...
SuperPseudo1234 Posted July 24, 2019 Share Posted July 24, 2019 Il semblerait que ce soit bien un problème causé par la 1.7.6. Du coup rétrogradage en 1.7.5.2 pour moi ! Link to comment Share on other sites More sharing options...
c00lsp0t Posted July 24, 2019 Share Posted July 24, 2019 Dans le backoffice de mon module de gestion de paiement CB l'erreur qu'il me sort dans le detail est : FAILED_SERVER_500_ERROR, rule=URL de notification à la fin du paiement, duration=~0,9s, response= null Pas super précis hélas Link to comment Share on other sites More sharing options...
flyman30 Posted July 24, 2019 Author Share Posted July 24, 2019 Ça a l'air de bouger chez Prestashop ... Citation jcpaybox commented 36 minutes ago • edited so far we still haven't found why the validateOrder process does not finish. debug seems to show that Tools::displayPrice could be the last function called, in the validateOrder method, when building the $product_var_tpl array. Contributor khouloudbelguith commented 7 minutes ago Citation Hi Adrien, I just received the module clicandpayhttps://drive.google.com/file/d/1VneFWdx6IsxeTX2IP97hDeDa9jQm9Yu3/view I checked it with PS1.7.6.0 & PS1.7.5.2 => I have issues. Thanks! Link to comment Share on other sites More sharing options...
flyman30 Posted July 24, 2019 Author Share Posted July 24, 2019 il y a 52 minutes, SuperPseudo1234 a dit : Il semblerait que ce soit bien un problème causé par la 1.7.6. Du coup rétrogradage en 1.7.5.2 pour moi ! J'aimerai bien faire pareil sauf que j'ai perdu les sauvegardes 1.7.5.2 il ne me reste que celle de le 1.7.6.0 pas de bol !! Link to comment Share on other sites More sharing options...
c00lsp0t Posted July 24, 2019 Share Posted July 24, 2019 6 minutes ago, flyman30 said: J'aimerai bien faire pareil sauf que j'ai perdu les sauvegardes 1.7.5.2 il ne me reste que celle de le 1.7.6.0 pas de bol !! Par contre c'est relou mon module de payment requiers des clé API sécurisé et donc en fournissant le module a la personne elle n'a pas pu faire le test. Je sais pas non plus ce que va répondre le fournisseur du module à ce sujet que j'ai contacté. Link to comment Share on other sites More sharing options...
flyman30 Posted July 24, 2019 Author Share Posted July 24, 2019 il y a 1 minute, c00lsp0t a dit : Par contre c'est relou mon module de payment requiers des clé API sécurisé et donc en fournissant le module a la personne elle n'a pas pu faire le test. Je sais pas non plus ce que va répondre le fournisseur du module à ce sujet que j'ai contacté. Oui j'ai lu son commentaire, e-transaction est fourni avec une clé pour les tests Link to comment Share on other sites More sharing options...
c00lsp0t Posted July 24, 2019 Share Posted July 24, 2019 Just now, flyman30 said: Oui j'ai lu son commentaire, e-transaction est fourni avec une clé pour les tests J'ai bien une cle de test mais c'est associé à ma boutique et à l'url de celle-ci donc je suis pas sur que ca puisse marcher Link to comment Share on other sites More sharing options...
flyman30 Posted July 24, 2019 Author Share Posted July 24, 2019 il y a 1 minute, c00lsp0t a dit : J'ai bien une cle de test mais c'est associé à ma boutique et à l'url de celle-ci donc je suis pas sur que ca puisse marcher Ha oui ça n'est pas pratique.. comme je te l'ai dit mon module est fourni préparer pour les tests pour passer en mode production il faut générer un clé hmac de prod et paramètrer pour la boutique. Link to comment Share on other sites More sharing options...
flyman30 Posted July 24, 2019 Author Share Posted July 24, 2019 (edited) Il y a 3 heures, c00lsp0t a dit : En faisant un comparatif de la méthode validateOrder du fichier de la classe PaymentModule.php on s'aperçoit que 2 grosse partie ont été réécrite : la première partie sur la construction de l'objet Order et la deuxième concernant les taxes. Il faudrait voir peut etre que si on mettait l'ancienne façon de valider la commande ca pourrait peut etre temporairement corriger ce bug. Ou tout du moins se limiter à la premiere partie qui concerne la construction de la commande. J'ai mis en PJ deux fichier : - La méthode validateOrder en 1.7.6 => file-new.php - La méthode validateOrder en 1.7.5.2 => file-old.php file-new.php Comment tu pense faire ces modifs ? je peut tester sur mon site de test au besoin. Edited July 24, 2019 by flyman30 (see edit history) Link to comment Share on other sites More sharing options...
c00lsp0t Posted July 24, 2019 Share Posted July 24, 2019 (edited) 2 hours ago, flyman30 said: Comment tu pense faire ces modifs ? je peut tester sur mon site de test au besoin. Je comptais faire un truc sale a base de copier l'ancienne methode pour l'ecraser dans la nouvelle methode dans le fichier PaymentModule.php. En gros dans le fichier /classes/PaymentModule.php remplacer la méthode validateOrder du fichier en 1.7.6 par celle contenu dans le fichier de l'archive prestashop 1.7.5.2 qu'on peut dl sur prestashop Mais quand j'ai regardé un comparatif ya pas tant que ca de diff en fait et donc je doute au final que ca vienne de cette partie la. (d'ou mon post d'apres ou je seche) Edited July 24, 2019 by c00lsp0t (see edit history) Link to comment Share on other sites More sharing options...
flyman30 Posted July 25, 2019 Author Share Posted July 25, 2019 J'ai testé ta solution, bien entendu ça ne fonctionne pas. Finalement ils commence à comprendre notre problème et à nous prendre au sérieux : https://github.com/PrestaShop/PrestaShop/issues/14648 Link to comment Share on other sites More sharing options...
tdf-mep Posted July 25, 2019 Share Posted July 25, 2019 (edited) Les paiements PayPal sont également impactés. J'ai vu vos différents commentaires sur https://github.com/PrestaShop/PrestaShop/issues/14648 . C'est quand même dingue que ce bug ne soit pas d'avantage priorisé (déclaré depuis 10 jours et toujours pas embarqué dans la prochaine release) : il s'agit quand même de la fonctionnalité de base d'une boutique e-commerce => pouvoir payer ses achats ! Edited July 25, 2019 by tdf-mep (see edit history) 1 Link to comment Share on other sites More sharing options...
digeek Posted July 25, 2019 Share Posted July 25, 2019 Nous avons du Paypal (en sandbox pour l'instant) sur la boutique qui rencontre le soucis des paiements. Les paiements réalisés sont bien validés (à contrario des paiements Sogenactif 2.0) Link to comment Share on other sites More sharing options...
c00lsp0t Posted July 25, 2019 Share Posted July 25, 2019 (edited) 29 minutes ago, digeek said: Nous avons du Paypal (en sandbox pour l'instant) sur la boutique qui rencontre le soucis des paiements. Les paiements réalisés sont bien validés (à contrario des paiements Sogenactif 2.0) Tu veut dire que sur sogenactif meme le paiement ne se valide pas ? Ce n'est pas comme nous avec un paiement validé sur le site bancaire mais avec un retour sur prestashop sans status de commande ou sans creation de commande ? Si c'est ca je t'invite si ce n'est pas déjà fait à poster tes log de Sogenactif sur le github du problème : https://github.com/PrestaShop/PrestaShop/issues/14648 Bref ce bug dans mon cas n'empeche pas le paiement mais reste quand même très problématique puisque il faut traiter en manuel la commande des reception de celle-ci pour lui changer de status et renvoyer les email au client. De mon point de vue c'est un problème critique qui devrait avoir la top priorité de fix. Edited July 25, 2019 by c00lsp0t (see edit history) Link to comment Share on other sites More sharing options...
digeek Posted July 25, 2019 Share Posted July 25, 2019 Je suis dans le même cas que tout le monde. Le paiement ne génère pas d'erreur, mais la commande se retrouve avec un statut 0 dans la bdd (et n'est donc pas validée). Link to comment Share on other sites More sharing options...
c00lsp0t Posted July 25, 2019 Share Posted July 25, 2019 Just now, digeek said: Je suis dans le même cas que tout le monde. Le paiement ne génère pas d'erreur, mais la commande se retrouve avec un statut 0 dans la bdd (et n'est donc pas validée). Ok. Le plus génant c'est que nous n'avons pas de solution de contournement à mettre en place le temps du fix. Même pas de "bidouille" meme "crade" pour faire fonctionner la chose le temps que ce problème soit corrigé. Link to comment Share on other sites More sharing options...
tdf-mep Posted July 25, 2019 Share Posted July 25, 2019 30 minutes ago, digeek said: Nous avons du Paypal (en sandbox pour l'instant) sur la boutique qui rencontre le soucis des paiements. Les paiements réalisés sont bien validés (à contrario des paiements Sogenactif 2.0) Pour PayPal : Erreur affiché au client (cf screenshot) Erreur de validation de la commande : The locale 2 is invalid. Votre paiement a été effectué. Contactez le Service clientèle. Paiement accepté (PayPal envoie un mail de confirmation) Dans le back office : état de la commande non mise à jour Je pensé qu'il s'agissait du même problème, mais après vérification, pas d'erreur dans les log serveur ToolsCore::displayPrice => ToolsCore::getContextLocale(Object(Context)) => peut être qu'il s'agit d'un autre problème, je vais creuser NB : test Paypal également réalisé après mise à jour manuel de la table ps_currency ( numeric_iso_code & precision cf : https://github.com/PrestaShop/PrestaShop/issues/14608 ) Pour CM-CIC P@iement (cf deuxième post de ce thread) : Paiement accepté Pas d'erreur affiché au client Dans les log serveur, visiblement comme sur beaucoup d'autre module de paiement, erreur ToolsCore::displayPrice => ToolsCore::getContextLocale(Object(Context)) Dans le back office : état de la commande non mise à jour NB : je ne suis pas sur que CM-CIC P@iement sont contrôlé par PayBox comme indiqué par plus haut dans ce thread par flyman30 Link to comment Share on other sites More sharing options...
digeek Posted July 25, 2019 Share Posted July 25, 2019 @tdf-mep > as tu pensé a modifier la colonne precision a 2 au lieu de 6 dans la table ps_currency ? Link to comment Share on other sites More sharing options...
tdf-mep Posted July 25, 2019 Share Posted July 25, 2019 Oui comme indiqué dans mon post précédent : Quote NB : test Paypal également réalisé après mise à jour manuel de la table ps_currency ( numeric_iso_code & precision cf : https://github.com/PrestaShop/PrestaShop/issues/14608 ) Link to comment Share on other sites More sharing options...
flyman30 Posted July 26, 2019 Author Share Posted July 26, 2019 Je pense que beaucoups de monde va être dans la mouise... cette réponse de dévelopeur fait peur, ça voudrait dire que pratiquement tous les modules de paiement bancaires ne sont pas adaptés au nouveau core de PrestShop.... Citation I think this comment points in the right direction. I don't have access to the module's source code, but it looks like they are using custom endpoints and side-stepping PrestaShop's router. This is a bad practice and is strongly discouraged because when you do that, things like this happen. Basically Tools now expects a certain environment to be available, in particular, it needs the service container to be initialized so that it can use the CLDR service to format prices. This environment is available whenever you use a PrestaShop controller, but not when accessing a module file directly (PS has no control over it). I'd suggest module developers to build a FrontController to handle validation instead of a custom endpoint like validation.php. To be clear: to my best understanding this issue must be addressed by module developers, it's not a bug in the core. Link to comment Share on other sites More sharing options...
c00lsp0t Posted July 26, 2019 Share Posted July 26, 2019 (edited) 9 minutes ago, flyman30 said: Je pense que beaucoups de monde va être dans la mouise... cette réponse de dévelopeur fait peur, ça voudrait dire que pratiquement tous les modules de paiement bancaires ne sont pas adaptés au nouveau core de PrestShop.... Oui cette réponse est vraiment relou. Ca veut dire qu'ils ne vont rien faire et mettre les développeurs de module en faute. Ca va aussi dépendre de la réactivité des developpeur de module sachant qu'on est en juillet. Après d'apres sa réponse ca pourrait ne pas etre si long à developper puisque ca serait changer le paradigme de validation.php qui n'est qu'un fichier php de code par l'ajout d'une classe validation qui etend la classe FrontController. Ensuite il faudrait mettre le code de validation.php dans une methode validate() par exemple et faire appel à cette méthode de la classe validation qui etend FrontController. (mais c'est cette partie qui risque d'etre plus tricky puisqu'il faudrait l'appeller au bon moment. Moment que je ne connais pas.) Ou alors il faudrait voir comment est articuler leur module de méthode de paiment de prestashop des cheque et viremant bancaire et faire la meme chose Edited July 26, 2019 by c00lsp0t (see edit history) Link to comment Share on other sites More sharing options...
c00lsp0t Posted July 26, 2019 Share Posted July 26, 2019 En gros dans le paiement par cheque il y a dans le dossier du module un fichier validation.php contenu dans controller/front/ Et ce fichier est sous la forme : class Ps_CheckpaymentValidationModuleFrontController extends ModuleFrontController { public function postProcess() { .....Code de validation } } Peut etre que notre solution est de modifier notre module creer ce front controller sous ce modele et foutre l'integralite du code de validation.php de notre module existant dans ce controller. Ensuite par contre il faut voir comment l'appeller. Link to comment Share on other sites More sharing options...
tdf-mep Posted July 26, 2019 Share Posted July 26, 2019 (edited) 2 hours ago, flyman30 said: Je pense que beaucoups de monde va être dans la mouise... cette réponse de dévelopeur fait peur, ça voudrait dire que pratiquement tous les modules de paiement bancaires ne sont pas adaptés au nouveau core de PrestShop.... C'est ni plus ni moins du grand n'importe quoi. On ne peut pas casser la compatibilité et bloquer autant de modules de paiement et ne rien vouloir faire pour les gens impactés. J'espère qu'il ne vont pas rester sur çà. Voici le début du code source de CMCICPaiement : <?php /** * 2007-2015 PrestaShop * * DISCLAIMER * * Do not edit or add to this file if you wish to upgrade PrestaShop to newer * versions in the future. If you wish to customize PrestaShop for your * needs please refer to http://www.prestashop.com for more information. * * @author PrestaShop SA <[email protected]> * @copyright 2007-2014 PrestaShop SA * @license http://addons.prestashop.com/en/content/12-terms-and-conditions-of-use * International Registered Trademark & Property of PrestaShop SA */ use PrestaShop\PrestaShop\Core\Payment\PaymentOption; class CMCICPaiement extends PaymentModule [...] public function __construct() { $this->name = 'cmcicpaiement'; $this->version = '3.0.4'; $this->page = basename(__FILE__, '.php'); $this->bootstrap = true; $this->author = 'PrestaShop'; Développé par Prestashop visiblement : pas de mise à jour disponible pour l'instant... Edited July 26, 2019 by tdf-mep (see edit history) 1 Link to comment Share on other sites More sharing options...
c00lsp0t Posted July 26, 2019 Share Posted July 26, 2019 res honnetement vu le nombre de module touché il pourrait faire un patch de rétro-compatibilité avec l'ancienne méthode sans le "container". Ca serait crade comme le dit le lead dev presta mais ca marcherai et ca permettrait au developpeur de module de leur laisser le temps de recoder leur méthode de validation "proprement" Link to comment Share on other sites More sharing options...
c00lsp0t Posted July 26, 2019 Share Posted July 26, 2019 (edited) Bon j'ai essayer de créer un FrontController dans controllers/front en l'appellant validation. php et ayant le code suivant : class ClicandpayValidationModuleFrontController extends ModuleFrontController { /** * @see FrontController::postProcess() */ public function postProcess() { /* module logger object */ $logger = ClicandpayTools::getLogger(); $save_on_failure = true; if (ClicandpayTools::checkRestIpnValidity()) { $test_mode = Configuration::get('CLICANDPAY_MODE') === 'TEST'; $sha_key = $test_mode ? Configuration::get('CLICANDPAY_STD_PRIVKEY_TEST') : Configuration::get('CLICANDPAY_STD_PRIVKEY_PROD'); /* use direct post content to avoid stipslashes from json data */ $data = $_POST; if (!ClicandpayTools::checkHash($data, $sha_key)) { $ip = Tools::getRemoteAddr(); $logger->logError("{$ip} tries to access validation.php page without valid signature with data: " . print_r($data, true)); die('<span style="display:none">KO-An error occurred while computing the signature.' . "\n" . '</span>'); } $answer = json_decode($data['kr-answer'], true); if (!is_array($answer)) { $logger->logError('Invalid REST IPN request received. Content of kr-answer: ' . $data['kr-answer']); die('<span style="display:none">KO-Invalid IPN request received.' . "\n" . '</span>'); } $save_on_failure &= isset($answer['orderCycle']) && ($answer['orderCycle'] === 'CLOSED'); /* wrap payment result to use traditional order creation tunnel */ $data = ClicandpayTools::convertRestResult($answer); $cart_id = (int) $data['vads_order_id']; /* shopping cart object */ $cart = new Cart($cart_id); require_once _PS_MODULE_DIR_ . 'clicandpay/classes/ClicandpayResponse.php'; /* patch for unrecieved metadata field */ if (!isset($data['vads_order_info'])) { $payment = new ClicandpayStandardPayment(); $data['vads_order_info'] = $payment->getTitle($cart->id_lang); } /** @var ClicandpayResponse $response */ $response = new ClicandpayResponse($data, null, null, null); } elseif (ClicandpayTools::checkFormIpnValidity()) { $cart_id = (int) Tools::getValue('vads_order_id'); /* shopping cart object */ $cart = new Cart($cart_id); require_once _PS_MODULE_DIR_ . 'clicandpay/classes/ClicandpayResponse.php'; /** @var ClicandpayResponse $response */ $response = new ClicandpayResponse( $_POST, Configuration::get('CLICANDPAY_MODE'), Configuration::get('CLICANDPAY_KEY_TEST'), Configuration::get('CLICANDPAY_KEY_PROD'), Configuration::get('CLICANDPAY_SIGN_ALGO') ); /* check the authenticity of the request */ if (!$response->isAuthentified()) { $ip = Tools::getRemoteAddr(); $logger->logError("{$ip} tries to access validation.php page without valid signature with data: " . print_r($_POST, true)); $logger->logError('Signature algorithm selected in module settings must be the same as one selected in gateway Back Office.'); die($response->getOutputForGateway('auth_fail')); } } else { $logger->logError('Invalid IPN request received. Content: ' . print_r($_POST, true)); die('<span style="display:none">KO-Invalid IPN request received.' . "\n" . '</span>'); } $logger->logInfo("Server call process starts for cart #$cart_id."); /* cart errors */ if (!Validate::isLoadedObject($cart)) { $logger->logError("Cart #$cart_id not found in database."); die('<span style="display:none">KO-Order not found.' . "\n" . '</span>'); } elseif ($cart->nbProducts() <= 0) { $logger->logError("Cart #$cart_id was emptied before redirection."); die('<span style="display:none">KO-Empty cart detected before order processing.' . "\n" . '</span>'); } /* rebuild context */ if (isset($cart->id_shop)) { $_GET['id_shop'] = $cart->id_shop; Context::getContext()->shop = Shop::initialize(); } Context::getContext()->customer = new Customer((int) $cart->id_customer); Context::getContext()->customer->logged = 1; Context::getContext()->cart = $cart = new Cart((int) $cart_id); // reload cart to take into account customer group $address = new Address((int) $cart->id_address_invoice); Context::getContext()->country = new Country((int) $address->id_country); Context::getContext()->language = new Language((int) $cart->id_lang); Context::getContext()->currency = new Currency((int) $cart->id_currency); Context::getContext()->link = new Link(); /* module main object */ $clicandpay = new Clicandpay(); /* search order in db */ $order_id = Order::getOrderByCartId($cart_id); if ($order_id === false) { /* order has not been processed yet */ $new_state = (int) Clicandpay::nextOrderState($response); if ($response->isAcceptedPayment()) { $logger->logInfo("Payment accepted for cart #$cart_id. New order state is $new_state."); $order = $clicandpay->saveOrder($cart, $new_state, $response); if (Clicandpay::hasAmountError($order)) { /* amount paid not equals initial amount. */ $msg = "Error: amount paid {$order->total_paid_real} is not equal to initial amount {$order->total_paid}."; $msg .= " Order is in a failed state, cart #$cart_id."; $logger->logWarning($msg); die($response->getOutputForGateway('ko', 'Total paid is different from order amount.')); } else { /* response to server */ die($response->getOutputForGateway('payment_ok')); } } else { /* payment KO */ $logger->logInfo("Payment failed for cart #$cart_id."); $save_on_failure &= (Configuration::get('CLICANDPAY_FAILURE_MANAGEMENT') === ClicandpayTools::ON_FAILURE_SAVE); if ($save_on_failure || Clicandpay::isOney($response)) { /* save on failure option is selected or Oney payment */ $msg = Clicandpay::isOney($response) ? 'FacilyPay Oney payment' : 'Save on failure option is selected'; $logger->logInfo("$msg : save failed order for cart #$cart_id. New order state is $new_state."); $order = $clicandpay->saveOrder($cart, $new_state, $response); die($response->getOutputForGateway('payment_ko')); } else { die($response->getOutputForGateway('payment_ko_bis')); } } } else { /* order already registered */ $logger->logInfo("Order #$order_id already registered for cart #$cart_id."); $order = new Order((int) $order_id); $old_state = (int) $order->getCurrentState(); $logger->logInfo("The current state for order corresponding to cart #$cart_id is ($old_state)."); /* check if a total refund of order was made */ $total_refund = false; if ($response->get('operation_type') === 'CREDIT') { $currency = ClicandpayApi::findCurrency($response->get('currency')); $decimals = $currency->getDecimals(); $paid_total = $currency->convertAmountToFloat($response->get('amount')); if (number_format($order->total_paid_real, $decimals) === number_format($paid_total, $decimals)) { $total_refund = true; } } $outofstock = Clicandpay::isOutOfStock($order); $new_state = (int) Clicandpay::nextOrderState($response, $total_refund, $outofstock); /* final states */ $consistent_states = array( 'PS_OS_OUTOFSTOCK_PAID', // override paid state since PrestaShop 1.6.1 'CLICANDPAY_OS_PAYMENT_OUTOFSTOCK', // paid state for PrestaShop < 1.6.1 'PS_OS_PAYMENT', 'CLICANDPAY_OS_TRANS_PENDING', 'PS_OS_REFUND', 'PS_OS_CANCELED', ); /* if the payment is not the first in sequence, do not update order state */ $first_payment = ($response->get('sequence_number') === '1') || !$response->get('sequence_number'); if (($old_state === $new_state) || !$first_payment) { /* no changes, just display a confirmation message */ $logger->logInfo("No state change for order associated with cart #$cart_id, order remains in state ({$old_state})."); $clicandpay->savePayment($order, $response); $clicandpay->createMessage($order, $response); if ($response->isAcceptedPayment()) { $msg = 'payment_ok_already_done'; } else { $msg = 'payment_ko_already_done'; } die($response->getOutputForGateway($msg)); } elseif (Clicandpay::isPaidOrder($order) && (!Clicandpay::isStateInArray($new_state, $consistent_states) || ($response->get('url_check_src') === 'PAY'))) { /* order cannot move from final paid state to not completed states */ $logger->logInfo("Order is successfully registered for cart #$cart_id but platform returns a payment error, transaction status is {$response->getTransStatus()}."); die($response->getOutputForGateway('payment_ko_on_order_ok')); } elseif (!$old_state || Clicandpay::isStateInArray($old_state, Clicandpay::getManagedStates())) { if (($old_state === Configuration::get('PS_OS_ERROR')) && $response->isAcceptedPayment() && Clicandpay::hasAmountError($order)) { /* amount paid not equals initial amount. */ $msg = "Error: amount paid {$order->total_paid_real} is not equal to initial amount {$order->total_paid}."; $msg .= " Order is in a failed state, cart #$cart_id."; $logger->logWarning($msg); die($response->getOutputForGateway('ko', 'Total paid is different from order amount.')); } if (!$old_state) { $logger->logWarning("Current order state for cart #$cart_id is empty! Something went wrong. Try to set it anyway."); } $clicandpay->setOrderState($order, $new_state, $response); $logger->logInfo("Order is successfully updated for cart #$cart_id."); die($response->getOutputForGateway($response->isAcceptedPayment() ? 'payment_ok' : 'payment_ko')); } else { $logger->logWarning("Unknown order state ID ($old_state) for cart #$cart_id. Managed by merchant."); die($response->getOutputForGateway('ok', 'Unknown order status.')); } } } } En fait j'ai repris le code présent dans mon validation.php à la racine du module et je l'ai mis dans la méthode postProcess. J'ai fait ca parce que dans le module prestashop ps_wirepayment c'est un peu dans ce style la le code de validation.php à la racinne du module est repris dans le front controller validation qu'il nomme le nom du moduleValidationModuleFrontController J'ai aussi ajouter dans le constructeur de la class main de mon module le nouveau frontcontroller $this->controllers = array(..... 'validation'); Et bien malgré cela j'ai strictement les meme erreur à savoir que le paiement se fait bien mais la commande dans le BO n'a pas de status et j'ai une erreur de notification de retour de paiement sur le backoffice de mon module de paiement. Les log sont aussi identique. Donc soit j'ai oublié quelquechose soit ce n'est pas le seul pb qu'il y a concernant ce problème de paiement. Bon j'ai tenté d'expliquer en anglais ma démarche sur le topic de bug prestashop du github : https://github.com/PrestaShop/PrestaShop/issues/14648 En espérant que je me fasse comprendre. Edited July 27, 2019 by c00lsp0t (see edit history) Link to comment Share on other sites More sharing options...
Recommended Posts