shroom

Hello, Je cherche à afficher la description courte des produits sur la page d'accueil. Rien de très compliqué à l'exception du fait que certains produits (pas tous) dans certains blocs (pas tous non plus) ne sont pas suivis de cette description. Voici l'erreur que rapporte Presta : Notice: Undefined index: description_short in .../tools/smarty/sysplugins/smarty_internal_templatebase.php(157) : eval()'d code on line 153 J'ai donc désactivé et purgé manuellement le cache, à tout hasard, mais rien n'y fait. La requète pour afficher la description est très basique, à l'exception d'une classe CSS pour tronquer le nombre de lignes affichées et qui en tout état cause fonctionne car les lignes disponibles pour son affichage sont bien présentes, mais vides. Qu'est-ce qui peut causer cette erreur, sur certains produits uniquement ?

Ah super, merci ! Suffit que je ne zieute pas la partie anglaise pour que la réponse s'y trouve

Je rencontre un problème lorsque je souhaite ajouter un produit en BO sur Prestashop v1.6.1.5. De manière "aléatoire" (je n'ai pas trouvé le dénominateur commun), il est impossible de valider la création d'un nouveau produit : la page de création se recharge avec la plupart des champs vidés, exception faite du code produit et du code EAN. Rien n'est alors enregistré en BDD. L'erreur ne se rencontre que lorsque la catégorie qui va accueillir le nouveau produit est sélectionnée au préalable; sans cette pré-sélection, pas d'erreur. Impossible de trouver la moindre indice dans les logs (ni ceux de Prestashop ni du serveur). Quelqu'un a-t-il déjà rencontré ce problème ?

Idem sous Presta v1.6.1.5 depuis la nuit dernière.

Y a-t-il un petit patch temporaire que je pourrais appliquer sur une v1.6.0.14 en attendant une vraie mise à jour, que je ne souhaite pas faire pendant cette période faste ?

Je confirme également, panier non validé (Presta v1.5.5.0) et ce, quelle que soit la version du module utilisé (v3.5.x / v3.7.2).

Hello, I'd like to update the format of my URLs without getting 404s. At the moment, I'm using the standard one, which is: {category:/}{id}-{rewrite}{-:ean13}.html And I'd like to use something along those lines: {rewrite}-{id}-{-:ean13} It's easy, I just change it, save the fixes and done: site's working pretty fine. Now, it'll take some time before Google updates the links and I'd like to avoid 404s and other issues this change can lead to. Is there an easy way to 301-redirect the old format to new format? I have hundreds of products so if there's an easy template to apply in order to do this, it'll be great!

Any clue on how to make special characters display correctly?

I'd like to use the country iso code on the invoice.tpl file, taking advantage of the "country" object already declared in the "HTMLTemplateInvoice" file, though assigning the "iso code" to smarty crashes the pdf generation. Any clue on how to properly send the iso code value to the tpl file?

Edit: en fait tout semble fonctionner correctement en procédant de la sorte (hors transporteur) : - créer une nouvelle taxe et sa règle - mettre à jour les tables "product" et "product_shop" en indiquant cette nouvelle règle - procéder à la conversion du prix HT

Entre deux coupes de champagne (bonne année tout le monde !), la même question m'a effectivement traversé l'esprit. Ma tâche cron et mes quelques requêtes SQL ont parfaitement fonctionné, seulement voilà, si je clique sur une ancienne commande, elle a également le nouveau taux alors qu'il faudrait qu'elle affiche l'ancien taux et l'ancien prix HT, tout du moins pour toutes les commandes payées en 2013 et antérieur. Ca me semble relativement anodin, je suppose que peu de personnes vont rechercher d'anciennes factures, et que peu de personnes passent commandes le soir du réveillon, mais sait-on jamais...

Ici : $multiple2 = '(1.7/1.1)'; Ne serait-ce pas plutôt : $multiple2 = '(1.07/1.1)'; Je suppose également que les lignes suivantes sont aussi obsolètes : $nvxtx3 = 5; [...] $oldtx3 = 5.5; $nvxtx3 = 5.5; [...] $oldtx3 = 5; Merci pour votre contribution

Any chance for a quick fix regarding the encoding issue? Accents aren't being displayed properly with this solution

Oui, mais comme tu peux le constater, mon post rentre déjà dans la catégorie "tl;dr". C'est plus un bilan de mon expérience, que du cas par cas. S'il fallait rentrer dans le détail, je pense que je n'aurais pas encore fini d'écrire. Loin de moi l'idée de dire qu'il n'y a aucun esprit collaboratif et je ne pointe le doigt sur personne en particulier : j'ai souvent appuyé sur le bouton "Like This" lorsque je m'étais servi d'un bout de code. Mais la tendance générale, pour quelqu'un comme moi qui ne vient sur ce forum souvent qu'en dernier recours, ne me paraît pas excellente. Maintenant si cela s'améliore, tant mieux. Je ne demande pas mieux qu'à pouvoir venir ici pour chercher des renseignements, découvrir ce que les autres développeurs font... plutôt qu'à ne venir systématiquement que pour trouver des solutions à des pertes de productivité. Je sais bien que certains parmi vous vivent du développement Prestashop, mais d'un point de vue professionnel, je n'aime pas consacrer du temps de travail à rectifier ce qui ne devrait pas l'être et à payer/faire payer pour. L'aspect un peu brouillon du forum (j'ai trouvé des aides dans à peu près toutes les rubriques) n'y contribue peut-être pas non plus. Comme le souligne 2FR3, il serait peut-être judicieux de mettre en valeur ce travail communautaire, voire de séparer complétement l'espace "place de marché" et l'espace "entre-aide". Autant, je n'ai aucun problème pour obtenir des modules tiers lorsque le travail accompli sur ceux-ci est conséquent, apporte une réelle plus-value et/ou quand il ne s'agit pas de mon domaine de compétence, autant je trouve frustrant d'avoir à consacrer un temps parfois considérable pour des broutilles; comprendre : travailler un produit de base qui donne parfois l'impression de ne pas avoir été testé correctement avant de passer en production (j'ai attendu la version v1.5.4.1 avant de proposer la migration en v1.5 de la boutique sur laquelle je travaille). Je suis désolé si ces messages peuvent paraître désagréables. Ils ne le sont pas pour le plaisir de l'être. Simplement un retour d'expérience de quelqu'un qui aimerait voir son expérience Presta un peu plus "fluide"

Je vais compléter avec mon retour personnel. Cela fait deux ans maintenant que je travaille bon gré mal gré avec cette solution et je ne le fais pas de bon cœur, ayant repris un site tournant déjà avec Presta. Le fait est que, oui, c'est "probablement" la solution la plus accessible aujourd'hui, du fait de sa gratuité et qu'en conséquence nombre de petites boutiques s'en servent. Mais, à mon sens, la mentalité open-source s'arrête là. Bien sur, en bout de chaîne, il y a des commerçants. Donc une activité rémunératrice et je conçois évidemment que les spécialistes n'aient pas vraiment envie de s'investir dans la communauté avant de s'avoir s'ils pourront monétiser leur aide. Mais ce n'est pas une bonne mentalité pour moi. Certes, certains modules premium valent amplement leur coût, surtout lorsqu'un développeur va au-delà en vous expliquant comment corriger des bugs de Prestashop (sic). Mais à moins de se satisfaire de ce qu'on a, ce n'est pas la panacée, surtout : - lorsque le support Presta vous demande d'acheter de la maintenance pour corriger un de leurs bugs (sic bis) - lorsque vous passez 2/3 de votre temps sur Presta à chercher pourquoi ce qui devrait marcher ne marche pas, très contre-productif - lorsque Presta fait la sourde oreille lorsque des commerçants se plaignent de voir des fonctionnalités utiles disparaître Alors oui, Presta c'est bien parce que c'est gratuit, parce qu'il inclut par défaut nombre d'outils utiles mais la comunauté ressemble plus à une place de marché qu'à une place d'entre-aide. Je suis d'accord sur le fait qu'il ne soit pas non plus question de donner des cours d'informatiques aux commerçants. Mais je dois admettre que je suis fatigué de passer des heures à comprendre pourquoi mon code PHP ne fonctionne pas sous Presta, alors qu'il le devrait. En bout de course, je fais une recherche sous Google, en anglais et en français. Trois fois sur quatre je trouve un début de réponse, ou tout du moins des questions similaires, preuve au final que les commerçants ont bien souvent les mêmes besoins, non satisfaits. Et assez souvent vous trouvez un développeur apportant une réponse vague et vous redirigeant vers un module payant. Je n'ai malheureusement pas le temps de me consacrer uniquement à Prestashop (ça m'aiderait à n'en pas douter, mais j'ai d'autres clients). Et le temps que j'y consacre se résume à chercher pourquoi un module marche un jour et pas le lendemain (surtout lorsque vous n'avez touché à rien entre temps). Je vise PayPal & SoCo tout particulièrement, mais pas que. Je préférerais consacrer mon temps à développer des outils pour améliorer la productivité du commerçant, plutôt qu'à corriger des bugs dans le coeur. J'ai parfois l'impression que les développeurs sont complétement déconnectés des besoins des principaux utilisateurs de leur application, un comble pour une appli open-source.