codeurWeb

Salut Anthony, Je confirme ce qu'a dit Samyha. Tous les paiements finissent sur la confirmation de commande, donc dans order-confirmation.tpl. Le problème est que les clients ne sont pas toujours redirigés vers cette page après le paiement. Il y a des interfaces de paiement qui redirigent automatiquement le client et d'autres non. Le client peut aussi fermer le navigateur juste après avoir payé. Donc ce n'est pas toujours fiable, malheureusement... Julien

En effet, c'est assez étrange. C'est forcement un ajout récent car le nom du hook est standardisé selon la version >= 1.5 mais ce hook n'est créé à aucun moment car il n'y a pas de méthode d'installation ni de fichier d'upgrade qui aurait pu ajouter ce hook pour l'utiliser. Ceci dit, le code qui envoi le mail est exécuté avant le Hook::exec(), donc, si le exec() ne fait pas d'erreur, les mails devraient être envoyés. Si le Hook::exec() fait une erreur, vous pouvez essayer d'ajouter le hook "actionModuleMailAlertSendCustomer" dans la table ps_hook. Cependant, ce hook semble ne jamais être appelé puisqu'il n'y a pas de fonction correspondante et que son nom est incohérent pour une utilisation en "Hook dynamique". Je pense donc que vous pouvez mettre le hook::exec() en commentaire...

Salut, j'ai rencontré ce problème également, la solution est la : https://github.com/codeurWeb/PrestaShop-1.5/commit/b04d9d62525f356d4edcead97c51338450521bee C'est en attente de validation.

Bonjour, en testant un module de gestion d'onglets sur les produits, sur la version 1.6.0.3, je remarque que la structure html des onglets a changé. L'ancienne structure html : <div id="more_info_block"> <ul class="idTabs idTabsShort" id="more_info_tabs"> <li><a href="#idTab1" id="more_info_tab_more_info">Onglet 1</a></li> <li><a href="#idTab2" id="more_info_tab_more_info">Onglet 2</a></li> {hookTab} </ul> <div class="sheets align_justify" id="more_info_sheets"> <div id="idTab1">Contenu onglet 1</div> <div id="idTab2">Contenu onglet 2</div> {hookTabContent} </div> </div> La nouvelle structure semble être : <section class="page-product-box"> <h3 class="idTabHrefShort" id="#idTab1">Onglet 1</h3> <h3 class="idTabHrefShort" id="#idTab2">Onglet 2</h3> <div id="idTab1">Contenu onglet 1</div> <div id="idTab2">Contenu onglet 2</div> </section> Donc, tous les modules qui utilisent les onglets des produits risquent de ne plus s'afficher correctement. (Cf: ) Je ne sais pas si c'est parce que cette partie n'est pas encore faite ou si il va falloir adapter tous les modules. Bien à vous, Julien

Bonjour, avez-vous essayé de modifier le paramètre "Afficher les attributs indisponibles sur la fiche produit" à non dans Préférences > Produits ?

Bonjour, il faut commencer par redimensionner les images. Pour ça, il faut aller dans Préférences > Images et modifier les dimensions de "home_default" à 250X200. Ensuite, toujours dans Préférences > Images, il faut régénérer les images. (En bas de la page)

Bonjour, Si votre site n'est qu'en Français, vous pouvez utiliser les traductions dans Localisation > Traduction. Si vous êtes en multilangues, il faut que la traduction de base soit en Anglais puis traduite via le bavck-office. Sinon, le texte se trouve dans le fichier .tpl du modules blocknewsletter si c'est bien ce module qui est utilisé. Regardez d'abord dans /themes/votretheme/modules/blocknewsletter pour voir si le fichier TPL est surchargé. Dans ce cas, c'est ce fichier qu'il faut modifier. Cdt

Bonjour, il faut faire la modification CSS dans le fichier votretheme/css/product.css (ou dans globals.css selon votre thème), puis désactivé les options de performance et vider le cache pour que la modification CSS soient prises en compte. Ensuite, vous pouvez ré-activer vos options de performance. Performances activés compilation : jamais cache : activé Performances désactivés compilation : toujours cache : désactivé Sur les dernières versions, il y a un bouton "Vider le cache". Sinon, vous pouvez supprimer les fichiers dans votretheme/cache/ pour vider le cache (En laissant l'index.php si il est présent)

Bonjour, pour faire des recherches avancés, vous pouvez utiliser le module de navigation à facette fournis avec Prestashop. Il permet de configurer des filtres selon les catégories en se basant sur les caractéristiques et les déclinaisons. Par exemple, vous pouvez utiliser les catégories et sous-catégories pour la navigation par marques et par modèles, puis le filtrage par caractéristiques pour arriver aux produits.

Bonjour, avez-vous songé à le faire avec les déclinaisons ? Cela permet de laisser le choix aux clients et de gérer des prix supplémentaires.

Bonjour, J'ai développé un module qui permet de faire ça : http://puzzle-ecommerce.com/fr/catalogue/26-caracteristiques-multiples-module-prestashop.html

Bonjour, oui c'est ça. Je rajouterais qu'après la configuration, il faut passer quelques commandes en mode test avant de demander le passage en production à Atos et passer le module en mode production.

Bonjour, j'ai eu à mettre en place un paiement CIC pour un de mes clients. J'ai utilisé le module de @creaweb06 qui coûte 65€ et prend en charge le paiement comptant ainsi que le paiement fractionné. Je vous le recommande, il est très bien fait : http://www.creaweb06.fr/modules-de-paiement-prestashop/1-prestashop-module-paiement-cic-credit-mutuel-cmcic.html

C'est dans le fichier /themes/nomdutheme/category.tpl, et la variable est $subcategories.

Si les nouveaux clients peuvent s'inscrire et se connecter, c'est qu'il n'y a pas de "problème" et on peut en déduire que les mots de passe des clients importés ne sont pas bien cryptés. Si les mots de passe étaient cryptés dans son ancien système, c'est difficile d'imaginer qu'il a pu les décoder avant l'import. (Sauf si les dev n'avaient pas compris le principe du cryptage à sens unique) Pour l'import des clients dans PS, il faut que les mot de passe soient en clairs car ils sont cryptés à l'import. Je pense que le problème est là : Si les mots de passe ont été importés pré-crypté, PS les a re-crypté et plus rien de correspond. Solutions : - Si les mots de passe sont en clair dans l'ancien site : réimporter les clients en laissant les mdp en clair. - Si les mots de passe sont cryptés mais décryptables : solution précédente. - Si les mots de passe sont cryptés et non décryptable : il faut mettre en place un système de vérification, récupération et de mise à jour du mot de passe comme l'ont fait l'équipe PS pour le module "importerosc", méthode hookbeforeAuthentication($params). Le principe est que les anciens mots de passe cryptés sont importés dans la table customer et lors de l'authentification, sont vérifiés et mise à jour avec le cryptage PS. Du coup, c'est en se connectant qu'un client règle le problème de son compte de façon transparente. (Je ne sais pas si ça va t'aider mais ce que j'explique là fonctionne parfaitement pour importer d'osCommerce)