Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Bank payment modules are in error with version 1.7.6.0 #14648

Closed
flyman30 opened this issue Jul 15, 2019 · 57 comments

Comments

@flyman30
Copy link

commented Jul 15, 2019

Hello, I was in
Prestashop version 1.7.5.2
Debian Server 3.16.51-3
Apache
Php 5.6.36
MySql 10.0.32-MariaDB-0 + deb8u1
E-transaction payment module

Update to 1.7.6.0 successful but the card payment module An error appears when trying to pay:

https://tpeweb.e-transactions.fr/cgi/MYchoix_pagepaiement.cgi
Protection error.
We regret not being able to give a favorable answer to your request for payment.

Back to PrestaShop 1.7.5.2 and there the module works!
For info on the French forum of PrestShop another member with a similar problem:
For information, I have a similar concern with the payment module systemPay.

I have a 500 error calling the notification url

@mariem-abid

This comment has been minimized.

Copy link

commented Jul 15, 2019

Hi @flyman30,

Could you please provide us with more info? We need more details to understand how we can reproduce your issue:

  • host
  • server setup and configuration
  • PrestaShop version (source)
  • debug mode report
  • PHP error logs
  • apache error log
  • javascript console log
  • screenshots

Don't you know how to get this information? Please read the following article:
http://build.prestashop.com/howtos/misc/how-to-create-bug-report/

Thanks!

@flyman30

This comment has been minimized.

Copy link
Author

commented Jul 15, 2019

@khouloudbelguith

This comment has been minimized.

Copy link
Contributor

commented Jul 16, 2019

Hi @flyman30,

In your shop, I did not manage to reproduce the issue using "Payer par chèque".
https://drive.google.com/file/d/1TtGjTaBz8zRAlsmzPpH_WFPedVv0xLUn/view
About the other payment modules, have you tried to contact the module's author about this issue, if you need an update for those modules for the new release PS1.7.6.0?

Thanks to check with them & feedback.

@flyman30

This comment has been minimized.

Copy link
Author

commented Jul 16, 2019

@flyman30

This comment has been minimized.

Copy link
Author

commented Jul 16, 2019

In debug mode i have this,

`[PrestaShopDatabaseException]
Table 'boutique.ps_aninstagram' doesn't exist

SELECT m.id_insta, m.position
FROM ps_aninstagram m
WHERE m.id_shop = 1
AND active = 1
AND m.id_shop = 1
GROUP BY m.id_insta

at line 769 in file classes/db/Db.php
764. if ($webservice_call && $errno) {
765. $dbg = debug_backtrace();
766. WebserviceRequest::getInstance()->setError(500, '[SQL Error] ' . $this->getMsgError() . '. From ' . (isset($dbg[3]['class']) ? $dbg[3]['class'] : '') . '->' . $dbg[3]['function'] . '() Query was : ' . $sql, 97);
767. } elseif (PS_DEBUG_SQL && $errno && !defined('PS_INSTALLATION_IN_PROGRESS')) {
768. if ($sql) {
769. throw new PrestaShopDatabaseException($this->getMsgError() . '

' . $sql . '
');
770. }
771.
772. throw new PrestaShopDatabaseException($this->getMsgError());
773. }
774. }
DbCore->displayError - [line 385 - classes/db/Db.php] - [1 Arguments]
DbCore->query - [line 613 - classes/db/Db.php] - [1 Arguments]
DbCore->executeS - [line 202 - modules/aninstagramfeed/classes/insta.php] - [2 Arguments]
Insta::getHooks - [line 464 - modules/aninstagramfeed/aninstagramfeed.php]
Aninstagramfeed->__call - [line 970 - classes/Hook.php] - [2 Arguments]
HookCore::coreCallHook - [line 355 - classes/Hook.php] - [3 Arguments]
HookCore::callHookOn - [line 907 - classes/Hook.php] - [3 Arguments]`

@khouloudbelguith

This comment has been minimized.

Copy link
Contributor

commented Jul 16, 2019

@flyman30, this issue occurs due to the aninstagramfeed module.
Have you tried to contact the module author about this issue?

Thanks!

@Quetzacoalt91

This comment has been minimized.

Copy link
Member

commented Jul 16, 2019

The original issue may be related to #14608.

When we upgrade to 1.7.6.0, prices are displayed with 6 decimals, which could explain why payment modules can't work after an upgrade.

@123monsite-regis

This comment has been minimized.

Copy link
Contributor

commented Jul 23, 2019

hi ,

we have similar issues with bank modules, the error is :

stderr: thrown in public_html/classes/Tools.php on line 801 stderr: #3 {main} stderr: #2 modules/XXXX/validation.php(123) PaymentModule->validateOrder stderr: #0 classes/Tools.php(773): ToolsCore::getContextLocale(Object(Context)) stderr: PHP message: PHP Fatal error: Uncaught Error: Call to a member function get() on null in classes/Tools.php:801

this seem due to modules using /module/Mybank/valdation.php to notifiy the transactions , whithout a clean front controller there is no controller on : https://github.com/PrestaShop/PrestaShop/blob/1.7.6.x/classes/Tools.php#L801

$container = isset($context->controller) ? $context->controller->getContainer() : null;
        if (null === $container) {
            $container = SymfonyContainer::getInstance();
        }
        /** @var LocaleRepository $localeRepository */
        $localeRepository = $container->get(self::SERVICE_LOCALE_REPOSITORY);
        $locale = $localeRepository->getLocale(
            $context->language->getLocale()
        );`

i does not know if the core prestashop has to correct this or modules editors ?

regards

@flyman30

This comment has been minimized.

Copy link
Author

commented Jul 23, 2019

Pending the correction of the future 1.7.6.1 how do we sell?
Do you have any corrections that we could make on our shop that were in 1.7.5.2 update in 1.7.6.0? The corrections of the ps_currency table have solved a small part of the problem, when did the correction of the non-validation in prestashop of the bank's returns?

@khouloudbelguith

This comment has been minimized.

Copy link
Contributor

commented Jul 23, 2019

@123monsite-regis, in your Database, table ps_currency, thanks to change the precision from 6 to 2.
Thanks to check & feedback.

@jojocarofr

This comment has been minimized.

Copy link

commented Jul 23, 2019

Bonjour
Le meme bug avec systempay , j'ai fait les modifs sur ps_currency et ca ne fonctionne pas j'ai une erreur lors de la validation de l'achat
Merci de vos aides

@khouloudbelguith

This comment has been minimized.

Copy link
Contributor

commented Jul 24, 2019

Hi @flyman30, @jojocarofr,

Could you please try to check if you have the same issue with PS1.7.6.0 fresh install?

Thanks!

@flyman30

This comment has been minimized.

Copy link
Author

commented Jul 24, 2019

J'utilise le module E-transaction 3.0.12 fournit par ma banque depuis que j'ai une boutique Prestashop (1.7.0.1) sans aucun soucis.
Ce n'est pas le module qui est en cause puisque TOUS les modules de paiement bancaire semble impactés !

  • E-Transaction
  • cmcicpaiement
  • Sogenactif 2.0
  • clicandpay
    etc...

Il faut comprendre pourquoi cette version PrestaShop présente un bug majeur dans la réception des validations bancaire

exemple :
https://www.prestashop.com/forums/topic/997100-validation-commande-impossible-avec-e-transaction-paybox/
https://www.prestashop.com/forums/topic/997001-suite-mise-%C3%A0-jour-1752-1760-les-retours-bancaire-ne-se-font-pas/?tab=comments#comment-3138391

@flyman30

This comment has been minimized.

Copy link
Author

commented Jul 24, 2019

Voila les log de PayBox pour un essai de transaction par E-transaction

Voici les logs du retour IPN de votre transaction :

Jul 22 11:00:01 pbxprwb24 PayboxIPN.cgi[63522]: (INF) - Contact de l'URL en POST : https://*****.com/modules/etransactions/index.php?t=s&a=i - Donnees : M=1710&R
=1190%20-%20patrick%20Planul&T=524982735&A=446555&B=0&C=Visa&D=2106&E=00000&F=Y&G=O&I=FRA&J=--&N=------&O=Y&P=3DSECURE&Q=10%3A59%3A17&S=114349215&W=22072019&Y=FRA&Z=0-0&K=u
X9XAj%2F6sRLy6n1p3WEHKfLIUlsorlkcq6Lygs8f7y1WHaADP3T5DFf59H%2BeX0mRecz1RDRtMXiYN5jF2zykTE4o40hjgzbsbuz1w3LsaDwwnUUWh4jgtG4dkdIB7LA1zdhwpUAQLDz9bFYj5FpZXgY5JC0lU6n2%2BySOXYy
Nup4%3D
Jul 22 11:00:01 pbxprwb24 PayboxIPN.cgi[63522]: (INF) - Resolution DNS IPV4
Jul 22 11:00:01 pbxprwb24 PayboxIPN.cgi[63522]: (INF) - Utilisation de la version SSL par défaut
Jul 22 11:00:01 pbxprwb24 PayboxIPN.cgi[63522]: (INF) - Liste des ciphers SSL forces : RC4-MD5:RC4-SHA:DHE-RSA-AES256-SHA:DES-CBC3-SHA:AES128-SHA:DHE-RSA-AES128-SHA:ECDHE-R
SA-AES128-SHA:ECDHE-RSA-AES256-SHA384:ECDHE-ECDSA-AES256-SHA384:ECDHE-ECDSA-AES128-SHA256:ECDHE-ECDSA-AES128-GCM-SHA256:ECDHE-RSA-AES256-GCM-SHA384:ECDHE-RSA-AES128-SHA256:
ECDHE-RSA-AES128-GCM-SHA256:+ALL
Jul 22 11:00:01 pbxprwb24 PayboxIPN.cgi[63522]: (INF) - Utilisation de libcurl v7.53.1
Jul 22 11:00:11 pbxprwb24 PayboxIPN.cgi[63522]: (ERR) - Erreur de connexion - essai 1 : (code http: 500 - code curl: 0)
Jul 22 11:00:21 pbxprwb24 PayboxIPN.cgi[63522]: (INF) - https://****.com/modules/etransactions/index.php?t=s&a=i - Succes

@khouloudbelguith

This comment has been minimized.

Copy link
Contributor

commented Jul 24, 2019

Hi @flyman30,

In my case I tried with those modules:

  • ps_wirepayment
  • ps_checkpayment
  • COD
  • PayPal

They are ok, there is no issue reproduced.

Thanks!

@flyman30

This comment has been minimized.

Copy link
Author

commented Jul 24, 2019

cmcicpaiement
Sogenactif 2.0
E-Transaction
clicandpay

Send validation data but it is not validated by Prestashop 1.7.6.0 !

Here is the e-transaction module for test

prestashop-1.5.x-1.6.x-1.7.x-etransactions-3.0.12.zip

@flyman30

This comment has been minimized.

Copy link
Author

commented Jul 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

| 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. | 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. | $logger->logInfo("Payment accepted for cart #$cart_id. New order state is $new_state."); $order = $clicandpay->saveOrder($cart, $new_state, $response); | $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;
-- | -- | -- | -- | --
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.
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.
$logger->logInfo("Payment accepted for cart #$cart_id. New order state is $new_state."); $order = $clicandpay->saveOrder($cart, $new_state, $response);
$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;

@khouloudbelguith

This comment has been minimized.

Copy link
Contributor

commented Jul 24, 2019

@flyman30, I tried with your module & PS1.7.6.0 & PS1.7.5.2, in the FO => OK
https://drive.google.com/file/d/16w2ocol3AiSujkhA7z42SnS2CfIIuLvt/view & the email is sent => but in the back office there is no order created

Thanks!

@flyman30

This comment has been minimized.

Copy link
Author

commented Jul 24, 2019

184/5000
I am glad that you have tested the e-transaction module, with prestashop 1.7.5.2 the order is validated in BO but not in 1.7.6.0.
What do you think, can you do something?

@marionf marionf added Major 1.7.6.0 and removed 1.7.5.2 labels Jul 24, 2019

@khouloudbelguith

This comment has been minimized.

Copy link
Contributor

commented Jul 26, 2019

Hi all,

As discussed with @webmastercoolspot, I'm trying to reproduce the issue with clicandpay module.
So, I need to discuss with the support team: https://clicandpay.groupecdn.fr/doc/fr-FR/support/
to get an account test for me to reproduce the issue with a key test and account test.

Thanks for your understanding!

@flyman30

This comment has been minimized.

Copy link
Author

commented Jul 26, 2019

I thought you understood that ALL payment modules have the same problems ie Prestashop 1.7.6.0 does not understand the return of acceptance of payments that the banks transmit.
It is urgent that the developers look for the cause as soon as possible!

@webmastercoolspot

This comment has been minimized.

Copy link

commented Jul 26, 2019

Yes it's not only me and clicandpay

I hope it will be fixed as soon as possible

Thx :)

@eternoendless

This comment has been minimized.

Copy link
Member

commented Jul 26, 2019

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.

@flyman30

This comment has been minimized.

Copy link
Author

commented Jul 26, 2019

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.

That would mean that virtually ALL bank payment modules are obsolete because they would no longer meet the standards imposed by PrestaShop ???
Thank you for all the shops impacted by this change, a change whose suppliers of bank payment modules have not been warned!

@webmastercoolspot

This comment has been minimized.

Copy link

commented Jul 26, 2019

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.

Ok you mean if i create in my module folder a /controllers/front/validation.php and structure like this :

class CbCheckpaymentValidationModuleFrontController extends ModuleFrontController
{
public function postProcess()
{
//Insert code contained in validation.php
}
}

And in code i put all code in validation.php in root of my payment module it will be work with prestashop 1.7.6 ?

How to call this new frontcontroller in payment process ?

@webmastercoolspot

This comment has been minimized.

Copy link

commented Jul 26, 2019

Is it possible to prestashop to revert back for this to way like prestashop 1.7.5.2 even if it's a wrong method to do validation payment.
That permit to payment module dev to update their addon to new proper methode with FrontController and no impact prestashop user ?

@webmastercoolspot

This comment has been minimized.

Copy link

commented Jul 27, 2019

Ok i try to create a new controller and i name it validation.php in "mymodule/controllers/front"

I create class :

class ClicandpayValidationModuleFrontController extends ModuleFrontController
{
     /**
     * @see FrontController::postProcess()
     */
    public function postProcess()
    {
      .............
    }
}

I put in "..........." code there are in my /mymodule/validation.php

My module name is "clicandpay :
$this->name = 'clicandpay';

After i modify my main class of my module to change this :

$this->controllers = array('redirect', 'submit', 'rest', 'iframe');

TO this :

$this->controllers = array('redirect', 'submit', 'rest', 'iframe', 'validation');

Adding my new controller in construct main class.

And after this i try to make a test payment in my shop and i always have same bug (after paiement ok my commande have no status and BO Payment module tell me than i have IPN error (notification url return error)

and my log are same :

INFO v1.7.6.0 2019/07/27 - 01:46:48: Form data generation for cart #116 with standard submodule.
INFO v1.7.6.0 2019/07/27 - 01:46:49: Data to be sent to payment gateway : Array
(
......
)

INFO v1.7.6.0 2019/07/27 - 01:46:58: Server call process starts for cart #116.
INFO v1.7.6.0 2019/07/27 - 01:46:58: Payment accepted for cart #116. New order state is 2.
INFO v1.7.6.0 2019/07/27 - 01:46:58: Create order for cart #116.
INFO v1.7.6.0 2019/07/27 - 01:47:01: User return to shop process starts for cart #116.
INFO v1.7.6.0 2019/07/27 - 01:47:01: Order already registered for cart #116.
INFO v1.7.6.0 2019/07/27 - 01:47:01: The current state for order corresponding to cart #116 is (0).
WARNING v1.7.6.0 2019/07/27 - 01:47:01: Unknown order state ID (0) for cart #116. Managed by merchant.
INFO v1.7.6.0 2019/07/27 - 01:47:01: Payment success for cart #116. Redirect to success page.

And in my BO payment module i have error 500 notification URL and message are :

FAILED_SERVER_500_ERROR, rule=URL de notification à la fin du paiement, duration=~0,5s, response= null

So i missed something to create validation front controller ?

Or maybe it's not only the problem.

@webmastercoolspot

This comment has been minimized.

Copy link

commented Jul 27, 2019

I'd suggest module developers to build a FrontController to handle validation instead of a custom endpoint like validation.php.

Furtheremore. For my payment module it's impossible to not used validation.php in root module.
Indeed, this file is needed in BO payment Module site for to check URL Notification when user put bank card information.

BO site module payment need access URL file php for construct notification URL. If you say that prestashop now need to have only frontcontroller, my payment module will be don't work anymore for prestashop 1.7.6 and more forever
rule-BO-notification

It's not possible for BO module payment to have access url for "ModuleFrontController" prestashop

Because i think module payment won't rework is Back Office (this BO payment merchant is not only for prestashop but for lot of eshop framework like woocomerce/magento/etc....) only because prestashop don't want use "bad practice" anymore.

Best Regard.

@olecorre

This comment has been minimized.

Copy link

commented Jul 29, 2019

With 1.7.6.0 fresh and Payzen:
FastCGI sent in stderr: "PHP message: PHP Fatal error: Call to a member function get() on null in /home/oboutique/www/classes/Tools.php on line 801" while reading response header from upstream, client: 194.50.38.134, server: oboutique.fr, request: "POST /modules/payzen/validation.php HTTP/1.1

In Tools :
$localeRepository = $container->get(self::SERVICE_LOCALE_REPOSITORY);

@eternoendless

This comment has been minimized.

Copy link
Member

commented Jul 29, 2019

That would mean that virtually ALL bank payment modules are obsolete because they would no longer meet the standards imposed by PrestaShop ???

No, just the ones that don't follow PrestaShop recommendations. Modules bypassing PrestaShop were working by chance and chance alone until now, it was just a matter of time.

So i missed something to create validation front controller ?

Did you check that the URL of your controller is correct and reachable?

BO site module payment need access URL file php for construct notification URL.

I'm not sure what you meant here but if the payment processor absolutely needs the endpoint to be named "validation.php" you could keep the file and issue a http 301 permanent redirect to the controller URL.

only because prestashop don't want use "bad practice" anymore.

This is not true. The process seems to be failing because the dependency container is not initialized when you don't go through a Controller. Until now, it just happened to work fine by chance, because the DC wasn't being used in that specific flow. It was just a matter of time, now it's needed because the new currency handling system uses it.

We cannot take any responsibility when people don't follow PS recommandations.

Also, did you perchance test your module when we asked module developers to test them with 1.7.6 beta back in May?

@eternoendless

This comment has been minimized.

Copy link
Member

commented Jul 29, 2019

Again to make things clear: This is not a new recommendation, you should have NEVER bypassed ModuleFrontControllers, which exist since 1.5.0. Your code was working by chance, and it's just now that it has become evident.

@ttoine

This comment has been minimized.

Copy link
Contributor

commented Jul 29, 2019

With 1.7.6, there has been many Beta and RC releases, in order to test it, but, also, to test modules and report issues. That could have been solved before the release.

I can't see any issue opened on this problem before this one, including on the forum.

For reference on the best practice:
https://devdocs.prestashop.com/1.7/modules/concepts/controllers/front-controllers/#example-of-method-calls

@webmastercoolspot

This comment has been minimized.

Copy link

commented Jul 29, 2019

So i missed something to create validation front controller ?

Did you check that the URL of your controller is correct and reachable?

BO site module payment need access URL file php for construct notification URL.

I'm not sure what you meant here but if the payment processor absolutely needs the endpoint to be named "validation.php" you could keep the file and issue a http 301 permanent redirect to the controller URL.

Ok and how i put my controller reachable ?

Did you mean i need to put this to be reachable :
Context::getContext()->link->getModuleLink('clicandpay', 'validation', array()); ?

If yes where to put this code in my module ?

Or just need to redirection 301 old validation.php to my controllers/front/validation.php ?

Sorry for my newbie question i just try to understand.

@tdf-mep

This comment has been minimized.

Copy link

commented Jul 29, 2019

That would mean that virtually ALL bank payment modules are obsolete because they would no longer meet the standards imposed by PrestaShop ???

No, just the ones that don't follow PrestaShop recommendations. Modules bypassing PrestaShop were working by chance and chance alone until now, it was just a matter of time.

So i missed something to create validation front controller ?

Did you check that the URL of your controller is correct and reachable?

BO site module payment need access URL file php for construct notification URL.

I'm not sure what you meant here but if the payment processor absolutely needs the endpoint to be named "validation.php" you could keep the file and issue a http 301 permanent redirect to the controller URL.

only because prestashop don't want use "bad practice" anymore.

This is not true. The process seems to be failing because the dependency container is not initialized when you don't go through a Controller. Until now, it just happened to work fine by chance, because the DC wasn't being used in that specific flow. It was just a matter of time, now it's needed because the new currency handling system uses it.

We cannot take any responsibility when people don't follow PS recommandations.

Also, did you perchance test your module when we asked module developers to test them with 1.7.6 beta back in May?

We have same problem with CM-CIC / Monetico Paiement module

Is it possible to prestashop to revert back for this to way like prestashop 1.7.5.2 even if it's a wrong method to do validation payment.
That permit to payment module dev to update their addon to new proper methode with FrontController and no impact prestashop user ?

I agree webmasercools, may a deprecated method should remain available : many payment modules seems to have same problem

@ttoine

This comment has been minimized.

Copy link
Contributor

commented Jul 29, 2019

If this is reverted to the old behavior, be aware that it means that no module, and no dev will make the job to use best practices...
again, that's why beta and release candidate are released: to test and report issues.

@eternoendless

This comment has been minimized.

Copy link
Member

commented Jul 29, 2019

Ok and how i put my controller reachable ?

As stated in the documentation, your front controller is accessible in an URL like this:

// if the shop uses friendly urls
http://your-url.domain/<language-code-if-multilanguage>/module/<name-of-your-module>/<name-of-your-controller>

// if not
http://your-url.domain/index.php?fc=module&module=<name-of-your-module>&controller=<name-of-your-controller>

Just keep in mind:

  • If your module is called "clicandpay" and your controller is "Validation.php" then the classname should be named "ClicandpayValidationModuleFrontController" (as explained here)
  • In the links above, <name-of-your-controller> should be replaced with "Validation" and not "ClicandpayValidationModuleFrontController"

That is how routing works in PrestaShop.

This code would return that same URL when run in PS:

Context::getContext()->link->getModuleLink('clicandpay', 'validation', array());

You can use this module to see a working example: https://github.com/PrestaShop/ps_buybuttonlite

For the redirection, you can just add a header in your old validation.php so the bank is redirected to the new address (as long as their client follows redirections).

header('Location: '. $theNewAddressExplainedAbove, true, 301);

may a deprecated method should remain available : many payment modules seems to have same problem

The deprecated method Tools::displayPrice() is still available and widely used. But it has to be run in a PrestaShop context (aka through a PrestaShop route) and won't work properly otherwise, because it needs the Dependency Container to be initialized. You can still initialise the DC by yourself if you insist, I've seen some workarounds, but I strongly discourage you from doing that, and if you decide to go that way you're on your own. Either way it's much, much easier, more stable and more secure just to go through a controller or redirect to a controller.

This is also why we removed or deprecated most of our old endpoints in 1.7.6.


Once more: I strongly suggest AGAINST including PrestaShop classes on your PHP code, and using them statically. Chances are that they won't work on their own, and even if they do today, there's no assurance that they will tomorrow.

Static methods are evil because they rely on global state and are based on assumptions. This is a perfect example of why it's so bad. And that's why we need to get rid of them.

@eternoendless

This comment has been minimized.

Copy link
Member

commented Jul 29, 2019

Oh and also: this cannot and will not be reverted because the new currency system is based on multiple independent services which are managed through the Dependency Container. Separate systems are easier to develop, maintain and test.

I'm sorry that your modules stopped working but this is due to bad practices in the past that allowed some things to work in a way that they should never have been allowed to in the first place.

Following good practices is the best way of ensuring this doesn't happen again.

@tdf-mep

This comment has been minimized.

Copy link

commented Jul 29, 2019

I have read your previous posts and i understand what you say.

My mistake is a lack of test before upgrading to this version : shame one me for that !!!

But you may understant : I (we ?) are a little bit lost / disappointed.
Unless I'm mistaken on test or anything else :

  • CM-CIC / Monetico Paiement is still sell at 300€
    => tag as compatible 1.7.6.0
    => tag as develop by Prestashop (is it wright ?)
    => (i wrote a message to this module support to explain this problem witout response until now)

So :
=> Prestashop developpers of the module don't follow Prestashop rules ?
=> No one test this module during Beta and RC ? (may unit / integration tests can be implemented ?)
=> Maybe something can be improve in doc to warn about this : many payment module in same situation ?

I'm not a beta-tester and I don't want / hunderstant why should fix that module by myself : I just want my shop to work.

No intention of being aggressive with this post : it's just a complicated situation for many of us without (easy) solution (roll-back to previous prestashop release ?) for a couple of weeks now.

I should not upgrade before well testing, I known...

@ttoine

This comment has been minimized.

Copy link
Contributor

commented Jul 29, 2019

@tdf-mep thank you for your message.
this is great to read an answer like this one.

About your questions: you are right, and we are currently investigating in order to understand why it happened, and what can be done to solve the issue quickly.

BTW, it is quite amazing that only french banks modules have an issue.

@webmastercoolspot

This comment has been minimized.

Copy link

commented Jul 30, 2019

Ok With suggestion of @eternoendless i made my payment module work again . Thanks to you

My new log :

`INFO v1.7.6.0 2019/07/30 - 01:55:49: Form data generation for cart #127 with standard submodule.
INFO v1.7.6.0 2019/07/30 - 01:55:49: Data to be sent to payment gateway : Array
(
......
)

INFO v1.7.6.0 2019/07/30 - 01:55:59: Server call process starts for cart #127.
INFO v1.7.6.0 2019/07/30 - 01:55:59: Front Controller : Payment accepted for cart #127. New order state is 2.
INFO v1.7.6.0 2019/07/30 - 01:55:59: Create order for cart #127.
INFO v1.7.6.0 2019/07/30 - 01:56:02: Order #28 created successfully for cart #127.
INFO v1.7.6.0 2019/07/30 - 01:56:02: Save payment information for cart #127.
INFO v1.7.6.0 2019/07/30 - 01:56:02: Payment information with ID(s) 30 saved successfully for cart #127.
INFO v1.7.6.0 2019/07/30 - 01:56:06: User return to shop process starts for cart #127.
INFO v1.7.6.0 2019/07/30 - 01:56:06: Order already registered for cart #127.
INFO v1.7.6.0 2019/07/30 - 01:56:06: The current state for order corresponding to cart #127 is (2).
INFO v1.7.6.0 2019/07/30 - 01:56:06: No changes for order associated with cart #127, order remains in state (2).
INFO v1.7.6.0 2019/07/30 - 01:56:06: Payment success confirmed for cart #127.`

All is good because in return BO i have a status for my commande (PJ)

ok-paiement

I will try to make full tutorial for help other marchand have problem here : https://www.prestashop.com/forums/topic/997001-suite-mise-%C3%A0-jour-1752-1760-les-retours-bancaire-ne-se-font-pas/

Thanks agains to @eternoendless for his suggestion :)

@eternoendless

This comment has been minimized.

Copy link
Member

commented Jul 30, 2019

Hi @webmastercoolspot

I'm glad that my suggestion worked :)

Now that the problem and its solution have been identified, I'm closing this issue.

@jf-viguier

This comment has been minimized.

Copy link
Contributor

commented Jul 30, 2019

Please don't close this issue, others payment modules are involved

@LinkOfLight

This comment has been minimized.

Copy link

commented Jul 30, 2019

@khouloudbelguith khouloudbelguith removed the NMI label Jul 30, 2019

@eternoendless

This comment has been minimized.

Copy link
Member

commented Jul 30, 2019

Please don't close this issue, others payment modules are involved

To my best understanding this is a module issue, and not an issue with PrestaShop itself that can be fixed in the Core. As such, there's nothing we can do, it has to be addressed by their respective developers using the solution explained above.

If more information is found that could point to a problem within PrestaShop, feel free to open a new issue.

Modules developed by PrestaShop that present this issue are being fixed by the appropriate team as we speak. For modules developed by other vendors, you will have to get in touch with them and ask them to make sure their modules are compatible with PrestaShop 1.7.6.

@webmastercoolspot

This comment has been minimized.

Copy link

commented Jul 30, 2019

If you are understand french. I've made a post of my modification. Maybe it help : https://www.prestashop.com/forums/topic/997001-suite-mise-%C3%A0-jour-1752-1760-les-retours-bancaire-ne-se-font-pas/?tab=comments#comment-3140082

Sorry not enought good in english for do same in english

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
You can’t perform that action at this time.