yann viroulaud

Up ?

Serveur Enterprise SP-64 - 64G E5-1620v2 de chez OVH Il n'y a qu'un E-commerce tournant dessus. J'ai du mal à croire qu'il ne tienne pas la "charge" sur ce type de requête. (Cela ne met pas en erreur 500 les pages produits, dans mes logs je n'ai pas de signalisation de requête perdue ou autre) L'activation du mode dev ne donne pas d'autres infos. Si un dédié n'est pas suffisant pour gérer un prestashop d'une envergure assez modeste (environ 30K visiteur unique / mois) sur une requête contenant 2000 lignes dans une table j'ai du mal à me dire que qui que ce soit puisse avoir une structure suffisante dans ce cas... Merci tout de même pour la piste (mais a mon sens incorrect)

Bonjour, nous rencontrons depuis un certain temps des problèmes concernant nos prix barré. Après quelques vérifications et test, il s’avère que la table ps_specific_price est la table qui génère le problème. Ce problème est simple, au bout d'un certain nombre de ligne renseigné (environ 2200), la table "sature" et prestashop sur sa partie front fait complètement disparaître les prix barrés. Si nous supprimons un nombre de ligne pour "libérer" de l'espace sur cette table, hop les prix barrés réapparaissent. Nous sommes sur prestashop 1.7.1.1 (et la montée de version n'est pas possible en l'état) Nous avons un catalogue de plus de 900 référence, une partie de ce catalogue possède une réduction sur 3 groupe d'utilisateurs (visiteur, invité, client) pour que cela n'impacte pas nos groupes B2B. Ce qui par défaut sur un catalogue de 300 référence du type, provoque donc 900 lignes juste pour ces produits. Nous avons des produits customisables, qui génère (en cette période de solde) 1 produit par customisation. Cette dernière ayant un ID propre, considéré comme un produit unique, viens donc rajouter 1 ligne supplémentaire dans notre base de donnée sur la table specific_price. Avec une moyenne de 40 produit par jour créer via notre composeur, il est donc quasi systématique que chaque matin je sois obligé de vider une partie de la base. Viendra un moment ou cette dernière ne pourra plus être "vider". Si quelqu'un à déjà rencontré ce type de problème "incroyable" ?

Toujours pareil...

Ma version est la suivante : 1.6.0.11

Personnellement j'ai ca en displayHeader et l'erreur de ma console

I got that message when I switched statut to " shipping " intro " shipped"

Same issue for me. Anyone ?

Bonjour, je rencontre actuellement un problème plutôt gênant, sur une de mes boutiques, prestashop en 1.6, quand on edit une fiche produit, le premier " affichage " de la page produit n'est pas correct. Les zones de textes sont réduite et en mode HTML brut (sans le wysiwig donc), de plus le produit n'est dans " aucune " catégorie. Si j'enregistre une première fois, il me met une erreur et la, magie, tout s'affiche de nouveau correctement. Le problème même en mode debug ne génère aucune erreur ce qui est réellement le vrai problème car au moins je saurai ou chercher. J'aimerai donc savoir si quelqu'un à déjà rencontré le problème et si oui qu'avez vous fait pour résoudre le problème ? Cordialement

Merci pour cette réponse. En revanche j'ai un soucis. Nous utilisons une méthode d'affichage d'information supplémentaire dans le cas d'un produit configurable : {foreach $order_detail.customizedDatas as $customizationPerAddress} {foreach $customizationPerAddress as $customizationId => $customization} <tr class="customization_data {$bgcolor_class}"> <td class="center"> &nbsp;</td> <td> {if isset($customization.datas[Product::CUSTOMIZE_TEXTFIELD]) && count($customization.datas[Product::CUSTOMIZE_TEXTFIELD]) > 0} <table style="width: 100%;"> {foreach $customization.datas[Product::CUSTOMIZE_TEXTFIELD] as $customization_infos} <tr> <td style="width: 30%;"> {$customization_infos.name|string_format:{l s='%s:' d='Shop.Pdf' pdf='true'[spam-filter] </td> <td>{$customization_infos.value}</td> </tr> {/foreach} </table> {/if} {if isset($customization.datas[Product::CUSTOMIZE_FILE]) && count($customization.datas[Product::CUSTOMIZE_FILE]) > 0} <table style="width: 100%;"> <tr> <td style="width: 30%;">{l s='image(s):' d='Shop.Pdf' pdf='true'}</td> <td>{count($customization.datas[Product::CUSTOMIZE_FILE])}</td> </tr> </table> {/if} </td> <td class="center"> ({if $customization.quantity == 0}1{else}{$customization.quantity}{/if}) </td> </tr> {/foreach} {/foreach} Or malheureusement ce code n'est pas re-exploitable avec la surcouche de votre modéle. Auriez vous une idée ?

Et donc comment fait on de manière effective ? ( prestashop 1.7 ) C'est la question de base, a laquelle vous n'avez donc que répondu à moitié. et cela reviens donc aux premières réponses disponibles. Maintenant si il existe un moyen d'overrider les fichiers pdf pour associer non pas l'order product mais le product d'origine, quel est donc le code a fournir ? Cordialement

Attention... M4 ne traduit que les termes globaux. Ca ne fait pas la translation de la description produit en langue d'origine du shop.... Je viens de perdre 100€. Nice

Bonjour, Prestashop 1.7.1.1 Module Google analytics v 3.0.1 Symptome : Impossible d'ajouter un produit ou de supprimer dans le panier un produit. ( L'opération se fait mais il faut raffraichir le navigateur pour voir le résultat. ) Log : Stack trace: #0 XX\classes\Hook.php(891): Ps_Googleanalytics->hookactionCartSave(Array) #1 XX\classes\Hook.php(327): HookCore::coreCallHook(Object(Ps_Googleanalytics), 'hookactionCartS...', Array) #2 XX\classes\Hook.php(839): HookCore::callHookOn(Object(Ps_Googleanalytics), 'actionCartSave', Array) #3 XX\classes\Cart.php(263): HookCore::exec('actionCartSave') #4 XX\classes\Cart.php(1330): CartCore->update() #5 XX\controllers\front\CartController.php(348): CartCore->updateQty(1, 13, 0, 0, 'up', '5') #6 XX\controllers\front\CartController.php(179): CartControllerCore->processChangeProductInCart() #7 XX\controllers\front\CartController.php(171): CartControllerCore->updateCart() #8 XX\classes\controller\Controller.php(194): Cart in XX\modules\ps_googleanalytics\ps_googleanalytics.php on line 795 Résultat => Désactivation du module en attendant une solution....

Bonjour à tous et merci de prendre le temps de lire ce post. Cela fait 2 jours que j'essaye de rajouter une simple expression dans mon template category.tpl pour un bouton, qui serai donc traduisible dans les 6 langues dispo. Hors impossible de récuperer la moindre traduction. Dans mon fichier tpl voici la forme que cette expression a : <p class="link-primary">{l s='See the collection' d='Shop.Mytheme'}</p> ( En me basant sur cette page : http://build.prestashop.com/howtos/translation/how-to-translate-your-theme/#case-2:-you-are-creating-new-strings-in-files-that-already-exist-in-the-default-theme ) Impossible de voir ressortir l'expression. J'ai recharger, vider les caches, reboot le serveur, switcher de theme pour repasser sur l'inital, changer le nom, etc. Rien à faire, impossible en BO d'accéder a cette expression.. Si quelqu'un à une info ce serai génial. Merci par avance Update : J'ai ma réponse...Le thème ne dois PAS être " classic "....

Bonjour, je ne sais pas si je suis sur la bonne partie du forum. Toutefois j'ai un probleme avec le module de virement bancaire sur un de mes sites ( prestashop 1.6 ) Lors d'une validation de commande par virement bancaire ( v 1.1.2 ), la commende passe bien en status " En attente du paiement par virement bancaire " mais également en même temps sur " Autorisation acceptée par PayPal "... J'ai beau me creuser la tête TRÈS FORT je ne vois aucune corrélation possible entre ces 2 modules ... Si jamais quelqu'un à une idée je suis preneur. Merci d'avance