Jump to content

J. Danse

Members
  • Posts

    2,563
  • Joined

  • Last visited

  • Days Won

    5

Everything posted by J. Danse

  1. Je viens de tester le module sur une version 1.5.5. Il n'y a pas eu de soucis et aucunes configurations spécifiques à faire. :-/
  2. C'est ce que j'allais dire... Cette version est en beta, ok, mais elle vient tout de même d'être releasé en version finale. ;-)
  3. Le mode basique est - il me semble - sans les produits de démos. Ce n'est désormais plus possible, et il faut les supprimés via le module PS Cleaner. Pour la suppression de commandes, c'est tout à fait volontaire. Il n'est normalement pas possible/logique de supprimer des commandes. Par contre, tant qu'on est pas en production, il est possible d'utiliser le module PS Cleaner pour supprimer l'ensemble des commandes de tests.
  4. Cela s'appelle du CSS (Ok, du CSS inline mais du CSS tout de même). Par contre, pour revenir sur le message de réponse à Jeckyl, l'idée de la hauteur fixe est bien ce qui est décrit par Atch (même si expliquer par plus amples précisions). Dans l'idée, beaucoup lisent en diagonales des questions et des réponses - sur ce forum et partout ailleurs. Beaucoup posent des questions mais ont des notions (qui divergent souvent des autres) en tout point: CSS, HTML, PHP, marketing, e-commerce, logistique, ... Bref, il est parfois plus aisé (afin de répondre à tous !) de réaliser des réponses courtes auxquelles il - me semble - n'y a lieu que de demandes des précisions quant à la réalisation des solutions données. Et, en très bref, il n'y a pas lieu de réagir ainsi: Jeckyl et bien d'autres sont des personnes bénévoles qui tentent d'aider au mieux et au plus les uns et les autres. Et ce, je précise, sans jamais faire une citation marketing/commercial (ce qui est malheureusement bien trop souvent le cas, d'autant quand il s'agit de réponses à côté la plaque). C'est d'ailleurs ce genre de comportements qui font que l'on a parfois pas/plus envie de participer et de répondre aux questions telles que celles-ci, finalement. Et c'est bien dommage, pour tout un chacun ! ;-)
  5. Bonjour, Merci pour votre achat. Concernant votre soucis, je ne visualise pas de déclinaisons sur cette fiche produit. D'ailleurs, par contre, je ne pense pas que le soucis viennent des déclinaisons et du module mais plus vite d'un paramétrage qui fait défaut. Si vous voulez, vous pouvez me contacter via le formulaire de contact sur mon propre site ou via celui d'addons, si votre achat est fait via ce site. On pourra ainsi échanger plus facilement par email et voir ce que l'on peut faire ensemble pour corriger ce soucis et éventuellement déterminer si cela peut provenir du module ou non
  6. Et, pour l'info, la version 1.5.5 intègre la clé d'ouverture pour la console de debug. Par contre, niveau configuration, c'est toujours SMARTY_DEBUG par défaut. Si l'utilisateur utilise cette méthode, il devra prendre le soin de modifier la clé.
  7. Exact, cette super variable (j'arrête de me lancer des fleurs, ah ah ! ;-)) est configurable via le BO, section Thèmes. Pour la question technique, c'est dans la classe Mail, méthode Send(). $template_vars['{color}'] = Tools::safeOutput(Configuration::get('PS_MAIL_COLOR', null, null, $id_shop)); Et c'est arrivé avec PrestaShop 1.5.3.0
  8. Si j'abuse, je peux aussi mentionner les bugs avec le module "ProductComments". En premier lieu, l'insertion du critère "Quality" étant réalisé au sein du fichier SQL, elle est insérée pour une seule langue et uniquement en anglais (mais, dans mon cas, pour le français). Un détail, mais qui pourrait être facilement corrigé. Par contre, l'insertion d'un commentaire me retourne purement et simplement ceci: Title is incorrect Comment is incorrect Customer name is incorrect Product not found Non seulement ce n'est pas traduis mais aucunes des valeurs marquées dans les champs est envoyée en AJAX et donc elles ne peuvent pas être traitées. Il faut remplacer (à la L63 de modules\productcomments\js\productcomments.js): data: $('#fancybox-content form').serialize(), Par: data: $('#new_comment_form form').serialize(),
  9. J'ai une traduction manquante, également lors de l'installation d'un module ayant une dépendance: "Before installing this module, you have to installed these/this module(s) first :"
  10. Un numéro sans indicatif en Belgique (et au Canada, puisque je présume que l'installeur serait en français également) n'a pas spécialement de sens surtout si le numéro est français. Par contre, l'indication d'un indicatif ne pose pas soucis même si nous sommes dans le pays de destination, non ? Je mentionne souvent mon numéro comme +32 (0) ... ; cela permet d'indiquer assez simplement que le numéro est en Belgique et c'est compréhensible. Cela peut rester en anglais, mais c'est pour la cohérence (surtout que l'encart est assez costaud et que le footer reprend cette quasi même phrase avec un indicatif +33 dans le numéro... et donc je vois pas trop le soucis actuellement ;-)). C'est également pour cela que nous faisons des tests et des retours. C'est à ça que sert notre processus de tests. L'idée étant de faire avancer les choses, n'est-ce pas ? ;-)
  11. Nous sommes d'accord. Bon, outre passons le fait que ce soit dans un configure. Il devrait être possible de l'utiliser dans un Front Controller, par exemple. C'est un peu le but d'un Helper, tout de même. Non ? ;-) (Mais nous serons d'accord et n'étant pas le but du sujet, on va se stopper là dans la suite je pense que c'est mieux ;-)).
  12. Je viens de tester... Alors, oui, le soucis vient du fait que les variables $order_by et $order_way ne sont pas initialisées dans Smarty car elles n'existent pas dans ce contexte. Et il est n'est pas possible d'instancier celles du contrôleur puisque les variables sont protégées. Et impossible de mettre ces variables comme souhaitées, car elles seront remises à null par la suite. Dans l'idée, le message ci-dessus sur les normes est juste. Mais, par contre, il est vrai que l'on devrait pouvoir utiliser un HelperList même dans un configure de module, cela dit. Et entièrement
  13. L'ajout aux favoris via JavaScript n'est pas possible sur Chrome, c'est pourquoi le lien n'est pas affiché.
  14. Mon (premier) retour de test: [installer] Encart "Need Help" en anglais tandis que le reste est en français. Il serait intéressant que la traduction soit réalisée. [bO] AdminHome: J'ai un encart pour lequel Firefox n'arrive pas à faire le chargement. La cause ? Cette URL: http://://api.prestashop.com/rss2/news2.php?v=1.5.5.0&lang=fr ; Pull Request proposé. [bO] Carrier Wizard: aucune traductions en français.
  15. Bon... Pour le moment, je suis bloqué à 45% de l'installation. Edit: Ah, l'a juste fallu le temps. Beaucoup de temps ! ;-)
  16. Entièrement d'accord. Maintenant, quand on veux aller un peu plus loin et ne pas s'arrêter à ce qu'on connait ou ce que l'on a vu dans un bout de code fonctionnel (l'idée étant évidemment que tout développement soit fonctionnel) mais non optimisé ou encore en utilisant des techniques invraisemblables (et je le dis car PrestaShop est une mixité de code fonctionnel mais complètement différent selon le moment de la production de celui-ci...) c'est assez délicat de pouvoir farfouiller là-dedans. La démarche réalisée par CaptainFlam est intéressante. Malheureusement, les mises à jour se font et le suivi de ce genre de document n'est pas possible et il serait d'ailleurs intenable de l'utiliser. La simple et bonne raison que PrestaShop n'utilise pas (bien que ce sont les normes de développement) les blocs de commentaires phpDoc comme il se devrait et qui plus est que l'on a des nouvelles méthodes au fur et à mesure. Fut un temps, j'avais une documentation de ce genre alimentée au fur et à mesure des versions des méthodes existantes. Ce qui permettait également de pouvoir cibler une version spécifique de PrestaShop et d'en connaître les méthodes disponibles (et ainsi pouvoir définir si l'on devait ou non utiliser une ou l'autre méthode en fonction de son projet). L'analyseur de classes/controllers est toujours actif, je devrais voir éventuellement pour le faire tourner à nouveau et imaginer une nouvelle interface de documentation technique (mais pas de documentations d'utilisations, malheureusement !). Nous sommes d'accord, la documentation technique de PrestaShop 1.5 est pauvre et, qui plus est, parfois inadéquate. Effectivement, des bribes de l'ancienne version sont parfois insérées dans la nouvelle. Ce qui n'est pas des plus pratiques, il faut en convenir. Fut un temps (bien que je le fasse encore rarement), j'éditais cette documentation en collaboration avec PrestaShop et plus précisément Xavier, le responsable documentation. L'ennui, c'est que la documentation doit aussi couvrir la documentation utilisateur, administrateur et j'en passe et est gérée exclusivement par Xavier. Ce qui ne lui permet pas de couvrir l'ensemble des points de façons complètes et qui plus est rapidement. Malheureusement. Concernant les tutoriels, ils en existent quelques uns mais j'accorde qu'ils sont parfois fort ciblés ou encore non adaptés à un certain niveau de complexité ou de connaissances (me concernant, chaque tutoriel m'apporte quasiment toujours une nuance inconnue de la manière de procéder quant à la mise en oeuvre d'un développement ou encore par la code adapté). Les livres, parlons-en ! Il en existe, on l'accorde. Très peu. Je pense pouvoir dire qu'ils se compte sur les doigts de deux mains maximums (pour ne pas être trop restrictifs, tout de même). Mais, surtout, quasiment aucun n'est destiné à de la documentation technique ou plus précisément à des développeurs désireux d'en apprendre d'avantages sur PrestaShop et le développement de boutique avec ce dernier. Cependant, j'ai tout de même le plaisir de pouvoir dire que - du moins je l'espère ! - ce genre de discours changerait petit à petit dans quelques mois. Effectivement, je suis actuellement plongé dans la rédaction d'un ouvrage technique entièrement destiné aux développeurs PrestaShop. Le contenu de cet ouvrage sera aussi bien destinés aux débutants (prise en main basique) qu'aux plus expérimentés sur la solution. Avec des explications, des exemples techniques et des référentiels de fonctions. Et, pour finir, je peux même dire que cet ouvrage amène non seulement un côté physique non négligeable de documentation mais qu'au fur et à mesure de l'écriture et de ma lecture de codes (vous n'imaginez pas combien de temps j'ai pu passé à la lecture de code !), j'ai moi-même découvert des fonctionnements jusque là inconnus... Fonctionnement que je ne manques donc pas de transcrire, tant qu'à faire ! ;-)
  17. Exactement, il n'est pas possible d'ajouter du PHP dans les champs d'écritures ni même dans les fichiers templates (du moins, en natif). Par contre, les fiches produits ont quelques hooks sur lesquels ils seraient possible "d'ajouter" du PHP pour éventuellement obtenir l'effet escompté. Au même titre, sur une version 1.5, il est possible de rajouter des hooks spécifiques à l'endroit désirés via la balise {hook}.
  18. Les données de cette tables constitue les relations entre les fichiers physiques et les produits dans la base de données. Son effacement entrainerait la perte de ces relations (mais pas des fichiers, bien que devenus inutiles puisque non reliés). Par contre, de fait, le poids semble très volumineux. Beaucoup trop pour être normal. Avez-vous pu analyser le contenu de cette table et remarqué des éventuels défauts (id_product = 0, en double, ...) ? Si vous ne vous sentez pas à même de le faire (par manque de connaissances, par exemple), je peux vous communiquer mes coordonnées afin de pouvoir analyser cette table pour vous. L'idée est que si vous la rendez publique, les données contenues dedans peuvent être utilisés pour le téléchargement des fichiers. Ce qui serait dommage, je pense ;-)
  19. Est-ce que l'ajout de cette ligne dans le constructeur du controller change quelque chose ? $this->_defaultOrderBy = 'position';
  20. Très bonne question. Ce n'est pas nécessaire, c'est vrai.
  21. Malheureusement, c'est délicat. Tout dépend de la configuration de la boutique même et, qui plus est, il s'agissait ici d'une modification sur mesure car elle ne prends pas en compte l’entièreté des possibilités. Dans ce cas-ci, ce n'était pas dramatique mais cela à fait l'objet de plusieurs échanges. Sinon, ce serait avec plaisir évidemment !
  22. Sur le principe, qu'appelles-tu une page de produit "full" ? Sans les colonnes de gauche et droite, c'est bien cela ?
  23. Je pense que chaque cas est un cas à part et certaines fonctionnalités (liées à l'ergonomie) doivent être prises en compte ou non selon ce même cas. Il est clair que si je remplis un caddie de produits consommables (et surtout d'un même produit ayant des déclinaisons), ça serait embêtant. Maintenant, si j'achète un voyage aux Caraïbes, autant dire que je ne vais pas en acheter 2/3 de durée différentes en même temps (ou du moins, rarement !) ;-). Dans ce cas là, je préfère aller directement à mon panier finalement. Chaque projet doit avoir ses impératifs et ses règles d'ergonomies, selon moi !
×
×
  • Create New...

Important Information

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