Jump to content

ntoug

Members
  • Posts

    13
  • Joined

  • Last visited

Profile Information

  • Location
    France
  • Activity
    Web development agency

ntoug's Achievements

Newbie

Newbie (1/14)

0

Reputation

  1. Bonjour, J'ai exactement le même problème ! Testé sur 2 prestashop. Dont un 1.6.1.23 vierge (juste installé). Pour reproduire le problème : 1- mise au panier d'un produit (pour les test, j'ai mis le stock à 1 pour ce produit) 2- commande par "virement bancaire" (tests par CB, même phénomène) 3- la commande est donc en statut "en attente de virement bancaire", 4- changement du statut depuis le BO vers "paiement accepté" => Le stock du produit passe à 0 (tout est normal) 5- "remboursement partiel" (bouton sur le BO, page détail de commande) 6- quantité à rembourser : 1 + montant qu'on souhaite. 7- ON NE COCHE PAS "remettre les produits en stock" => l'avoir est créé, le statut de commande ne bouge pas (normal), mais le stock est repassé à 1 !!
  2. Bon, j'ai pu me débrouiller en faisant un programme de comparaison de sources, par méthodes de classes et de contrôleurs. j'ai donc ma liste de méthodes modifiées entre PS1.6.1.9 et PS1.6.1.19. Le sujet est donc clos !
  3. Hello la community, Je rencontre un problème qui me semble très répandu, mais je ne trouve pas d'info sur les forums ou google, je lance donc une balise SOS ! Je suis chargé de changer de version de Prestashop nos 67 boutiques actuelles, qui sont en PS 1.6.1.9, pour les passer progressivement en PS 1.6.1.19 (la version 1.7 attendra encore un petit peu). Prestashop permet l'utilisation des overrides, ce que nous avons fait pour nos marchands : Chaque demande spécifique de marchand a fait l'objet d'overrides en fonction de ses besoins. Or certaines de ces méthodes overridées ont été modifiées/corrigées/optimisées dans leurs classes/contrôleurs originaux, entre les 2 versions. Il faut donc réappliquer ces changements sur nos overrides, sur chaque boutique séparément. Je pense développer un petit module qui m'alertera des changements possibles détectés. 2 cas possibles : - pas de changement sur telle méthode de tel PHP entre les 2 versions : mon override peut rester en l'état - changements sur telle méthode de tel PHP entre les 2 versions : je dois réappliquer manuellement les évolutions sur mon override Vu la complexité, il faudrait que je référence à l'avance les noms des méthodes et PHP qui ont changés entre PS 1.6.1.9 et PS 1.6.1.19 Que j'en fasse un tableau en dur une bonne fois pour toute dans mon module. Puis après, sur chaque boutique, je pourrais parser les overrides et leurs méthodes en automatique pour voir si certains tappent sur des méthodes "à revoir" La question à 1000 balles, comment trouver cette fameuse liste des METHODES modifiées entre la 1.6.1.9 et la 1.6.1.19 ? J'ai cherché du côté du changelog, du github, en vain. Les différents outils de diff travaillent à la ligne, ça ne m'arrange pas.. J'avais développé un programme qui me donne les différences des PHP (hors méthodes) en enlevant les codes inutiles (commentaires, espaces), mais là encore ce n'est pas suffisant. Il faudrait descendre au niveau "méthode". Quelqu'un a-t-il une solution pour générer cette liste ? Quelqu'un chez Prestashop a-t-il cette fameuse liste ? Merci d'avance !!
  4. Nouveautés sur le sujet ! Je viens de tester sur un prestashop complètement vierge 1.6.1.11. Le problème est là aussi, et je n'ai pas trouvé de ticket ouvert sur la forge, donc un gros bug Presta pas encore réparé (ni identifié?) Pour reproduire rapidement le problème : - créez un user depuis le backoffice [email protected] (notez les 2 points consécutifs, le pb existe aussi avec des accents, ou tout autre chose rejeté par SwiftMailer) - passez une commande depuis le BO avec ce user - ensuite j'ai finalisé la commande en front (pour être sûr de rentrer dans le process d'envois des mails) => [Thu Mar 02 16:09:05.892909 2017] [proxy_fcgi:error] [pid 24061:tid 139984853985024] [client ] AH01071: Got error 'PHP message: PHP Fatal error: Uncaught exception 'Swift_RfcComplianceException' with message 'Address in mailbox given [[email protected]] does not comply with RFC 2822, 3.6.2.' in /data/ps16111/tools/swift/classes/Swift/Mime/Headers/MailboxHeader.php:348 Stack trace: #0 /data/ps16111/tools/swift/classes/Swift/Mime/Headers/MailboxHeader.php(263): Swift_Mime_Headers_MailboxHeader->_assertValidAddress('[email protected]') #1 /data/ps16111/tools/swift/classes/Swift/Mime/Headers/MailboxHeader.php(106): Swift_Mime_Headers_MailboxHeader->normalizeMailboxes(Array) #2 /data/ps16111/tools/swift/classes/Swift/Mime/Headers/MailboxHeader.php(63): Swift_Mime_Headers_MailboxHeader->setNameAddresses(Array) #3 /data/ps16111/tools/swift/classes/Swift/Mime/SimpleHeaderFactory.php(58): Swift_Mime_Headers_MailboxHeader->setFieldBodyModel(Array) #4 /data/ps16111/tools/swift/classes/Swift/Mime/SimpleHeaderSet.php(68): Swift_Mime_Simple... ', referer: http://xxxx?fc=module&module=cheque&controller=payment
  5. Ca n'a pas l'air d’intéresser grand monde :-( J'avais créé un override pour interdire en amont les emails avec accents. Mais le problème est survenu à nouveau aujourd'hui avec une adresse email de type "[email protected]" Je ne comprends pas plusieurs choses : - comment est-ce possible que prestashop autorise dans ses règles de création d'email, des emails qui seront rejetés par la librairie SwiftMailer lors de l'utilisation plus tard ? - comment est-ce possible que le try/catch swiftMailer parte en Fatal à cause de son exception pas définie ? Et surtout.. comment corriger ça :-( Help !!!
  6. Bonjour, Je vous expose mon problème : J'avais un pretashop 1.6.1.1 que j'ai migré vers 1.6.1.9 via 1click-upgrade. Depuis (je pense que ça vient de là), je rencontre de nombreux problèmes sur les envois de mail. En effet, de nombreux clients inscrits ont des caractères accentués dans leur adresse email, et prestashop part en Fatal Error (voir en bas l'erreur complète) : Etrange à 1er abord, mais en cherchant sur internet, il s'avère que depuis 2014, la RFC a changé et autoriserai les caractères accentués dans les url et les emails. D'après ce que je vois dans la classe Validate.php, méthode isEmail(), Prestashop a pris en compte depuis longtemps cette nouvelle norme (la validation de l'email autorise les caractères spécifiques aux pays, donc les accents) D'après ce que j'ai vu sur des forums, la classe swiftmailer est très vieille sur les presta, mais aurait été mise à jour à partir de la 1.6.1.5. Peut-être que le "1-clickupgrade" ne fait pas ce boulot ? Un module gratuit est trouvable sur ce forum, qui gère son propre swiftmailer, mais qui ne doit en aucun cas être utilisé pour des versions > 1.6.1.4. Et dans tous les cas, je ne suis pas fan de déléguer cette partie à un module. Bref.. Quelqu'un a-t-il déjà eu ce problème ? les emails avec accents sont-ils bien autorisés et partent-ils correctement sur les versions récentes de Prestashop ? Des conseils sur le sujet seraient appréciés :-) Got error 'PHP message: PHP Fatal error: Uncaught exception 'Swift_RfcComplianceException' with message 'Address in mailbox given [d\xc3\[email protected]] does not comply with RFC 2822, 3.6.2.' in /data/tools/swift/classes/Swift/Mime/Headers/MailboxHeader.php:348\nStack trace:\n#0 /data/tools/swift/classes/Swift/Mime/Headers/MailboxHeader.php(263): Swift_Mime_Headers_MailboxHeader->_assertValidAddress('d??lia.kessi@ya...')\n#1 /data/tools/swift/classes/Swift/Mime/Headers/MailboxHeader.php(106): Swift_Mime_Headers_MailboxHeader->normalizeMailboxes(Array)\n#2 /data/tools/swift/classes/Swift/Mime/Headers/MailboxHeader.php(63): Swift_Mime_Headers_MailboxHeader->setNameAddresses(Array)\n#3 /data/tools/swift/classes/Swift/Mime/SimpleHeaderFactory.php(58): Swift_Mime_Headers_MailboxHeader->setFieldBodyModel(Array)\n#4 /data/ools/swift/classes/Swift/Mime/SimpleHeaderSet.php(68): Swift_Mime_SimpleHeaderFactory->createMailbo
  7. Merci de t'intéresser à mon post. En fait les options du TPE bancaire sont forcés pour que le paiement du client corresponde à une demande d'autorisation. Bref, le client n'est pas débité, on s'assure juste que la carte est correcte. Ce paramétrage n'est pas modifiable (stratégie de la boutique). Par contre, je souhaite transformer le panier en commande prestashop uniquement si nous arrivons à DEBITER le client. Donc : - tunnel classique - envoi du client vers la page de paiement bancaire - la banque retourne (en mode serveur à serveur) le résultat de cette autorisation à une URL de notification. - la banque attend en retour de cet appel une confirmation du programme (un acquittement) .. ce qui veut dire un echo "ok" + fin de la connexion HTTP. cet acquittement doit être fait tout de suite, avant d'autres traitements. - en plus, moi, je veux rappeler la banque en mode serveur à serveur, pour valider cette autorisation et débiter le client. donc la seule solution que je vois, c'est que mon url de notification, elle fasse les 2 jobs, à savoir : - un echo "ok" + exit ET (PUIS) - un curl pour valider le paiement .. c'est tiré par les cheveux, mais j'ai pas trouvé d'autres solutions.. Le fork répondait à mon besoin, seulement lorsque le fils (ou le père) fait un exit, l'autre process perd une partie de prestashop ("Logger" qui ne fonctionne plus, envoi de mail hs, chargement du panier qui ne marche plus) J'ai testé 5 mécaniques différentes avec des forks ou des "close-connection" ou encore des flush(), en vain. Pour le moment, j'ai trouvé une solution alternative en passant par un exec(xxxx >/dev/null &).. Pas très élégant, mais ça à le mérite de marcher en attendant mieux..
  8. Bonjour, Je suis en train de développer un module de paiement, et les besoins très spécifiques de la boutique et le process de la banque m'obligent à ce que mon URL de notification (url dans mon module, appelée par la banque en fin de paiement, de serveur à serveur) fasse 2 traitements : - retourner OK et libérer le PHP tout de suite pour que la banque reçoive l'acquittement - PUIS immédiatement APRES, rappeler la banque pour valider définitivement le paiement. Quand je dis Immédiatement, c'est tout de suite, pas plus tard via une cron (même toutes les minutes).. Car le client attend derrière son écran avec un sablier, de savoir si sa commande est bien validée. La seule solution que j'ai trouvé est d'utiliser pcntl_fork() Le fils retourne OK puis exit (ça fonctionne, tout est OK en banque.) Le père attend la réponse du fils avec pcntl_waitpid() puis continue son traitement en appelant l'url bancaire (une partie du traitement fonctionne, mais avec des effets de bord) Mon problème : Juste après pcntl_fork(), un Logger::addLog() envoie bien 2 logs (père et fils). Mais dès que pcntl_waitpid() est passé (dès que le fils a fait son exit), les Logger::addLog(() du père ne semblent plus fonctionner.. Ce qui augure que d'autres fonctions Prestashop risquent de ne pas fonctionner non plus (une partie du code fonctionne tout de même)... Bref, je me demande si le exit du fils ne fermerait pas certaines ressources Prestashop, devenues inaccessible au père qui lui continue de tourner.. Help !
  9. Bonjour Guillaume, avez-vous trouvé une solution à votre problème ? Je suis dans la même situation que vous....
  10. Je reviens sur mon problème, car j'ai un autre controller (le front) qui fait une palanquée de SELECT avant ses INSERT.. Je trouve bizarre de devoir désactiver le cache de tous ces SELECT... Je viens de faire une tentative, en vain, sans doute qu'un appel à une méthode qqpart fait un SELECT dans son coin.. Entre temps, j'ai transformé une partie des insert avec la méthode insert(), sans que cela ne résolve mon problème (ce qui était prévisible). J'ai rajouté une trace dans la méthode _getPDO() de la classe DbPDOCore. Cette dernière fait bien un PDO::MYSQL_ATTR_USE_BUFFERED_QUERY => true lors de l’instanciation de l'objet PDO. Donc le message d'erreur PHP conseille de positionner cette variable.. qui semble déjà positionnée ! .. o'scours !
  11. J'ai trouvé une solution "temporaire" : J'ai désactivé le cache sur le select initial : $count_shop = Db::getInstance()->getValue($requete_shop_count,0); Je ne sais pas si c'est la bonne méthode, si quelqu'un a d'autres propositions, je suis preneur !
  12. Désolé, je pensais qu'il s'agissait d'un problème générique et pas spécifique à mon code... Mon module faisant 2700 lignes, voilà quelques éléments : Je fais d'abord : $requete_shop_count = "SELECT COUNT(*) FROM " . _DB_PREFIX_ . "shop WHERE active = 1;"; $count_shop = Db::getInstance()->getValue($requete_shop_count); Si je mets ces 2 lignes en commentaire, l'insert d'après fonctionne.. Puis $requete_creation_form = "INSERT into " . _DB_PREFIX_ . "SELLER_form (`id_form` ,`nb_images` ,`id_category_auto` ,`id_category_user` ,`id_category_default` ,`active` ,`etat` ,`tailleMo`) VALUES (NULL , '" . $_POST["nb_images_form"] . "', '" . $categories . "', '" . $user_categories . "', '" . $_POST["default_category"] . "', '1', '" . $_POST["etat_form"] . "', '" . $_POST["taille_form"] . "');"; $reponse_requete_creation_form = Db::getInstance()->execute($requete_creation_form); $ID_last_form = Db::getInstance()->Insert_ID(); Cet insert ne passe pas tant que le select précédent n'a pas été commenté. Et : - oui, il faut prévoir d'échapper ce qui vient du _POST - oui, il serait mieux d'utiliser la méthode Db::getInstance()->insert(); Mais cela ne résoudra pas je pense mon problème actuel de "PDO unbuffered"....
  13. Bonjour, Je suis en train de terminer le développement d'une module pour PS1.5. J'ai suivi le billet de Sarah Lorenzini sur les bonnes pratiques de dev, que je félicite au passage. Je rencontre un problème lors de l'insert en base de données . L'insert échoue avec le message : " Cannot execute queries while other unbuffered queries are active. Consider using PDOStatement::fetchAll(). Alternatively, if your code is only ever going to run against mysql, you may enable query buffering by setting the PDO::MYSQL_ATTR_USE_BUFFERED_QUERY attribute. " D'après ce que je comprends, PDO a mis un verrou sur ma table dû à un SELECT précédent sur cette même table (pourtant je ne suis pas dans une boucle) .. Difficile de trouver des infos sur ce forum ou Google pour résoudre ce problème, qui me semble basique.. J'ai trouvé 2 pistes : déclarer un "PDO::MYSQL_ATTR_USE_BUFFERED_QUERY" .. (je ne sais pas vraiment comment). Ce qui me dérange avec cette méthode, c'est qu'on sort des bonnes pratiques pour s'astreindre à utiliser mysql, ce qui va à l'encontre de l'abstraction des couches.. purger cet hypothétique SELECT précédent, pour faire sauter ce "verrou".. sur de vieux topix, on parle de pdoxxx->fetchAll() .. mais cette notation n'existe plus normalement.. j'utilise des getRow(), getValue() ou executeS().. qui je suppose libèrent les tables après leur appel... Ce problème doit apparaitre pour de nombreux développeurs, j'ai du louper un épisode ! Pour info, l'insert est tout bête : $reponse_requete_creation_form = Db::getInstance()->execute($requete_creation_form);
×
×
  • Create New...