Jump to content

Broceliande

Members
  • Posts

    1,735
  • Joined

  • Last visited

  • Days Won

    5

Everything posted by Broceliande

  1. Bonjour, Il suffit simplement de supprimer le dossier /modules/paypal Paypal n'étant pas(plus) un module natif, il n'est pas mis à jour lors du passage a la 1.6 Comme c'est un module, dans le BO, il est analysé par la classe module, ce même s'il n'est pas installé. Or la version 1.4 contient effectivement une version de validateOrder obsolète.
  2. Cedric , tu ne précises pas, es tu en paypal integral évolution ou integral ?... c'est important le mode... J'ai corrigé ce bug déjà pour un client en intégral évolution et utilisant la version 3.8.1 du module paypal. Ce n'est pas une question de priorité. Tu peux nous dire? Si c'est HSS on peut faire un test rapide.
  3. Intéressant comme réponse à la concurrence.... Effectivement depuis deux ans Sora Caisse tourne avec des fonctionnalités utiles, identiques je ne sais pas , je n'ai pas le recul suffisant , mais ça fait aussi deux ans que Sora caisse s'assoit sur ses acquis et que l'interface reste toujours aussi glauque. Je trouve toujours intéressant de pouvoir comparer. Il faut savoir accepter la concurrence
  4. Pour un "défilement d'option" comme vous l'abordez, Je pense que simplement vous n'avez pas étudié la notion de déclinaisons. Pour l'envoi auto de mails lors de l'inscription ou de commandes, c'est le module alertes email soit mailalert qu'il faut configurer. ... A noter que si ces notion vous échappent complètement vous avez alors besoin d'un débriefing à leur sujet
  5. C'est exactement à ça que je pensais en disant qu'il y avait surement plus simple , sauf qu'on a un peu moins de données avec celle ci et il ne faut pas oublier de spécifier la profondeur... Je voulais pas rentrer dans le compliqué et aller ouvrir la classe lol
  6. John77, Tu surcharges CategoryController et tu fais ton assign smarty sur les pages listings pour le coup. Donc par conséquence tu ne retrouveras pas tes variables dans ProductController et donc dans product.tpl. De plus , si dans les listings $products est un tableau associatif, dans la fiche produit , $product est un objet de la classe Product. Pourquoi ne pas simplement créer une override de Product et y ajouter une méthode unique genre getSubCategories(); ça ressemblerait à ça (à la louche et de tête hein je n'approfondis pas... donc c'est du code un peu yahourt ): public function getSubCategories(){ $subcats = array(); $category = new Category($product->id_category_default); $subcats = $category->getSubCategories($this->context->language->id); foreach($subcats as &$subcat){ $subcat['subcategories']=array(); $subcatobj = new Category($subcat['id_category']); $subcat['subcategories'][] = $subcatobj->getSubCategories($this->context->language->id); return $subcats; } Pas certain qu'il n'y ait pas plus simple mais bon ... Dans product.tpl tu récupères un tableau complet en une seule fois avec $product->getSubCategories(); a toi de dumper la variable pour voir comment elle ressort pour l'exploiter ensuite.
  7. Bonsoir, As tu vidé ton cache smarty ? (/tools/smarty/compile dans ton cas) , et le cas échéant le dossier /themes/tontheme/cache. Dans les deux cas ne pas supprimer le fichier index.php ....
  8. Je confirme ce que dit ChDUP : la solution est propre et sans bavures, surtout si cela se fait dans une surcouche propre du thème. La seule solution plus propre serait que le module paypal le soit (propre) , mais ça c'est pas gagné ....
  9. Sauf Erreur tu as activé le paiement en 1 clic du module paypal. De par le fait tu auras souvent ce genre d'erreur , que tu dois ignorer... ou alors simplement tu reste sur un tunnel de commande standard et tu désactives cette fonctionnalité (je le recommande)
  10. Bonsoir, tu as probablement une erreur javascript qui plante la console et du coup envoie le formulaire directement sans passer par le .submit() Sous Chrome(et sous PC snif, pour mac je sais pas), tu peux t'en assurer en faisant F12 sur la page de paiement , cliquer sur l'onglet console, puis un F5 pour recharger la page et voir les erreurs.
  11. Je rejoins Natsu, Le post d'Eolia est intéressant et important. En ce qui me concerne, je n'y vois pas de référence particulière à un prestataire donné, mais un avis utilse sur l'hébergement en générale. J'ai vu un nombre incroyable de clients pris en otage par leur hébergeur faut de pouvoir obtenir des accès ftp etc dus par tout hébergeur au client. Résultat : Un exemple parmi d'autres , modif d'une image sur le site : 250€ . Je ne cite aucun prestataire non plus , je dis juste que j'ai vu ce genre de cas de figure à de nombreuses reprises, et que j'ai du tout aussi souvent contacter moi même l'hebrgeur pour lui rappeler ses obligations et obtenir de quoi intervenir moi même sur ce que me demandait le client, à savoir à chaque fois quelque chose de précis pour lequel le prestataire s'avouait lui même incompétent. Bref une mise en garde aux e-commerçant n'est pas hors sujet dans cette rubrique, et je ne vois pas trop le but de lapider Eolia pour Topic utile et ne citant personne. A moins de vous sentir directement visé , vous avez pollué ce topic qui aurait pu s'étoffer de points utiles sans pour autant devenir diffamatoire.
  12. Quelque précisions si celà peut t'aider : Dans (ps_)category: - la catégorie root doit avoir son id_parent à 0 , et ne pas avoir is_root_category (un truc comme ça de mémoire) à 0 , contrairement à ce que l'on serait tenté de penser - la catégorie accueil doit avoir comme parent l'id de la categorie root et elle doit avoir le champ "is_root" à 1 (une drôle de logique de conception je te l'accorde) Dans la table (ps_)configuration (selon le préfixe), il y a deux valeurs importantes : PS_ROOT_CATEGORY et PS_HOME_CATEGORY. il faut vérifier que que les ids soient les bons et les ajuster dans le cas contraire... Il peut également être nécessaire après des manips successives et surtout quand celà ne fonctionne pas de reconstruire l'arbre ntree. Cela se fait en appelant depuis un controller (donc dans un contexte presta avec les classes chargées) : Category::regenerateEntireNtree();
  13. Oui c'est ce que mon deuxième post suggérait. Le problème ne se situe ni au niveau de bind ou d'apache mais sur le fait que tu veux utiliser plusieurs domaines sur une seule boutique et non un domaine par boutique. La 301 provient de l'utilisation de l'url canonique et donc du .htaccess Cette redirection provient d'une configuration présente dans préférences -> seo et urls : rediriger vers l'url canonique. Il est donc possible de désactiver cette redirection mais pour le coup : attention au duplicate content ! Si une seule boutique a plusieurs urls, tu dois t'assurer d'une manière ou une autre que chaque url a et utilise une seule et unique langue. Ceci n'étant possible qu'avec un module spécifique (il en existe). Le duplicate content peut signer l'ordre d'exécution d'un site alors si tu as un module qui analyse l'url et ne sélectionne qu'une langue, on est ok , à condition de ne pas offrir le choix de langue au client final. Sinon c'est duplicate et la seule méthode possible est le multi boutique dans un contexte 1 shop = un domaine = 1 langue.
  14. Salut, Toutes les actions générées par les helpers peuvent être implémentées dans ton AdminController en prenant soin de surcoucher toutes les méthodes d'adminController (et par héritage, de Controller) basées sur ObjectModel. En fait tu focalises sur les helpers, mais je pense que ton pb vient de ton controller admin. Jette un oeil attentif aux paramètres get ou post envoyés par tes différents boutons générés par ces helpers. Tu trouveras des noms de variable ou de submit , qu'il faudra rechercher dans la classe AdminController.php pour identifier la méthode qui les traite. Dès lors, tu peux implémenter ta propre méthode dans ton controller et ne pas utiliser l'automatisation type 'objectModel' Pour tes affichages en doubles, je suppose que tu appelles parent::initContent dans ta méthode , or tu dois la réimplémentér entièrement sans appeler le parent. Celle ci ou une autre d'ailleurs que tu peux ne pas avoir implémentée. C'est léger comme piste je sais mais vu l'heure je n'ai pas le temps d'en faire plus.
  15. Malheureusement pour ce genre de problématique il faut déplier au max les sous-catégories quitte à avoir une redondance. En fait je pense qu'il manque un niveau de catégorie à la base , au minimum dans les roues : --> Roues --> Marque véhicule --> Modèle véhicule --> Taille roue --> Pneus ! A ce stade il est facile de glisser dans l'arbo les pneus dispos puisqu'on est au bout de cette arbo (on a donc bien le modèle voulu et la taille de roue). Bien sûr on aura pris soin de laisser le produit dans la catégorie Taille roue (et par défaut) Il devient alors facile de récup l'id de la sous catégorie fille de la catégorie par défaut de la roue, de l'instancier et d'en lister les produits (voir Category->getProducts() dans la classe Category).
  16. De manière générale non , mais as-tu essayé au moins d'activer le configurateur de thèmes ? Un thème 1.6 bootstrap digne de ce nom devrait au moins l'implémenter, ce qui pourrait donner au moins quelques possibilités de variations de couleurs et de polices... Sinon de toute façon clairement il faut mettre les mains dans le cambouis et encore on n'a pas parlé de sass ... à supposer que les sass soient fournis avec les thèmes uhu ... C'est plus dur d'approche mais ça simplifie énormément la vie.
  17. Mince je viens de réaliser quelque-chose : tu as ajouté les domaines mais tous pointent sur la même boutique n'est-ce pas ?
  18. Bonsoir, On peut déja oublier la notion d'ip failover ça ne servira pas ta cause. tu dis bien être en multi-boutiques. Dans ce cas chaque boutique peut avoir sa propre url canonique et ses propres urls (si on a monsite.de et www.monsite.de par exemple). Ceci est primordial dans la configuration multishop mais je gage que ce n'est pas le pb. Tu dis que chaque domaine a sa propre zône, dans bind (j'en déduis que tu utilises ton dédié comme serveur dns , ce qui n'est pas prudent mais on pourra en débattre plus tard) . Quid de la config apache ? Si chaque domaine a sa propre config apache , on touche de près à la source du pb. le domaine worldwide étant le .fr chez toi , les autres domaines en .it .de etc doivent juste être des alias du domaine principal. Dans /etc/apache2/sites-available tu devrais avoir un seul de ces domaines configuré , et dans le fichier concerné , voir apparaître les autres en "ServerAlias" ... Pour résumer il faut checker ces deux points : - config des urls des boutiques dans la config multiboutiques - config apache unique pour l'ensemble des domaines.
  19. Ce que l'un et l'autre décrivez, c'est pour moi le résultat d'une mise à jour d'une branche 1.4 vers une Branche 1.5 ou 1.6 Mais ni l'un ni l'autre ne le précise. Par le passé j'ai eu à rectifier l'agencement des catégories accueil + root , notamment leur valeur de configuration en BDD. Mais là il faudrait nous en dire plus : y a-t-il comme je le présume eu mise à jour , et si oui de quelle version vers quelle version ?
  20. +1 oui c'est une très juste remarque, mais si Jean.M veut utiliser une page html , et veut du responsive, alors la page elle même peut l'être sans nécessairement utiliser bootstrap. C'est à lui de s'en assurer . De toute évidence ma réponse est dans le cadre ou il souhaite le faire lui même et comme il semble le faire, mais pas "si on voulait le faire correctement..." , là c'est une autre affaire. En même temps j'ai le sentiment qu'un template de page de maintenance avec chrono , c'est plus pour annoncer l'ouverture d'un site que pour un usage régulier. Parce que dans le cas contraire ça n'a rien de pratique , dès lors qu'il faut remettre le compteur à jour à la mano à chaque mise en maintenance. Pour ça faudrait encore que ce soit paramétrable
  21. En fait votre réponse est là, dans ce deuxième post. Pour chaque statut/état de commande (administrables depuis le BO -> Commandes -> Etats (ou statuts peut être selon la version), il existe un paramètre : permettre au client de voir sa facture. En décochant cette option pour tous les états de commandes similaires à une attente de paiement , alors en principe la facture ne sera pas générée et donc n'incrémentera pas le compteur. On peut s'intéresser également au parmètre "Considérer la commande comme valide" . Je conçois toutefois qu'il peut être génant en B2B de demander un paiement sans faire de facture. Dans ce cas il existe des modules de "devis" simples qui imprimeront un devis sans générer de n° de facture. La facture sera naturellement disponible et générée normalement au passage au statut de paiement valide pour vous ....
  22. Outre le fait qu'il faut absolument lire l'excellent article de Devnet sur le syndrome de la page blanche, il faut penser au fait que lorsqu'on met à jour un module , n'importe lequel , il est primordial de vider à chaque fois le cache smarty après la nouvelle install. C'est encore plus vrai pour le module Paypal qui selon les versions utilise des tpl et des données vraiment différents.
  23. Bonsoir, Un tpl est une extension par un language de programmation du format html à la base. Qui peut le plus peut le moins : un .tpl peu ne contenir que du pur code html . Donc la solution est de prendre un éditeur de texte comme notepad++ (de préférence pas notepad pour conserver l'encodage) , d'éditer les deux et de faire un copier coller tout bête en remplaçant bien sur l'intégralité de maintenance.tpl. Par contre attention au code javascript (puisqu'on parle de compteur il y en a forcément) : si le code javascript est dans le html directement, il faut repérer tous les { et } et s'assurer qu'on a un espace avant et après chacun de ces caractères , faute de quoi du code javascipt peut être considéré comme une instruction smarty et forcément pour le coup , une instruction qui plante.
×
×
  • Create New...

Important Information

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