Jump to content

Broceliande

Members
  • Posts

    1,735
  • Joined

  • Last visited

  • Days Won

    5

Everything posted by Broceliande

  1. Hi, If you really need to target modules dir within your theme dir, rather than using automatic theme overrides (you didn't tell what you were trying to do) , then you should use {$tpl_uri}/modules/yourmodule/yourfile....
  2. Bonjour, Le fait que tu ais pu greffer le module en footer implique qu'il implémente effectivement ce hook, faute de quoi il n'aurait pas été greffable , à moins que tu n'aies modifié le code du module en suivant un quelconque tuto. Il est fort probable que le module en question effectue un test sur la page courante. A titre d'exemple , si le module est écrit pour ne s'exécuter que sur l'accueil , il peut parfaitement effectuer un test sur la propriété php_self et sortir si cette valeur n'est pas "index". ca donnerait un truc du genre : if ($this->php_self != "index") return; Il faudrait nous en dire plus sur le module en question.
  3. Je n'ai pas regardé de quand date le patch, mais sur une 1.6.1.4, lorsque la case générer un avoir est cochée, il est possible de spécifier plus bas si l'avoir doit inclure ou non le bon de réduction.
  4. Bonsoir, Il n'existe pourtant qu'une seule raison au "vidage intempestif" du panier : un cookie en conflit avec un autre. La seule raison implique une seule solution : le cookie doit être unique. Pour ce faire sur une 1.6.1.4 , il est nécessaire d'indiquer dans Préférences -> Seo - urls, de vérifier que : - le nom de domaine et le nom de domaine ssl son identiques. - le champ "Rediriger vers l'URL canonique" est réglé sur "301 Déplacé Définitivement (recommandé lorsque vous avez lancé le site)" Eventuellement, il peut être utile de cocher "Désactiver l'option MultiViews d'Apache et Désactiver le mod sécurity...." Concernant les solutions de panier "ajax" à désactiver , ce n'est pas une solution mais un moyen de contournement uniquement de certains dysfonctionnements. Ici je pense simplement que quelques réglages essentiels au passage en production du site n'ont pas été effectués.
  5. Bonsoir, La réponse est contenue dans la question ici. Il faut raisonner en terme de hierarchie des règles de prix. La remise par groupe est probablement la plus haute dans cet arbre car elle s'applique systématquement , quelque soit le prix de base , les réductions , soldes etc ... Pourtant il est possible et facile en créant une (enfin trois) règles de prix catalogue, d'ajouter une remise de x% pour chaque groupe utilisateur et spécifier des catégories associées. Il suffit qu'un produit n'appartienne pas à ces catégories sélectionnées pour que les prix spécifiques générés par la règle de prix catalogue ne s'applique pas . Pour résumer : oublie les remises de groupe qui s'appliqueront toujours, et crée 3 règles de prix catalogue en y spécifiant l'appartenance au groupe x ou y , la réduction consentie , et les restrictions de catégories. Ca marchera pareil sauf que les produits hors des catégories sus-citées échapperont à toute règle de prix ...
  6. Ah exact pour 29 , j'ai pu retrouver un code que j'avais fais sur une 1.4 , j'ajoutait 000 si je n'avais pas un code postal intégral. Mais si tu ne peux pas ajouteur un simple sélecteur de région , effectivement tu vas devoir te coltiner la correspondance insee, sachant que charger l'ensemble des codes en js va être un peu lourd, à moins que tu ne te fasses un p'tit controller ajax pour ça ...
  7. Hmm bon c'est assez difficile à expliquer comme ça en quelques mots...., mais les thèmes UHU comme les deux autres sont entièrement basés sur des tas d'effets dans tous les sens et donc pleins de modules additionnels sans lesquels on n'obtient rien de ressemblant à ce qu'on croit avoir acheté. Même pour UHU je suis étonné que les visuels ne soient pas configurables ? Quoiqu'il en soit, est-ce que la quantité d'infos et la hauteur de page à scroller de ce type de thème va dans l'esprit du e-commerce ? En ce qui me concerne c'est clairement non , et non , et encore non. L'acheteur veut voir rapidement le produit qu'il cherche et ne souhaite pas digérer xmille pixels de scroll dès la première page. Trop d'infos, trop de visuels , qui occultent ce pour quoi le visisteur est là, mais pas seulement, on doit aussi y ajouter le temps de chargement accru que ces thèmes surchargés de partout apportent. Ne serait-ce que par le nombre de modules à traiter par le moteur de prestashop. Ces thèmes sont réalisés par des graphistes et des intégrateurs doués c'est indéniable, mais ce n'est pas valable pour le e-commerce. Pour moi ça colle aux blogs et autres cms , pas à une boutique en ligne. Mes clients qui vendent réellement vont à l'essentiel : le produit , et y ajoutent un maximum d'ergonomie immédiatement compréhensible par tous. Je pourrais citer des exemples mais je ne voudrais pas être censuré juste pour ça (hein mon Oron ) , car ce serait un peu de la pub inappropriée.
  8. Salut, A défaut de la ville , le code postal est insuffisant pour l'appli map appelée par le store locator. Plus facile que de passer par le code INSEE , fais toi juste une correspondance département nom_département , genre : 29 Finistère De manière générale , il est préférable d'avoir des données prédéfinies pour obtenir un résultat à tout les coups que d'utiliser une simple adresse dans un input ou chaqun va entre son adresse à sa manière.... Plus tu utilises de champs et plus la tâche est aisée , tu n'as dans ce cas absolument plus besoin de l'adresse (enfin tout dépend de ce qu'on veut exactement car il faut également ajuster le zoom de la map ... mais bon) En séparant code postal, ville, rue et pays par exemple , il t'est plus facile de concaténer l'adresse à envoyer au locator. Chose plutôt a ton avantage , tu sembles limiter les recherches à la france... Je peux t'en dire un peu plus au besoin mais essaye par exemple juste une fois d'envoyer ça : var address = 29 Finistère , France" ; Note au passage que de mémoire il me semble que le locator aime bien que les champs soient toujours suivis d'un espace.... donc un +" " en js derrière un champ ne mange pas de pain. Tiens nous au jus de tes avancées et résultats, je dis tout ça un peu de mémoire, mais c'est déja assez loin.
  9. Possible oui , mais sûrement pas l'explication exacte à ton problème : l'erreur la plus fréquente quand on crée un module à partir d'un gabarit ou d'un autre module, est qu'on copie une structure existante pour la modifier. Souvent en effet ou oublie de modifier le nom de la classe ou celui du dossier , mais derrière il ne faut pas oublier de supprimer avant la première installation le fichier xml présent dans tous les modules depuis la 1.5. Ce fichier contient lui aussi le nom de la classe du module, ainsi que son numéro de série addons le cas échéant (utilisé pour les maj ou installations externes sans avoir nécessairement le module dans l'arbo du site). J'ai le sentiment que c'est ton cas , ce qui a trompé la classe module quand tu as souhaité l'installer. Cette histoire de majuscule a pu éventuellement régénérer un config.xml pour le module , mais bon je ne pense pas que cela n'ait été la véritable cause.
  10. Salut, Le problème à mon sens est que tu cherches du mauvais côté. Je m'explique : Tu entends modifier la classe CartRule si j'ai bien compris , alors que cette classe sait parfaitement gérer nativement un nombre donné d'utilisations. En elle même elle se suffit pour gérer les bons que tu souhaites générer, mais certes non les créer d'elle même. Tu as deux choix à partir de là : Un module sur mesure même tout simple qui va se greffer sur la validation d'une commande et créer le fameux bon en fonction de l'appartenance d'un produit du panier à une catégorie donnée, ou à un produit défini (ou systématiquement au besoin, mais imagine si tu veux vendre autre chose ...). Le bon doit comporter plusieurs paramètres et peut être créé en passant par l'objet CartRule (recommandé sauf si on sait ce qu'on fait), ou une insertion BDD. Le deuxième choix est peut être moins lourd et passerait par une override. Dans les deux cas il faut savoir développer un minimum sous presta : - au moins savoir créer un module ou une override. - Instancier un nouvel Objet CartRule - Renseigner les propriétés nécessaires et obligatoires de l'objet - Enfin enregistrer l'objet par sa méthode save() ou add() Ce n'est pas un énorme deal mais il faut coder un minimum , et savoir exactement ce qu'on veut pour ne pas partir dans tous les sens et risquer des effets de bord. Je ne sais pas quel est ton degré de connaissances à ce niveau donc je ne m'étendrai pas plus mais pour obtenir le résultat , modifier la classe CartRule.php est une très mauvais idée.
  11. erf ça existe toujours les thèmes UHU ? Sincèrement je pense que mes potes intégrateurs te répondraient mieux que moi, mais je doute que les css du thème en ta possession soient en adéquation avec un défaut bootstrap 1.6. Je peux me gourrer mais à l'instinct ....
  12. Je me foule d'un post parce que ce module paypal à la mode 202 commence à me courir grave ! Pardonnez l'expression mais tout de même il y a des limites à ce qu'on peut supporter. Dernier exemple en date , la version 3.10.2 du module parfaitement ininstallable sur 1.4.x et pour cause : public function install() { if (!parent::install() || !$this->registerHook('payment') || !$this->registerHook('displayPaymentEU') || !$this->registerHook('paymentReturn') || !$this->registerHook('shoppingCartExtra') || !$this->registerHook('backBeforePayment') || !$this->registerHook('rightColumn') || !$this->registerHook('cancelProduct') || !$this->registerHook('productFooter') || !$this->registerHook('header') || !$this->registerHook('adminOrder') || !$this->registerHook('backOfficeHeader') || !$this->registerHook('actionPSCleanerGetModulesTables')) return false; Deux hooks , pas moins , qui n'existent pas et donc une install qui ne va pas au bout. Ca vaut bien le coup d'avoir du code spécifique 1.5 et + la ligne d'après : if ((_PS_VERSION_ >= '1.5') && (!$this->registerHook('displayMobileHeader') || !$this->registerHook('displayMobileShoppingCartTop') || !$this->registerHook('displayMobileAddToCartTop'))) return false; Alors j'ai titré effectivement "Bugs en tous genres" parce que ce n'est pas le premier que je dois corriger chez un client , et ce ne sera probablement pas le dernier. Je ne vais pas lister ici tous les bugs que j'ai eu à isoler et fixer notamment avec certains types de bons de réduc mais je commence à en avoir ras le bol de voir les version se succéder sans que ces bugs ne soient corrigés et que d'autres viennent s'ajouter à la liste à chaque version. C'est vraiment si difficile pour une agence certifiée Prestashop et en charge d'un module si important de prêter attention aux bugs remontés par les utilisateurs ? Je vois des tas de "sticky" concernant paypal et pas un seul ne répond aux questions des utilisateurs qui rencontrent de véritables bugs et dont les posts se noient presque aussitot en 2emes page. J'ai vraiment envie de dire : 202, vous vous bougez le cul quand ? @ les modos je tiens à dire qu'il n'y a ici aucune insulte , aucune diffamation, et que j'espère bien échapper à la censure sur ce coup car il est temps qu'un module de paiement comme paypal ne soit plus le cauchemar des prestataires...
  13. Par "Hébergement mal configuré" , j'entendais un dédié sur lequel on aurait laissé les données du serveur mysql sur la partition système, qui est généralement sous-dimensionnée par rapport aux autres. Il arrive également d'avoir cette erreur lorsque la partition système est pleine (de logs le plus souvent) Il existe des apprentis hébergeurs qui commettent cette erreur... Il se peut également que tu sois sur une machine virtuelle et que l'espace physique alloué à la partition abritant les données soit arrivée à son "trop plein" Dans tous les cas tu n'y peux absolument rien , c'est du ressort et du devoir de ton hébergeur de faire en sorte que ce type d'erreur n'arrive pas. Pour ma part je penche pour le cas de figure "partition racine pleine", et il semble que ton hébergeur soit intervenu sans quoi l'erreur aurait persisté.
  14. L'erreur -1 sur une bdd mysql est le plus souvent un manque d'espace disque. Sur un hébergement maladroitement configuré on se retrouve parfois avec un stockage de mysql sur la plus petite partition. Il est également possible que ton hébergeur ait atteint les limites de son disque partagé entre ses différents sites... pas très glop... Pour les notices penses à inverser la manip proposée par Eolia pour activer le debug :
  15. Sans être absolument certain d'avoir tout compris , il semble donc que tu ais à dispo une version 1.5.2 de prestashop (pas stable du tout au passage) , et une autre en 1.6 dans laquelle tu souhaites rappatrier ton travail sur la 1.5 ? Si tel est le cas et si tu as accès à tes bases de données , le mieux est de passer ta 1.5.x en 1.6.y et de transférer les tables concernées d'une version vers l'autre ...
  16. Il semble que tu ais pu règler ton problème mais c'est un peu limite de parler de pseudo lorsque l'on parle de l'identité d'un client non ? Pseudo vaut pour les forums et les blogs , mais si on parle d'un prestashop ce que l'on récupère comme tu dis est un nom "pleinement qualifié". Je crains que ce simple fait n'implique que tu dois absolument afficher une politique de confidentialité bien claire à ce sujet. Je dis ça ... je dis rien ...
  17. Bonjour David, Puisque tu n'as pas plus de données et que tu dois les compléter , je prêcherais pour un import des données que tu as et une modif depuis storecommander Par avance je m'excuse de placer ici un lien commercial mais ça me semble répondre à ta demande. le fait est que tu pourras éditer tes descriptions et métas à la mode "csv" aussi bien , et que l'effet sera immédiat sans import supplémentaire. Maintenant le problème qui pourrait se poser, c'est si des champs mandatory/obligatoires n'existent pas dans ton flux de produits.
  18. Bonjour, Ces boutons sont ajoutés une fois que la page est entièrement chargée sauf erreur de ma part (chargement asynchrone/Ajax). Sous chrome il suffirait d'ouvrir la console javascript (F12 et onglet console) puis recharger la page pour voir si des erreurs javascript n'interrompent pas le traitement avant la fin. Ca pourrait fort bien venir d'un module récemment installé qui se greffe quelque part avant et plante le javascript. C'est vite repéré dans la console : les erreurs y apparaissent en rouge. Sous chrome il peut être également intéressant de cliquer droit dans le blanc de la console pour cocher la case "log xmlHttpRequests" afin de vois également la progression des appels Ajax Un copie de la console sur ton BO pourrait nous en dire bcp.
  19. Bonjour Alain, Il y a pourtant forcément quelque-chose qui rend les transporteurs inaccessibles ou invalides pour le contexte. As-tu vérifié tes tranches? N'y en a-t-il pas de vides ? Il y aurait beaucoup de choses à contrôler. C'est rapide mais il faudrait un accès back-office pour vérifier. Un accès front n'est pas suffisant. Je veux bien jeter un oeil si tu le souhaites mais il me faudra nécessairement une clé ...
  20. @Storecase j'espère bien que tu as résolu ton problème mais si toi ou quelqu'un d'autre rencontre ce problème il faut absolument vérifier si le thème installé n'a pas de surcouche particulière pour le module paypal. Pour cela il faut vérifier dans le dossier du thème , en ftp , que dans le sous-dossier modules du thème (/themes/modules/letheme/modules) , il n'existe pas un dossier paypal. Auparavant le module paypal était natif et certains thème intègrent encore un "looking" pour les modules de paiment natifs. Or ces tpls ne sont pas toujours compatibles avec les nouvelles version des modules concernés.
  21. Bonsoir, Une chose a essayer avant toute autre : se rendre dans paramètres avancés -> performances , en BO , puis chercher le bouton "Effacer le cache de Smarty et le cache de l'Autoload" Il suffit de cliquer sur ce dernier pour effacer toute trace de compilation smarty d'un module plus ancien. il faut également jeter un oeil au dossier du thème , via ftp , et verifier dans le dossier /themes/montheme/modules , s'il n'existe pas un dossier paypal qui reviendrait à une surcouche du module, ce qui peut avec une version modifiée avoir des conséquences dramatiques. Si un tel dossier existe dans le sous-dossier modules de ton thème , il faut le supprimer et réitérer pour le coup l'opération citée ci-dessus à savoir vider le cache smarty . Merci de tester et nous dire
  22. Bonsoir, Je voudrais préciser quelques bricoles. Il n'y a pas "Un" développeur du module ATOS pour prestashop. Il y en a plusieurs , et tous ne sont pas à 200€ HT , il en existe de très fiables à moins de 70€ ... Ceci étant dit. D'une part il faut savoir que peut être 1% des acheteurs de ce module ne savent pas qu'il faut avoir souscrit un contrat vad au préalable , bien que beaucoup de modules le précisent. Un module est un outil qui permet à votre logiciel e-commerce d'accéder à certaines fonctionnalités supplémentaires. Il est tout a fait normal et heureux qu'aucun de ces modules ne puisse se transformer en solution bancaire , ce serait la porte ouverte .... Je tiens à préciser une autre chose concernant ce que vous a dit "l'intégrateur ATOS" : ATOS ou plus exactement Mercanet fournit certes un guide d'intégration , gratuit il est vrai et c'est la moindre des choses (ils faut que leur solution soit présente sur le plus de plateformes possibles...) , mais en aucun cas ils ne fournissent de module prêt à l'emploi pour tel ou tel logiciel e-commerce. C'est important de le savoir car j'ai eu peut être ce genre de retour par 35 % de mes clients , à qui les vendeurs de la solution faisaient miroiter un plugin gratuit qui reste un simple guide d'intégration et ne vous permet en aucun cas de démarrer avec leur solution sur votre plateforme, qu'elle soit ou non prestashop. Je ne suis ni développeur de modules de paiement , ni affilié à prestashop et je pense que si j'interviens c'est parce que je pense que vous allez vous heurter à un mur si vous pensez attaquer celui qui vous a vendu ce module. A mon sens vous devriez simplement demander "aimablement" le remboursrment de votre achat en expliquant au vendeur que vous n'avez pas la solution et que vous n'avez rien pu lire qui puisse vous laisser penser que vous deviez souscrire à une offre tierce. je vous encourage vraiment à jouer la carte de l'arrangement amiable car même si tout n'est pas écrit , vous n'êtes pas non plus censé ignorer ce qui est le BA-BA du e-commerce et des solutions de paiement en ligne. Seuls les organismes agréés sont habilités à fournir une solution de paiement à distance (vad) , et ces derniers n'ont aucun intérêt à vendre des modules ou extensions pour des environnements e-commerce, leur objectif étant selon le cas soit de fournir gratuitement l'outil (mais atos n'entre pas dans ceux qui pratiquent ceci), soit de compter sur les solutions existantes basées il est vrai sur leur guide d'intégration. Je trouve étrange la réponse de votre interlocuteur mercanet à ce sujet , encore que j'ai tellement rencontré ce cas de figure et du expliquer à mes clients que leur code ne suffisait pas à avoir ATOS sur leur prestashop , que je pense que la personne que vous avez eu est plus un commercial qu'un technicien support. J'espère ne pas avoir été blessant , ce n'est pas mon objectif, en revanche j'ai pour habitude de dire ce que je pense parce que mes clients ne me paient pas pour entendre ce qu'ils aimeraient entendre. Du coup navré si je termine en disant que vous avez été un peu naïf dans votre acte d'achat, mais c'est en forgeant ....
  23. Bonsoir, Après une création de panier et en allant jusqu'au bout du tunnel de commande , j'ai bien la même page blanche .... Vraisemblablement en mode cloud , prestashop a tout de même prévu un accès ftp alors la du coup il faut se ruer dessus , puis éditer le fichier /config/defines.inc.php afin d'y activer l'affichage des erreurs , php et sql en passant le paramètre ligne 29 en principe : if (!defined('_PS_MODE_DEV_')) define('_PS_MODE_DEV_', true); // au lieu de false A partir de là tu auras des infos cruciales sur l'erreur rencontrée. Je note que le bug n'existe pas sur le module de paiement par virement , et que le bug existe avec le module payplug , car tu parles de paypal à la base, sauf erreur ? Bref si tu as activé le debug le temps d'obtenir un message d'erreur , alors il suffit de nous le coller ici pour qu'on puisse avoir une idée plus précise de la source du problème.
  24. makinero, Même punition , le module shopimporter n'a pas été mis à jour et est incompatible avec ta nouvelle version. A mettre à jour ou à supprimer. Après coup il y en aura peut être d'autres... Etant donné qu'il s'arrête dès qu'il rencontre une erreur fatale, tu n'es peut être pas au bout de tes surprises.
  25. Bonjour, Pour le problème d'affichage il faudrait tenter de vider le cache navigateur, ainsi que le cache smarty. Enfin actualiser l'affichage avec CTRL+F5 (si PC) Dans le pire des cas, en urgence il est possible directement dans la base de données de modifier la variable de configuration pour permettre aux clients de commander. Il faut vérifier aussi dans le dossier du thème si les tpl du modules paypal ne sont pas surcouchés. En d'autres termes, si il existe un dossier /themes/montheme/modules/paypal , il faut le supprimer. Mais le fait que l'installation n'ait pu aller au bout à cause de la requête sql implique qu'il y a des chances pour que la table utilisée par paypal ne soit pas correcte. J'ai déja du résoudre ça en ajoutant les champs manquant ou mis à jour. Une méthode qui ne demande pas de mettre trop les mains dans le camboui est de désinstaller le module complètement et supprimer la table payment_method ...puis tout réinstaller. Dans tous les cas il faut manipuler la base de données un minimum.
×
×
  • Create New...

Important Information

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