Jump to content

shroom

Members
  • Posts

    98
  • Joined

  • Last visited

Everything posted by shroom

  1. 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 ?
  2. Ah super, merci ! Suffit que je ne zieute pas la partie anglaise pour que la réponse s'y trouve
  3. 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 ?
  4. 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 ?
  5. Thanks for the module I'm having a small issue with the pictures though (everything else is ok). Module is properly installed and activated as I can find the tags on the "product" pages. The picture link is correctly set though Facebook isn't using it for some reason. Prestashop version : v1.5.5.0 mod_security: off geolocalization: off site cache: cleared picture size: far above the recommended 200x200px picture link: no hotlink protection of some sort, pictures can be directly opened Anything I should check?
  6. 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).
  7. 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!
  8. 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?
  9. 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
  10. 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...
  11. 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
  12. Any chance for a quick fix regarding the encoding issue? Accents aren't being displayed properly with this solution
  13. 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"
  14. 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.
  15. Je profite de sujet pour vous demander si l'un d'entre vous sait comment afficher le nom de la société, lorsqu'un client l'a renseigné, dans le détail de sa commande en admin ? En l'état, seul son nom est affiché dans le récapitulatif des adresses. EDIT : en fin de compte, ça marche, simplement un bug sur une adresse...
  16. Merci Pour ce qui me concerne, il me semble que l'override ne soit pas vraiment en cause. Les données récupérées via la requête SQL semblent bonnes : une reconversion du tableau de sortie via html_entity_decode ne change rien.
  17. Je crois que l'absence ou plutôt le silence côté développeur doit surtout venir du fait qu'il y avait un cahier des charges à tenir et probablement faire en sorte que les clients privilégient ce moyen de paiement. Rien de tel alors qu'une présentation intrusive et au diable l'indication faite au client qu'il s'agit d'une transaction sécurisée. Merci pour votre contribution yvanb
  18. Hello ! En v1.5.5.0 cet override n'affiche pas les caractères spéciaux (accents et cie). Suis-je le seul à avoir ce problème ?
  19. It works with v1.5.x though special characters (accents...) aren't properly decoded anymore with v1.5.5.0.
  20. Bumping this thread to confirm that this override somehow works but doesn't handle special characters.
  21. Our shop needed a design change (we were using a customized default theme). We thought it was a good time to do that big upgrade and so I had a theme ready for v1.5.x. Nothing impressive as I did a v1.2.5 > v1.4 couple years ago. I did couple upgrades on a test domain and always this way : v1.4.8.2 > v1.4.11.0 > v1.5.5.0. The auto-upgrade process went quite fine, apart from one or two warnings that didn't prevent the upgrade to complete successfully (mostly due to a bugged auto-upgrade module). We did the real upgrade couple weeks ago, with an updated auto-upgrade module and it worked fine. Of course I had (and still have) to fix multiple minor bugs and annoyances, but no real major bugs and nothing related to the upgrade itself. Tips : - if you've customized your v1.4 installation, create a list of the changes that were made - duplicate your production database and create a new sql user for that specific test database - copy your v1.4 installation to a test subdomain on your server and update the config file in order to use the duplicated database (and not your production one) - remove all the custom override codes you've added - update your auto-upgrade module on the test domain - upgrade to the latest v1.4 then unlock the v1.5 upgrade option and untick the backup settings (not needed on a test installation, will speed up considerably the process) and let it deactivate the external modules during the process - test, test, test and test; unless you have issues with your host, there's no reason for the process not to work - apply your custom work back accordingly (you'll have to update most of it to the new code) - you'll probably have to update your cron jobs too - make backups prior to do the real upgrade - enjoy cool new features, regret the missing ones and be ready for new annoyances
×
×
  • Create New...

Important Information

Cookies ensure the smooth running of our services. Using these, you accept the use of cookies. Learn More