Quelques corrections et traductions

[Cousin-Hub]

Bonjour,
Voici quelques modifications faites à la version 5.0.0b2
J'ai fait des tests avec validation des paiements en url auto (silencieuce).

Fichier de traduction fr.php complet (fait un peu à l'arrache, à vérifier)
Affiche la page de paiement correctement avec gestion de la boite à cocher "conditions générales de vente" (boutons images inactifs et grisés si non cochée), Petit logo compatible avec le thème classic (seul le logo LCL est présent)
Gestion de l'Url de retour silencieuse en SSL (l'override de la classe ToolsCore est obligatoire pour que cela fonctionne, Atos ajoutant :443 à l'url envoyée..)
Correction d'un bug sur le retour de la devise dans le champ caddie, en effet json_decode renvoyait une erreur 4 (SYNTAX).
Correction d'un problème sur la page Atos de confirmation de paiement (en fait le champ receipt_complement contenait des commentaires HTML qui s'affichaient)

Les fichiers sont dans le dossier "override"

Dans le dossier principal du modules les modifications suivantes ont été apportées :

Modifications de tggatos.php impossibles à faire en override

Ajout du hook hookActionFrontControllerSetMedia pour permettre l'override (voir dossier override) et l'ajout d'un fichier js (gestion de bouton carte en focnrion de l'acceptation de conditions de vente)
Ligne 326 (install method)
foreach (array('paymentOptions', 'paymentReturn') as $hook) {
devient
foreach (array('paymentOptions', 'paymentReturn' , 'actionFrontControllerSetMedia') as $hook) {

Ligne 487 ajout
public function hookActionFrontControllerSetMedia($params) {}

Modifications suggérée de de silentrseponse.php ligne 30 et ajax.php les override n'ont pas l'air de fonctionner sans modification du code.
(Si une exception est levée les méthodes removeResponseLock ne sont pas appellées et le panier est bloqué en paiement.)

silentrseponse.php ligne 30
try{$this->module->processResponse($this->bankResponse);}
catch (Error $e) {}

ajax.php ligne 45
$order = null;
try{$order = $this->module->processResponse($this->bankResponse);}
catch (Error $e) {}

Les fichiers
modifttgatos.zip

Cordialement

Hubert

[Cousin-Hub]

J'ai besoin de votre aide.
Avec la modification
ajax.php ligne 45
$order = null;
try{$order = $this->module->processResponse($this->bankResponse);}
catch (Error $e) {}
Si la réponse silencieuse n'est pas arrivée, La commande est bien validée mais affiche une page d'erreur de paiement.

Sans la modification, si la réponse silencieuse n'est pas arrivée, le script est totalement bloqué.
Je ne comprends pas bien et c'est extrêmement difficile à déboguer.
Cordialement

[TrogloGeek]

Bonjour, lorsque vous dites que la réponse silencieuse n'est pas arrivée, êtes-vous certain qu'elle n'est pas en cours de traitement ?
Sur Apache, les requêtes sont loggées uniquement à terminaison de leur traitement : une requête en cours de traitement n'apparait pas dans les logs. (pour Nginx je n'ai pas vérifié)

Sur les quelques boutiques que j'ai pu auditer présentant un problème de la réponse, le problème venait du fait que la boutique prenait plus de temps pour valider une commande que ne le permettait la configuration HTTP/PHP, soit parce que la boutique était sur un hébergement trop lent (c'est souvent la réactivité du serveur MySQL le point faible) soit parce qu'un autre module essayait de contacter un service externe lors de la validation de commande (souvent pour collecte de statistiques, mise à jour de stock sur un marketplace ou déclaration de la livraison liée à la commande) et que ce service externe mettait trop de temps à répondre, voir parfois que le serveur de ce service était down et qu'aucun timeout n'était configuré pour l'appel à ce service.

concernant votre modification, effectivement il faudrait utiliser une structure try/finally pour libération du lock, mais surtout pas en enveloppant simplement le processResponse avec un bloc catch vide, cela corrompt la chaine de traitement et rend le débuggage impossible puisque les erreurs sont enterrées sous le tapis.

De plus, Il faut être très prudant lorsque l'on manipule un catch sur le classe Error, car cela ne tiendra pas compte des exceptions et surtout cela permet au traitement de continuer alors que la VM a rencontré du code invalide, sans savoir si le contexte d'exécution reste cohérent.

Le try/finally étant apparu en PHP 5.5 on va de préférence s'en passer, cela donnerait donc

                $order = null;
                try {
                    $order = $this->module->processResponse($this->bankResponse);
                } catch (Throwable $error) {
                    $this->module->removeResponseLock($id_cart, $lock);
                    throw $error;
                }
                $this->module->removeResponseLock($id_cart, $lock);

Dans le cas présent l'exception/error doit impérativement être relancée sans quoi effectivement l'utilisateur sera redirigé sur une erreur de paiement.