Jump to content

ezcb

Members
  • Posts

    21
  • Joined

  • Last visited

  • Days Won

    1

ezcb last won the day on January 21 2018

ezcb had the most liked content!

Profile Information

  • Activity
    User/Merchant

Recent Profile Visitors

4,644,804 profile views

ezcb's Achievements

Newbie

Newbie (1/14)

5

Reputation

1

Community Answers

  1. bonjour une piste ici, https://www.prestashop.com/forums/topic/469753-pb-sqlstate08004-1040-too-many-connections/?do=findComment&comment=2450116 Cdt
  2. Bonjour, peut etre une solution ici https://www.prestashop.com/forums/topic/469753-pb-sqlstate08004-1040-too-many-connections/?do=findComment&comment=2450116
  3. Bonjour une solution est ici. https://www.prestashop.com/forums/topic/469753-pb-sqlstate08004-1040-too-many-connections/?do=findComment&comment=2450116
  4. Bonjour, Le problème c'est MySQL qui s'engorge et explose, Le problème démarre avec les requêtes du bock de recherche du site, les requêtes s'empilent et font monter le serveur en température. Ajoutez un pic de trafic + le passage du bot de google et c'est le crash assuré. Pour ma part serveur dédie 8 cœurs et MYSQL à 800%. Premièrement il faut retrouver un site fonctionnel (pour vos clients et votre Référencement) donc on va provisoirement demander a google d'espacer de quelques secondes ses requêtes pour éviter le crash. Donc rendez vous sur Google webmastertools allez dans paramètre du site et cliquez sur Limiter la vitesse d'exploration maximale de Google Pour ma part j'ai modifié la vitesse d'exploration à 24 demandes par seconde et 4 secondes entre les demandes. Sachez que votre modification est provisoire, google réinitialise les réglages tous les 90 jours. Bon maintenant on va corriger le problème des requêtes qui s'empilent et en corrigeant cela on va gagner en performance et de manière très significative (recherche instantanée et site beaucoup plus rapide). Comme on sait que ce sont les requêtes de recherche qui consomment toutes les ressources Mysql on va simplement faire un SQL_NO_CACHE sur celles ci. Privilégiez l'override: Sur prestashop 1.6.1.7 récupérez le fichier search.ph dans le dossier Classes. Nous allons modifier la fonction FIND (public static function find) Remplacez la ligne 178 $db = Db::getInstance(_PS_USE_SQL_SLAVE_); Par $db = Db::getInstance(_PS_USE_SQL_SLAVE_); $no_database_cache = false; Ensuite on modifie la requête a la ligne environ 202 $intersect_array[] = 'SELECT si.id_product FROM '._DB_PREFIX_.'search_word sw LEFT JOIN '._DB_PREFIX_.'search_index si ON sw.id_word = si.id_word WHERE sw.id_lang = '.(int)$id_lang.' AND sw.id_shop = '.$context->shop->id.' AND sw.word LIKE '.($word[0] == '-' ? ' \''.$start_search.pSQL(Tools::substr($word, 1, PS_SEARCH_MAX_WORD_LENGTH)).$end_search.'\'' : ' \''.$start_search.pSQL(Tools::substr($word, 0, PS_SEARCH_MAX_WORD_LENGTH)).$end_search.'\'' ); Par $intersect_array[] = 'SELECT '.($no_database_cache?'SQL_NO_CACHE ':'').'si.id_product FROM '._DB_PREFIX_.'search_word sw LEFT JOIN '._DB_PREFIX_.'search_index si ON sw.id_word = si.id_word WHERE sw.id_lang = '.(int)$id_lang.' AND sw.id_shop = '.$context->shop->id.' AND sw.word LIKE '.($word[0] == '-' ? ' \''.$start_search.pSQL(Tools::substr($word, 1, PS_SEARCH_MAX_WORD_LENGTH)).$end_search.'\'' : ' \''.$start_search.pSQL(Tools::substr($word, 0, PS_SEARCH_MAX_WORD_LENGTH)).$end_search.'\'' ); Idem pour la requête a la ligne 286 on remplace if ($ajax) { $sql = 'SELECT DISTINCT p.id_product, pl.name pname, cl.name cname, cl.link_rewrite crewrite, pl.link_rewrite prewrite '.$score.' FROM '._DB_PREFIX_.'product p INNER JOIN `'._DB_PREFIX_.'product_lang` pl ON ( p.`id_product` = pl.`id_product` AND pl.`id_lang` = '.(int)$id_lang.Shop::addSqlRestrictionOnLang('pl').' ) '.Shop::addSqlAssociation('product', 'p').' INNER JOIN `'._DB_PREFIX_.'category_lang` cl ON ( product_shop.`id_category_default` = cl.`id_category` AND cl.`id_lang` = '.(int)$id_lang.Shop::addSqlRestrictionOnLang('cl').' ) WHERE p.`id_product` '.$product_pool.' ORDER BY position DESC LIMIT 10'; return $db->executeS($sql, true, false); } Par if ($ajax) { $sql = 'SELECT DISTINCT '.($no_database_cache?'SQL_NO_CACHE ':'').' p.id_product, pl.name pname, cl.name cname, cl.link_rewrite crewrite, pl.link_rewrite prewrite '.$score.' FROM '._DB_PREFIX_.'product p INNER JOIN `'._DB_PREFIX_.'product_lang` pl ON ( p.`id_product` = pl.`id_product` AND pl.`id_lang` = '.(int)$id_lang.Shop::addSqlRestrictionOnLang('pl').' ) '.Shop::addSqlAssociation('product', 'p').' INNER JOIN `'._DB_PREFIX_.'category_lang` cl ON ( product_shop.`id_category_default` = cl.`id_category` AND cl.`id_lang` = '.(int)$id_lang.Shop::addSqlRestrictionOnLang('cl').' ) WHERE p.`id_product` '.$product_pool.' ORDER BY position DESC LIMIT 10'; return $db->executeS($sql, true, false); } et enfin on remplace a la 314 $sql = 'SELECT p.*, product_shop.*, stock.out_of_stock, IFNULL(stock.quantity, 0) as quantity, Par $sql = 'SELECT '.($no_database_cache?'SQL_NO_CACHE ':'').' p.*, product_shop.*, stock.out_of_stock, IFNULL(stock.quantity, 0) as quantity, Enregistrez et savourez le resultat. N’hésitez pas non plus a mettre un Crawl delay 10 sur votre robots.tx. Autre chose pour les grosses boutique n’hésitez pas non plus a désactiver vos modules de cache tel que cachemanager et de comparer vos perf avec et sans module. en effet nous concernant depuis quelque temps notre serveur met moins de temps a exécuter les requêtes qu'a lire le cache. En espérant vous avoir aidé. Cdt EZ
  5. Bonjour Vincent, Avez vous trouvé une solution à votre problème de Surcharge ? Nous avons le même problème. Par avance merci de votre retour
  6. Bonjour voir la reponse ici https://www.prestashop.com/forums/topic/343432-double-paiement-et-bon-de-livraison/?p=2156451
  7. Bonjour, En fait il y a 2 bugs qui peuvent générer l'erreur Attention XXX € payé au lieu de XXX € Le premier bug est sur le calcul des factures qui est erroné. En effet la requête renvoi null sur une sum de 0 résultat. Pour corriger on ajoute la fonction COALESCE sur la requete SQL dans la fonction getSiblingTotal du fichier OrderInvoice.php on remplace donc public function getSiblingTotal($mod = OrderInvoice::TAX_INCL) { $query = new DbQuery(); $query->select('SUM(oi.total_paid_tax_incl) as total_paid_tax_incl, SUM(oi.total_paid_tax_excl) as total_paid_tax_excl'); $query->from('order_invoice_payment', 'oip1'); $query->innerJoin('order_invoice_payment', 'oip2', 'oip2.id_order_payment = oip1.id_order_payment AND oip2.id_order_invoice <> oip1.id_order_invoice'); $query->leftJoin('order_invoice', 'oi', 'oi.id_order_invoice = oip2.id_order_invoice'); $query->where('oip1.id_order_invoice = '.$this->id); $row = Db::getInstance()->getRow($query); switch ($mod) { case OrderInvoice::TAX_EXCL: return $row['total_paid_tax_excl']; case OrderInvoice::TAX_INCL: return $row['total_paid_tax_incl']; default: return $row; } } Par public function getSiblingTotal($mod = OrderInvoice::TAX_INCL) { $query = new DbQuery(); $query->select('COALESCE(SUM(oi.total_paid_tax_incl),0) as total_paid_tax_incl, COALESCE(SUM(oi.total_paid_tax_excl),0) as total_paid_tax_excl'); $query->from('order_invoice_payment', 'oip1'); $query->innerJoin('order_invoice_payment', 'oip2', 'oip2.id_order_payment = oip1.id_order_payment AND oip2.id_order_invoice <> oip1.id_order_invoice'); $query->leftJoin('order_invoice', 'oi', 'oi.id_order_invoice = oip2.id_order_invoice'); $query->where('oip1.id_order_invoice = '.$this->id); $row = Db::getInstance()->getRow($query); switch ($mod) { case OrderInvoice::TAX_EXCL: return $row['total_paid_tax_excl']; case OrderInvoice::TAX_INCL: return $row['total_paid_tax_incl']; default: return $row; } } On va également corriger la fonction getRestPaid() on remplace donc toujours dans OrderInvoice.php public function getRestPaid() { return round($this->total_paid_tax_incl + $this->getSiblingTotal() - $this->getTotalPaid(), 2); } Par public function getRestPaid() { return round($this->total_paid_tax_incl + (float)$this->getSiblingTotal() - $this->getTotalPaid(), 2); } Pour le deuxième BUG et le plus important c'est la fonction getTotalPaid qui est mise en cache et qui pose problème. Ce cache est unique par process http Dans ce process, la même action est appelée 2 fois sans être rafraîchis. En cas pratique ca donne getTotalPaid = 0 Ajout de la facture etc .... getTotalPaid = 0 alors qu'un paiement a été ajouté. Donc pour corriger il suffit de commenter la mise en cache de la fonction getTotalPaid() On remplace public function getTotalPaid() { $cache_id = 'order_invoice_paid_'.(int)$this->id; if (!Cache::isStored($cache_id)) { $amount = 0; $payments = OrderPayment::getByInvoiceId($this->id); foreach ($payments as $payment) $amount += $payment->amount; Cache::store($cache_id, $amount); } return Cache::retrieve($cache_id); } Par public function getTotalPaid() { $cache_id = 'order_invoice_paid_'.(int)$this->id; /*if (!Cache::isStored($cache_id)) {*/ $amount = 0; $payments = OrderPayment::getByInvoiceId($this->id); foreach ($payments as $payment) $amount += $payment->amount; Cache::store($cache_id, $amount); //} return Cache::retrieve($cache_id); } Voila a présent vous n'aurez plus de problème du XXXXXX€ au lieu de xxxx€ . Presta foire à la base. Il crée le paiement (acquittement du solde du) si le statut de la commande à l'option : "Considérer la commande associée comme validée" est activé. Alors que Presta devrait créer le paiement que si l'option : "Marquer la commande associée comme payée " est activé. Pourquoi ? parce que on peut tout à fait avoir une commande qui est valide et non payée (B2B) alors que Presta considère systématiquement qu'une commande validée est payé et en plus il considère que la commande est réglée à 100%. j'en déduit que l'ajout manuel de règlement partiel a une facture ne fonctionne pas. Faites un test : Prenez une commande et aller dans la table PS order paiement Modifiez le montant du paiement en le divisant par 2 par exemple. Revenez sur votre commande et dans l'onglet paiement vous verrez que le solde du paiement est divisé par 2 (donc en théorie le client a réglé 50% de la facture). Changez le statut de votre commande vers un autre statut validé. Et la Presta à créer à nouveau un paiement de la différence alors qu'il ne devrait pas y toucher. Par définition ce bug nous empêche de saisir plusieurs règlements pour une commande car comme je viens de le dire Presta considère une commande comme 100% acquittée dès lors qu'il y a changement de statut vers un statut considéré comme validé.
  8. Bonjour, Le correctif ne fonctionne pas sur la 1.6.0.9. Cela est totalement désolant et inadmissible car le bug est depuis toujours mis en avant et le seul correctif a été apporté grâce à nous sur prestashop 1.4.4.11 après avoir déboursé 1500 € pour le corriger auprès d'un dev indépendant qui a transmit l'info à presta. Et maintenant rebelote sur la 1.5 et 1.6 Je pense qu'il faut très sérieusement se réveiller chez prestashop parce que c'est tout simplement une honte et un gros manque de considération pour les utilisateurs qui se retrouvent au pied du mur et sans solution après avoir dépensé des milliers d'euros, car en téléchargeant la solution rien ne nous dit que les factures et les avoirs seront faux. C'est quand même le genre de bug ULTRA URGENT qui doit trouver solution dans les heures de sa sortie mais chez prestashop on s'en bat les cacahuètes. Oui les cacahuètes, car ils ont connaissance du bug depuis des années et ils ont la solution depuis la sortie de la 1.4.4.11 mais rien n'est fait. D’ailleurs comment fait prestashop avec sa comptabilité face a ce bug ? et au contrôleur fiscal on lui dit quoi ? on lui paye un café en le connectant sur le forum. Nous ne sommes pas des développeurs , Nous ne sommes pas des comptables , Nous ne sommes pas mathématicien . Nous sommes des vendeurs qui passons plus de temps a bricoler prestashop qu'a faire du commerce. Sur ce genre de bug vous n'avez pas le droit de nous laisser nous débrouiller tout seul. Désolé mais il fallait que ça sorte, j'en ai marre de passer pour un blaireau auprès de mon comptable et d'un incompétent auprès de nos clients pour un problème qui relève du béaba de la facturation. Si une personne détient la solution, même payante nous sommes intéressé et si nous avons trouvé de notre coté nous posterons la solution. Petit rappel du bug: 1 client passe commande sur un produit qui coûte 100€ avec un code promo de 20€, donc il paye 80 €. Le lendemain le client demande le remboursement. Pour annuler la facture nous générons l'avoir et comme le client souhaite racheter nous générons en même temps un bon de réductions. Et la surprise le montant de l'avoir est de 100€ au lieu de 80 € payé (le système ne prend pas en compte le code promo de 20€) Mais pas seulement, en allant voir sur le compte du client le bon de réduction n'est pas de 80€ mais de 100€.
  9. Bonjour, Le bug présenté ci-dessous concerne tous les commerçants qui ont migré vers la 1.6 (pour ma part 1.4.4.0 vers 1.6) Plus précisément cela concerne toutes les commandes qui ont été créées sur votre version précédente de Prestashop. La conséquence est lourde et alarmante car tous vos exports comptables et vos (pdf) factures qui étaient juste sont à présent totalement faux mais pire cela n'est pas qu'un simple problème de calcul mais une base de données mise à jour avec des valeurs complètement fausses à cause du module de MAJ autoupgrade. Je répète cela ne concerne que les anciennes commandes et pas celles passées a partir de la 1.6 car a priori les tables sont bien renseignées. Alors pourquoi les factures et les totaux sont faux sur les anciennes commandes et pas forcement sur les nouvelles ? Parce que lors de la mise a jour, le module autoupgrade ajoute de nouvelle tables et que les nouvelles tables sont alimentées avec de fausses valeurs. Exemple détaillé: Prenez une commande d'un client qui a utilisé un (avoir) bon de réduction et qui a acheté au moment ou vous utilisiez une version 1.4 voir 1.5. repérez le numéro de commande et allez sur phpmyadmin. une fois connecter allez sur la table ps.orders et recherchez la commande en question. Une fois trouvée regardez la colonne total_discounts_tax_excl la valeur affichée doit être le montant hors taxe du total_discounts_tax_incl Chez moi ça ne correspond a rien la valeur affichée du total_discounts_tax_excl est de (965.29) et la valeur du total_discounts_tax_incl est de 966.87 Idem regardez la colonne total_paid_tax_excl chez moi la valeur est en négatif (-29.08) alors que le total_paid_tax_incl est en positif (154.72) les résultats sont identiques sur la table ps_order_invoice idem sur la table ps_order_cart_rule la valeur des bons de réduction HT est a 0 partout. idem sur la table ps_order_detail_tax la valeur de la tva des produit est en négatif. Donc conclusion lors de la mise a jour les tables créées sont mal renseignées. Je précise qu'avant de poster le message j'ai réalisé 4 MAJ sur (2 serveurs différents) et le résultat est a chaque fois identique : 1 Maj 1.4.4.0 vers 1.5.5.0 vers 1.6.0.4 vers 1.6.0.9 1 Maj 1.4.4.0 vers 1.6.0.4 vers 1.6.0.6 vers 1.6.0.9 1 Maj 1.4.4.0 vers 1.6.0.6 vers 1.6.0.9 1 Maj 1.4.4.0 vers 1.6.0.9 La question est de savoir si vous avez une solution pour corriger les tables concernées par le bug ? Y a t'il une personne qui puisse effectuer un test de son coté et nous faire un retour. Merci par avance Cdt Z
  10. Bonjour j'ai eu le même problème sur mon serveur vps pro et idem au bout de 20 minutes plantage malgré les réglages du serveur. Par contre pas de souci avec le dédié de la prod il traite la MAJ en 6 minutes sur une base de 2.6GO. La solution n'a rien à voir avec la config serveur, elle est tout simplement dans le module autoupgrade lui même. Il faut ouvrir le fichier AdminSelfUpgrade.php a la ligne 4894 et 4895 il y a une ligne qui parle d'elle même: // set timeout to 20 minutes (before aborting an ajax request) $.ajaxSetup({timeout:1200000}); la valeur ici est en millisecondes (je pense). J'ai triplé la valeur et bingo au bout de 45 minutes mise a jour réussi (1.4.4.0 vers 1.6.0.9) et pas un seul warning . Donc même si le post date un peu je laisse le message car le problème est à ce jour toujours d'actualité. Cdt EZ
  11. Bonjour j'ai eu le même problème sur mon serveur vps pro et idem au bout de 20 minutes plantage malgré les réglages du serveur. Par contre pas de souci avec le dédié de la prod il traite la MAJ en 6 minutes sur une base de 2.6GO. La solution n'a rien à voir avec la config serveur, elle est tout simplement dans le module autoupgrade lui même. Il faut ouvrir le fichier AdminSelfUpgrade.php a la ligne 4894 et 4895 il y a une ligne qui parle d'elle même: // set timeout to 20 minutes (before aborting an ajax request) $.ajaxSetup({timeout:1200000}); la valeur ici est en millisecondes (je pense). J'ai triplé la valeur et bingo au bout de 45 minutes mise a jour réussi (1.4.4.0 vers 1.6.0.9) et pas un seul warning . Donc même si le post date un peu je laisse le message car le problème est à ce jour toujours d'actualité. Cdt EZ
  12. Bonjour j'ai eu le même problème sur mon serveur vps pro et idem au bout de 20 minutes plantage malgré les réglages du serveur. Par contre pas de souci avec le dédié de la prod il traite la MAJ en 6 minutes sur une base de 2.6GO. La solution n'a rien à voir avec la config serveur, elle est tout simplement dans le module autoupgrade lui même. Il faut ouvrir le fichier AdminSelfUpgrade.php a la ligne 4894 et 4895 il y a une ligne qui parle d'elle même: // set timeout to 20 minutes (before aborting an ajax request) $.ajaxSetup({timeout:1200000}); la valeur ici est en millisecondes (je pense). J'ai triplé la valeur et bingo au bout de 45 minutes mise a jour réussi (1.4.4.0 vers 1.6.0.9) et pas un seul warning . Donc même si le post date un peu je laisse le message car le problème est à ce jour toujours d'actualité. Cdt EZ
  13. Bonjour, Il suffit de changer la configuration du php sur le serveur pour ma part j'ai corrigé l'erreur en passant ma config en MOD-PHP au lieu du mode PHP-FPM et l'erreur à disparu. Cdt EZ
  14. Bonjour, Ayant rencontré le problème se week end je post la réponse malgré le fait que le post date un peu. J'ai finalement trouvé le problème qui se situe au niveau du serveur. En ce qui me concerne le php du serveur était réglé sur le mod PHP-FPM au lieu d’être configuré sur MOD-PHP. Une fois la configuration changée j'ai simplement rebooté le serveur et l'erreur à disparu et pour être sur du coup j'ai à nouveau testé en repassant la configuration sur le le mod PHP-FPM et l'erreur est aussitôt revenu. Cdt EZ
  15. Bonjour j'ai eu le même problème sur mon serveur vps pro et idem au bout de 20 minutes plantage malgré les réglages du serveur. Par contre pas de souci avec le dédié de la prod il traite la MAJ en 6 minutes sur une base de 2.6GO. La solution n'a rien à voir avec la config serveur, elle est tout simplement dans le module autoupgrade lui même. Il faut ouvrir le fichier AdminSelfUpgrade.php a la ligne 4894 et 4895 il y a une ligne qui parle d'elle même: // set timeout to 20 minutes (before aborting an ajax request) $.ajaxSetup({timeout:1200000}); la valeur ici est en millisecondes (je pense). J'ai triplé la valeur et bingo au bout de 45 minutes mise a jour réussi (1.4.4.0 vers 1.6.0.9) et pas un seul warning . Donc même si le post date un peu je laisse le message car le problème est à ce jour toujours d'actualité. Cdt EZ
×
×
  • Create New...