mexique1

Hello Sylvain. I was wrong about the else if, it actually works, I apologize. However the other concerns are true. Unless you are PCI compliant, you shouldn't post the credit card data to your own server. Never. Also, why post invalid data, while it can be verified on the client side, with the library provided by Stripe? I have contacted the Addons team more than a week ago to fix this module, or be refunded, but I had no answer. I can fix this module, provided you refund me. Could you please tell the developers to contact me?

Hello, I was (happily) using an open source Stripe module for testing (which can be found on GitHub), but then I told my customer to buy the official module from PrestaShop. All I can tell you is : don't buy it !!! - The module does not use the Stripe.js library - The module posts the credit card data in clear to the backend server - The JS code of the module is a joke : for example it uses "else if", which does not exist in JavaScript - The function that is intended to check if the credit card number is OK just doesn't work, you can even send the form with an empty card number. I can't believe I made my customer pay 200+ bucks for that... Now I want to ask a refund to PrestaShop but I know it will be a nightmare. I think this is a shame.

Bah oui Alex12 ta solution va évidemment éviter que le bloc des coupons de réduction disparaisse, mais ça ne résoud pas le problème

Je pense qu'il y a quand même un souci, j'ai reporté ça dans la forge, on va voir http://forge.prestashop.com/browse/PSCFV-10942

Non, j'ai juste fait ce script pour vérifier qu'en la présence de cette clé dans le cookie, le panier est verrouillé. Le fait de désactiver Express Checkout n'a aucun effet une fois que la clé est stockée dans le cookie. Il n'y a que 4 endroits dans le code où cette clé peut être supprimée, j'ai juste l'impression que le flow ne prévoit pas certains cas. Xavier, une fois qu'on a utilisé Express Checkout, comment faire pour revenir à une situation normale ? J'ai essayé de modifier le panier, de le vider, rien n'y fait. En effet, j'ai l'impression que certains client cliquent sur sur le bouton Express Checkout "pour voir ce que ça fait", et du coup on se retrouve dans cette situation.

Le bout de code qui "désactive" la modification du panier est ici (dans modules/paypal/views/templates/hook/paypal.js) $('.qty-field.cart_quantity_input, .cart_total_bar, .cart_quantity_delete, #cart_voucher *').remove(); Donc si je comprends bien, quand le fichier modules/paypal/express_checkout/payment.php est appellé, il stocke une clé "express_checkout" dans le cookie, qui, si elle est présente, désactive le panier. J'ai fait le petit script ci-dessous pour vérifier en stockant / supprimant le cookie moi-même, et ça marche à tous les coups ! $action = isset($_GET['action']) ? $_GET['action'] : 'add'; include_once(dirname(__FILE__).'/config/config.inc.php'); include_once(dirname(__FILE__).'/init.php'); if ($action == 'remove') { unset($cookie->express_checkout); echo 'Cookie removed'; } else if ($action == 'add') { $cookie->express_checkout = serialize(array()); echo 'Cookie added'; } Par contre je ne comprends pas le but de la manoeuvre... C'est dans le but d'empêcher la modification du panier, mais pourquoi ?

En français on dit plutôt "Injection des Dépendances", là tu as traduit en franglais "Dependency Injection"

Tout à fait, et c'est d'ailleurs déjà le cas, non ? Configuration stocke tout dans un array statique.. https://github.com/PrestaShop/PrestaShop/blob/master/classes/Configuration.php#L146 D'où mon commentaire : https://github.com/PrestaShop/PrestaShop/commit/a4997405dc00876709f8e740e99ed6e7c64d82da#commitcomment-2493996 Je comprends pas trop la démarche.. On peut m'expliquer ?

This is outdated now that the project in on GitHub Check my Pull Request : https://github.com/PrestaShop/PrestaShop/pull/70

Je plussoie fortement Erikku Oui, oui.. PrestaShop tient absolument à garder son bugtracker historique pour des raisons pas très claires, et ça introduit clairement de la confusion, en plus de compliquer la gestion. Les tickets ouverts sur GitHub sont systématiquement fermés sans sommation. Je ne pense pas que ce soit aux utilisateurs de tester.. PrestaShop n'a pas une cellule "qualité" chargée des tests ? Dans tous les cas, il faut des tests automatisés. On ne peu pas se reposer uniquement sur des tests humains. De même, lorsqu'un bug est détecté, il faut écrire un test J'ai envoyé un Pull Request pour ajouter des tests unitaires, resté sans réponse : https://github.com/PrestaShop/PrestaShop/pull/70 J'avais aussi récupéré d'autres tests écrits par PrestaShop sur le SVN, donc clairement il y en a, mais je ne comprends décidément pas pourquoi ils ne sont pas inclus dans le dépôt public ! Cependant, le code de PrestaShop étant difficile à tester unitairement, il est limite plus important d'avoir des tests fonctionnels. Dans ce que j'ai récupéré, il y a aussi des tests Selenium. Perso, je pense qu'il faut bosser sur ça : permettre aux contributeurs d'écrire et de lancer les tests fonctionnels simplement. Il va désormais falloir gérer le projet de manière plus pro, et celà passe par des tests unitaires, fonctionnels, de intégration continue.. C'est un travail de fond plutôt désagréable, mais sans ça, ça risque d'être de pire en pire à chaque fois.

Juste un truc à dire : LOL

Tu as bien évidemment raison. Déjà dit, mais il faudrait au pire un dépot dédié pour chaque "gros" module (complexe et qui évolue je veux dire), et les autres dans un dépot commun. Sinon dans l'idéal un dépot par module, mais il y en a qui sont tellement simples que ça en devient ridicule. Tu entends quoi par PNM ?

T'inquiète, la team aussi

Effectivement, c'est discutable, mais c'est déjà pas mal d'avoir fait une branche. Ca permet d'isoler la branche stable du reste. Après ya peu d'intérêt, vu qu'aucun outil d'intégration continue n'est branché dessus, et qu'il n'y a pas de tests. Je pense que PrestaShop découvre encore un peu GitHub.. le souci c'est qu'ils veulent pas vraiment écouter les conseils de la communauté, comme utiliser des sous-modules Git ou encore déprécier la forge pour l'issue tracker GitHub, et enfin virer ces fichier *.md qui n'ont rien à faire là au profit du Wiki. Bref, ça avance à petit pas

Salut, Si ça peut te consoler, une application native n'est pas la bonne solution pour le mobile. Tu trouves pas ça lourd les sites qui te proposent d'installer leur appli à chaque fois que tu visites leur site ? Sans compter que tu te coupes des utilisateurs qui n'ont pas d'Iphone ou d'Android.. Le web est multi-plateforme, inutile de chercher plus loin.. Je te conseille donc d'utiliser le thème mobile à la place.