Jump to content

Broceliande

Members
  • Posts

    1,735
  • Joined

  • Last visited

  • Days Won

    5

Everything posted by Broceliande

  1. Je vais tenter une réponse simple du coup : la validation des CGV n'est pas à voir dans un contexte loi Hamon. Elle est obligatoire et contractuelle : cocher la case sur le tunnel de commande site est en quelque sorte une signature électronique du client (si l'acceptation n'est pas précochée). Elle est utile et indispensable : Elle vaut acceptation de tes CGV par le client. C'est le commerçant autant que le client que cette case protège en quelque sorte. Dès lors que l'on passe un contrat entre deux parties, quel qu'il soit, il est figé dans le temps. Le contrat ne peut changer sur le seul vouloir d'une des deux parties, et heureusement j'ai envie de dire. La loi hamon va plus loin certes que cette seule acceptation : il est logique que si le client n'a pas copie des cgv liées à son achat au moment de son achat , les cgv sont susceptibles de changer entre la date d'achat , date à laquelle il a "signé le contrat" ... Comme Mediacom87 le précise, d'ailleurs....
  2. redtango2, pour la blague, si les utilisateurs suivent tes recommandation et publient leurs déboires ici, la liste pourrait bien s'étoffer de manière incontrôlable . Je salue l'intiative et le partage. Je ne suis pas tout à fait d'accord avec ta classification par contre. Il existe des tas de modules certifiés et non certifiés de qualité. Il en existe encore plus de cauchemardesques, mais on ne peut pas vraiment dire qu'ils se trouvent plus sur addons qu'ailleurs, ou inversement. En réalité c'est pareil que dans n'importe quel supermarché. On trouve des merveilles à prix top budget et des grosses daubes de marques, et inversement. @ Xavier je salue l'initiative : corriger un titre que le topic perdure , ça c'est classe
  3. Indeed, but ... Do you really trust what you wrote Well i'm just joking but i do believe our friend just has no idea of what these messages mean. @asunaja : it seems that either your hosting doesn't fit at all with prestashop's prerequisites, or you need someone to handle it. Set write permissions.... means you have to make those directories writable by apache. This can be done with a ftp client and enough rights. If this doesn't mean anything to you then it's sure you need a pre-configured hosting or someone to do it for you. mcrypt : this is not required (though you'll loose a bit performances) but you have to set another library (rindjael) in place of it. that can be done in advanced parameters menu in BO -> performances (should be around the bottom of the page) . magicquotes should'nt be a trouble : you should check your php configuration and version. pdo_mysql : same for this mod, it should be installed by default on any real hosting solutions. Aren't you casually using a kind of wampserver locally rather than a real hosting ?
  4. C'est le moins que l'on puisse faire... Maintenant le fait est et demeure que Devnet a indiqué la procédure précise que n'importe quel développeur sur Prestashop pourrait appliquer. Il a pris la peine de rentrer dans les détails comme la duplication du module pour ne pas subir la maj etc. Ce que vous avez eu c'est une séance de consulting à l'oeil. Ce que vous avez écrit et ce qu'il en ressort, c'est que vous prenez les intervenants du forum pour vos larbins et que vous devriez préciser dans vos posts que ce que vous voulez c'est du tout cousu mais gratos et pas juste des orientations, aussi précises soient elles. Vous ne méritez pas une seule des réponses à vos 200 et quelques posts sur ce forum. Je suis ravi d'être tombé sur ce post car je vous ajoute aussi sec à ma liste de contacts...indésirables...
  5. Bonjour Vincent, Certes on peut cautionner le passage à des version supérieures pour profiter des derniers correctifs, mais ce n'est pas donné à tout le monde de refaire un design comme ça pour un changement de branche, notamment pour ceux qui on fait faire un design spécifique. Et surtout , surtout , ce bug n'est pas résolu dans la 1.6.0.9 , pour le coup une maj ne sert à rien en ce qui concerne ce bug en tout cas, cf ci-dessous. Cdt,
  6. Alors ça je ne peux que saluer ! Bravo et merci pour la communauté. Pour ma part j'ai également modifié ce module depuis la 1.5.4.1 pour au moins deux de tes 3 "plus" : multilingue, liens. Je ne l'ai pas testé mais je compte bien le faire. L'utilisation des awesome est un plus (que mon collègue intégrateur avait lui même ajouté sur certains). Tiens pour ne pas passer pour un baratineur voici un lien ou ma propre version est utilisée : http://www.mademoiselledanse.com/fr/ Tu constateras qu'il est bien multilingue également , et qu'il gère également les liens. Merci encore ! c'est une modification qui devrait avoir sa place dans les futures version de presta. Perso je n'ai jamais eu le temps de suggérer mes modifs sur github, mais je t'invite vivement à le faire, ce module n'étant pas anodin. Congrats, Regards,
  7. I agree with you on some points, not all though... but it has been discussed already. If you ask me, indeed you were the very first to answer to my post and had a negative approach. I did not get frustrated though but felt i had to give you my opinion. This is what i did. What followed was not motived by this post so don't think you were aimed. Didn't i told you you were free to use this patch or not ? No i wasn't referring to you , rather to some tweets wich stayed only some tweets and weren't reported there. Maybe you'll find next fix from community usefull . I don't mind at all, be sure of this. Yes Xavier i got your message as it was told. A bit too flattering i'd say huh ? Well you must have understood i was a bit annoyed with Prestashop's message you had to report us. What i must say is that only Prestashop has been affected by this issue , indeed due to recent changes in paypal apis. Those changes don't affect global technical specifications, but only some fields validating rules. In the present issue, Paypal looks to be ok to roll back those changes, nice. They seem to do this for Prestashop only you know ... This made me think the real "wargame" was between Paypal and Prestashop , @ prestashop's users detriment. Prestashop won , but users lost in some way... Nice to see you keep a dialog between Presta and its community. Remember i also said this was not the first topic growing out of proportion. As well you know it's not the first or last one . No use to preach a convinced "guy" (as somebody names me). I'd even be able to show you how a real conflict can lead to a consistent collaboration, proof is even there in the french forum. Just ask me in pm if you are interested in nice stories
  8. Hi Xavier, I'm sure you know that i don't ignore that at all and really care about it. Indeed large scale testing is needed before any release. Also you know we (community, contributors) would be the first to blame hasardous releases ... First of all i'd like to tell (again) that i did post this fix for thone (only) who were really waiting for an immediate solution. 3 of my own customers just could not not wait till thursday and use standard mode instead. For this reason i had to find them a way to keep HSS working. (Some customers are more exposed to fraud than others...dependind on what they sale...) I didn't expect once this fix would be merged in github, especially 'as it' (i mentioned i didn't find its code really pretty. i don't find the native prettier one on the concerned part however). I just posted it because someone on irc asked me to do so, and cause if some of my customers couldn't wait using the temporary solution given, this can be the case of many others so. Notice that i didn't joined any patched archive or php files to my post, so that only aware service providers can use it if needed. But if we had to technically speak about the side effects this (temp) fix could have, (maybe you can ask to this module's devs to have a look it), the very few changes i made are small enough to ensure they are safe without a very long battery of tests, and would keep working even after Paypal's rollback. This could have been a good opportunity to see why, for example, we are serializing an integer in actual code ($cart->nbProducts()...) and maybe choose to enforce security in the same way (eg : base the hash on something else than the cart's products count). That's why IMHO , i think it was worth to have a look at the module especially now that it temporary stopped to work with HSS, even if we can trust Paypal will effectively do this rollback. The strangest here, Xavier, is that my initial post caused such polemics, though it only was a fix suggested for those exactly who were already shouting and blaming both Prestashop and Paypal... Quite strange as well, a simple contribution caused such a debate while in final , the only thing Prestashop users were thinking about and asking for was a working module (with HSS on) , and not have to wait 3 days for it. My own comments or opinion about the "public" post you made about this issue is another topic. First it's essential to keep communicating with the community, even more in the present case : yes you communicated. There were and still are some points we don't and never agree on . (we = prestashop and i ) It always been and always will. (wouldn't be a real community otherwise, would it? ) Here, what i don't agree in your post is only that we are told the module isn't responsible in anyway and that we just have to be patient and wait for Paypal action. You may understand what i meant if you look around & see if other softwares were affected by this issue. I couldn't find myself such reportings on major e-commerce softwares. So i do think that we can't tell the module , even if it worked before and will work again in a few dozens of hours, that the module itself is absolutely not involved. Is this a negative though ? I don't think so. I always call myself into question. In any case, whatever anyone can tell or think about me, each time something similar happens in future, in case in think i have something wich may help some members, i'll act the very same way. Best Regards
  9. Hmm ... Not sure that flooding Paypal tech support will speed up things or help. What if you had a technical problem on your website or logistic or so ? Would you be able to answer all you customers if they start such flood ? I do think you just would stop answering any call or mail as any human would , and start focus on the trouble you have in order to solve it and please your customers again. Plus , if you have a look in previous posts in this topic you'll see that Paypal already tried to answered publically to this unwanted behaviour. You may also could consider that the Prestashop module could also have been updated to work with new paypal restrictions. In this case one click in your modules tab (in BO) to upgrade the module and keep working as usual would have been possible. I won't blame the module's developers cause they made the module following technical specifications given by paypal. However i wonder who has to follow who's directives in this case. Paypal is used by a lot of different e-commerce softwares. I'd like to hear about other plateforms : do they encountered the same issue? This would help to make us an objective opinion : Who should react first ? Paypal , Prestashop , the module's maintainer agency ? IMHO every of them should have reacted as fast as possible. It was possible to make paypal HSS work on Prestashop as soon as this morning by a very few changes in the module itself, with no use to rollback those changes after Paypal's own rollback, cause the ipn failure is only due to a too long variable sent to paypal and then ignored (indeed this is new, since it wasn't rejected b4). It is possible to send the same data we need to paypal an get it back in ipn without reinvent the weel. I posted a sample of it myself. There are other ways, but in anyway, that was easy to do it, quickly and safely... (it took me at least 3 times less than answering to those posts in this topic )
  10. Well this is up to you indeed, and up to your customers... Mine (some of mine at least... using HSS) didn't want to loose the payment guarantee , so i had to find a solution for them. The code i gave wich you call "hack", will still work after the announced "rollback" Xavier talks about. I did not post it there to hear why some or some others won't use it , but only for those who need it and do want it. Do i have to tell more ?
  11. Hi, thanks for the info , but Xavier also tells And as well : What's real in these is that paypal indeed modified something in some post handling. It doesn't send invalid data but no data for a variable the module uses to identify the cart to validate and get a signature. Technically , it is possible to keep HSS working without loosing the cart_id nor the signature, just by changing the way to send this needed variable and make it smaller and cleaner, so that paypal send it back to ipn...the workaround i described doesn't alter the module's security at all. The same variables are visible in the form in both native modified code. I can't quite understand why you remind Xavier's post right now , while number of customers do want to keep HSS on :s . What's wrong if there a way , to share it?
  12. Hi folks, It really seems that paypal added some restrictions either on the field length, or its type. So for a customer i made this to make it work : in paypal.php i made the smarty assign a bit diffrent around line 524 , with no fields name nor json_encode. only the cart_id and the shasign , just split by a double "|" 'custom' => $cart->id."||".sha1(serialize($cart->nbProducts())), Then i modified ipn.php to rebuild them as they are used anywhere else in the code. arround line 248 my whole code look like this : if (Tools::getIsset('custom')) { $custget = explode("||",Tools::getValue('custom')); $custom = array('id_cart'=>$custget[0],'hash'=>$custget[1]); $ipn = new PayPalIPN(); $ipn->confirmOrder($custom); } i had to modify around line 159 this way as well : $custget = explode("||",Tools::getValue('custom')); $custom = array('id_cart'=>$custget[0],'hash'=>$custget[1]); I dont find this workaround really pretty , at least it works and isn't that worst than the existing code...
  13. C'est assez rassurant que les acheteurs soient privilégiés, disons que leurs droits ne soient pas bafoués. Couvrir le client est le but n°1 : un compte usurpé, un litige = transaction annulée ou fonds bloqués ... même si c'est une fausse déclaration oui c'est vrai. Mais paypal ne s'en cache pas puisque pour que les commerçants puissent convaincre via ce mode de règlement , il est clair que ce dernier doit rassurer l'acheteur , non ? Le reste me semble hors sujet ... bon ok y'a d'autres solutions, mais ce qui compte pour le commerçant est de rassurer le client. Perso , si je me place en tant qu'acheteur au lieu de prestataire, Payplug connais pas ... Dans ce cas autant laisser juste un vrai tpe , et ne laisser qu'une solution 100% bancaire. Certes il n'existe pas que paypal , mais pour être rassuré (oui c'est vrai que ça fait 3 fois que j'utilise le terme , ça doit bien représenter le fond de ma pensée du coup ) , le client e-commerce a besoin de connaitre la solution et s'oriente le plus souvent vers la plus connue. C'est un peu comme tous les portefeuilles électroniques qu'on proposait partout à un moment donné. Aujourd'hui combien de commerçants physiques utilisent encore du moneo et autre pf electro ?
  14. Il suffit que tu l'ais validé au moins une fois sous firefox ... Est-ce qu'il s'agit bien d'un certificat certifié ? Car si c'est un certif self made alors il ne faut plus se poser de question.
  15. Même si je suis pas fan de ce module , il est en adéquation parfaite avec le topic ! Ne serait-ce que le nom ... J'ai eu connaissance, il faudrait le retrouver , d'un module 100% javascript (le configurateur visuel est en flash) , qui est capable de sortir des BAT 300 dpi ... Il n'était pas cher , genre moins de 250€ , et son développeur était vraiment motivé pour le faire évoluer. J'ai honte de ne pas me souvenir du nom et du lien de ce module. Il était parfaitement adapté à cette demande. Je vais chercher quand même .
  16. Tout ceci est possible avec le multi-boutiques , avec peut être un bémol sur paypal qui pourrait utiliser une configuration globale plutot qu'une configuration par boutique. Deuxième bémol c'est le nombre de boutiques possibles pour des performances correctes... Après c'est vraiment un projet étrange. On connaissait déja le Drop Shipping (Pas de stock , vous vendez un article et vous le commandez au moment de la commande, au mieux le fournisseur l'expédie avec un carton neutre ou personnalisé à votre label), et toutes les demandes les plus farfelues qui y sont liées, là on découvre le concept du Drop Selling ... : Pas de stock , pas de commande fournisseur , juste de l'encaissement et plein de boutiques pour promouvoir un seul et même catalogue. Euh non c'est pas si nouveau comme concept , mais la méthode oui , partout ailleurs on parle d'affiliation. Enfin bon c'était pas pour démonter le truc, mais à priori , du multi-boutiques et hop le client a ce qu'il veut.
  17. Hi tous, Il existe un ensemble de disfonctionnements que l'on peut éviter lorsqu'on met à jour prestashop et surtout le module Paypal. Ce module a changé de nombreuses fois et considérablement évolué depuis la version 1.4.8.2 ... Selon la version de prestashop utilisée, il faut dire que l'on constate qu'une version plus récente du module ne fonctionne pas alors qu'une plus ancienne fonctionne. Il existe un problème récurrent auquel se heurtent bon nombre de commerçants, ou leurs prestataires, lors des mises à jour vers une version récente indiquée comme compatible. Ce qu'il faut savoir et appliquer avant de tester une nouvelle version du module paypal : - De nombreuses valeurs de configuration existant dans les versions précédentes du module n'existent plus dans les nouvelles. - Certaines valeurs dans les nouvelles versions changent ou ne sont pas utilisées. Il convient donc avant chaque nouvelle expérimentation d'une version de module d'effectuer ceci : - Désinstaller le module complètement, le supprimer. Edit du 27/11/2014 : Surtout , à chaque install ou désinstall : videz votre cache smarty !!! - Vérifier dans le dossier du thème s'il n'existe pas de surcouches tpl, css ou js de ce module. (j'en ai trouvé plein de fois , trop tard et à mes dépends) Pour cela il suffit de vous rendre dans le dossier du thème , et d'explorer les dossiers modules, css/modules , et js/modules pour voir s'il existe ou non un dossier paypal. S'il existe : pas glop faut supprimer , parce que du coup on mélange les versions... - La phase la plus délicate mais pas difficile non plus : trouver un accès à votre BDD (en générale via phpmyadmin) . Sauvegardez par acquis de conscience votre table prefix_configuration (le plus souvent ps_configuration ) en utilisant l'outil d'export. Les plus aguerris feront simplement (remplacez donc ps_ par votre préfixe si besoin) un delete from ps_configuration where name like "%PAYPAL%" Les moins à l'aise iront afficher la table ps_configuration et devront chercher toutes les variables de config contenant PAYPAL dans les différentes pages de cette table. Ici CTRL+F is your friend car dans la plupart des navigateurs, cela ouvre un champ de recherche qui vous permettra de trouver sur une page une chaine précise. Bref quand vous en trouvez une , chercher l'icone corbeille à droite de la ligne et supprimez là. Enfin vous pouvez uploader et réinstaller le module et le tester dans des conditions réelles. Je vous assure avoir pu résoudre toutes sortes de problèmes rencontrés par des clients avec paypal en opérant simplement cette opération de "nettoyage". Dire qu'à priori prestashop ne valide pas un module soumis à addons s'il laisse la moindre variable de config dans la bdd !!!
  18. La première approche est à proscrire (frais de livraison augmentés), la deuxième (taxe sur le mode de paiement) est meilleure, quoique... Il n'est pas légal de répercuter des frais supplémentaires dus à un poste x sur un poste y , ce qui place les acheteurs en position défavorable par rapport à d'autres . De plus si tu impactes les frais de livraison , alors que tu ne connais pas encore le mode de paiement , tout le monde est donc impacté ? Malheureusement je ne crois pas qu'il soit légal non plus de surfacturer un moyen de paiement. Par ailleurs, le récapitulatif de commande vaut contrat de vente. Le client à ce stade doit pouvoir finaliser sa commande au tarif qu'il valide. Si les frais paypal sont trop élevés, il existe une solution simple, la seule valable à mon sens : faire une moyenne des frais de paiement sur une période suffisamment longue et l'intégrer dans la marge globale. Cela risque évidemment d'augmenter tes prix de vente, mais il n'y a pas de solution miracle. Soit tu vends moins cher à tout le monde et tu ne proposes que la solution de paiement qui te coute le moins, soit tu as des frais réels et tu dois les répercuter dans ta marge. Navré pour cette réponse qui n'est pas une solution à ta question , en soi.
  19. Il n'existe pas d'autre moyen pour contourner ce problème que de modifier le module paypal lui même. En fait paypal lui même ne modifie rien sur prestashop (comment le pourrait-il d'ailleurs?) Tu as raison : le module crée une adresse et elle vient se placer en remplacement de celle choisie par le client. Le développeur du module a répondu avec zèle à la demande de paypal. Côté légal , je doute que celà le soit (légal) : le client commande et choisit une adresse de facturation , puis une adresse de livraison. Pour le client final , l'adresse de livraison choisie avant validation a été modifiée sans qu'il en ait même été averti : le contrat de vente est donc nul et non avenu. C'est bel et bien le module qui opère cette modification. Le moins que l'on puisse dire est que 202 communique (enfin used to...) beaucoup , si l'on en juge tous les topics épinglés (mais parfaitement inutiles). En revanche les vrais problèmes ne sont pas règlés et le module prend des libertés sur prestashop que l'on peut envisager comme un abus de "droits" (plutôt que de pouvoir). Parmi ces libertés , celle de modifier les adresses contractuelles de la commande. Celle de modifier les logos présents dans un dossier du module ... peut-être celles que l'on a pas encore découvertes... Ce qui est certain , c'est que Paypal a des conditions générales de vente et d'utilisation que les commerçants l'utilisant doivent accepter. Il est presque certain que 202 qui a développé le module a voulu suivre les indications de paypal à la lettre. Certes cela évite à Paypal bien des vérifications, mais ce genre de magouille n'existe pas dans le guide d'intégration officiel. Seules existent le conditions d'utilisation (plus draconiennes encore si l'on veut la garantie des paiements... paypal intégral évolution dans le texte) Il n'en reste pas moins certain que dans le cas présent , c'est le développeur du module qui effectue ces micmacs et rend le contrat de vente caduque. Je pense qu'il est bon que les commerçants en soient avertis. On ne dira pas que ça n'a pas été dit
  20. Le fait que la désactivation des cdn résolve le problème rencontré ne signifie qu'une chose à mon sens : - La version du js présente sur les cdn n'est pas la même que celle du module paypal utilisé. Lorsque l'on effectue une maj quelquonque sur prestashop , et que l'on utilise CCC pour le js (ce qui est bien évidemment recommandé) , alors simplement , il faut purger le/les cdn. Je propose cette première approche qui me semble la plus logique. Il est préférable de purger les cdn et continuer à les utiliser que de les désactiver. C'est un réflexe à prendre dès lors qu'un js ou un css change. Il faut savoir que pour un souci de performances, activer les ccc implique que les css et js de plusieurs modules et de controleurs front office sont Compressés (on retire tout ce qui est espace, retour à la ligne etc pour un fichier plus light) et Concaténés (mis bout à bout) . Ceci donne à l'exception des modules n'utilisant pas la "bonne" méthode d'ajout de css ou de js , un seul et unique fichier pour l'un et l'autre. Js et css sont des ressources mises en cache par tout cdn, du coup , cqfd : on change un truc ou on constate un comportement différent avec et sans cdn = on purge et le tour est joué. Si les symptômes persistent après cette purge , il est urgent de consulter
  21. @parslow je comprends bien ce que tu dis et je ne te contredis pas, d'autant moins que je n'ai pas étudié ces nouvelles normes. Mais tu confirmes en quelque sorte ce que je suggérais, à savoir que si aujourd'hui certain pratiquent autrement , la plupart des e-commerçants devront continuer à faire du redirect pour le paiement, même si la mode / la tendance aujourd'hui semble aller dans le sens inverse. Dans le cas de la redirection donc , je suppose que nous somme d'accord, c'est bien le prestataire de paiement qui doit être certifié et non le e-commerçant. Je suppose que ceux qui le sont ne manqueront pas de l'annoncer fièrement en temps voulu , car les autres n'auront très vite plus qu'à se mettre au pas ou s'abstenir. Je ne vois pas ça globalement comme quelque chose de négatif. En réalité j'ai en horreur les sites qui sont à même de de débiter à nouveau sans aucune intervention de ta part (hormis un simple clic , au mieux) . Quand je parlais des inconscients qui stockent des données de ce type parce qu'ils ont la fierté d'accepter les paiements direct sur leur site et que ça fait pro , on m'a relaté l'anecdote d'un de ceux-ci qui a tout perdu , mais alors vraiment tout , pour avoir voulu à tout prix avoir une page de saisie cb , inline , certes sous ssl mais qui a s'est vu rétroactivement débité de l'intégralité des transactions , même licites , effectuées sur son site. C'est une histoire que m'a raconté un collègue spécialisé justement dans les solutions d'hébergement de pages de paiement certifiées. Plus que les utilisateurs de Prestashop , ça risque de mettre une belle claque à des plateformes de vente comme apple store, google play , facebook etc ... Mais ça , je le vois plutôt come de bonne augure pas vrai ?
  22. Je voudrais pas me ridiculiser là dessus mais sauf erreur, qu'on y vienne ou non , la norme ne s'applique qu'aux interfaces bancaires, celles là même qui manipulent les données. Dans la majeure partie des cas, ces données sont gérées "outside" ... En dehors de quelques gigantesques commerçants , ou certains d'une gigantesque ânerie, les données bancaires ne transitent pas sur ou par la plateforme e-commerce . Ce qui se passe sur un log e-commerce comme Prestashop pourrait être shématisé (comme je le dis , dans la majeure partie des cas, il peut y avoir des axceptions) de cette manière : - Le client crée son panier et le valide sur la boutique en ligne. - La boutique en ligne redirige le client vers l'interface de paiement en indiquant simplement quelques références, mais aucune donnée bancaire, et surtout le montant espéré... - L'interface bancaire valide ou invalide le paiement , fait sa sauce, et prévient à sa manière le site e-commerce si cette transaction a été effectuée avec succès. J'ai vu des cas ou le e-commerçant utilise un enrôlement CB et effectivement propose une interface de saisie de CB par exemple. Là en effet, le serveur qui héberge la page de saisie doit d'ores et déja être certifié PCIDSS (2 peut être , pas forcément 3). Quand je parle d'enrôlement , il faut simplement comprendre que les données liées à la carte sont saisies depuis une page appartenant au commerçant , mais pas stockées. L'enrôlement effectué , la demande de paiement utilise un id pour demander une transaction sur la CB concernée, eg la plateforme Payzen et ses webservices. Reste que les commerçants qui stockent ces données eux même sont parfaitement inconscients... C'est vrai qu'il en existe. Je garde à l'esprit que cette sécurisation des paiements , si elle est nécessaire, ne doit pas être de la responsabilité des commerçants, mais des plateformes de paiement et des établissements bancaires. Chacun son métier.
  23. C'est assez étrange comme question parce que je n'arrive pas à comprendre ce que tu cherches à faire. En fait tu as déja , en principe , le nom de la catégorie courante dans un h1 (à priori) , sous une forme du type : {$category->name|escape:'htmlall':'UTF-8'} Ensuite dans le tpl il y a une boucle qui affiche les sous catégories, et effectivement un titre au dessus qui dit en gros "Sous catégories". Qui dit boucle en smarty dit foreach , mais toi tu cites le titre , alors j'avoue me demander ce que tu cherches réellement à obtenir. Admettons que l'on soit dans la catégorie "Cat 1" Admettons que dans cette catégorie nous ayons 3 sous-categories "Cat 2,Cat 3,Cat 4" Que veux tu réellement avoir à l'écran ? Pour info cette notation : {l s='subcategories'} est simplement une traduction. la fonction l est utilisée par prestashop pour traduire les chaines "fixes". l s='tata' va créer une chaine traduisible que tu pourras trouver dans les traductions front office. Par défaut , et à moins de la traduire, cette chaine sera et restera "tata" ... Ici donc subcategories est une chaine traduisible et non une variable contenant un nom de catégorie ou de sous-catégorie. Tu me suis ?
  24. Je pense avoir suffisamment nuancé mes propos : Je peux me tromper mais ça ressemble presque à une proposition de service là ... Ca me regarde autant que chaque utilisateur du forum puisque le topic est public et que tu as suggéré ceci en public. Je répète qu'il est dommage de terminer en privé un sujet auquel d'autres ont participé. Si vous êtes tous deux Guadeloupéens c'est top mais ça ne pollue pas le topic de faire une apparté conviviale : un petit hors sujet sympatique c'est pas rédhibitoire. Libre à toi déchangé en pv avec geriko mais dans ce cas tu pouvais lui proposer directement en message privé. Je ne suis pas non plus quelqu'un qui vient à la pêche aux clients sur le forum. Je viens et participe aux sujets qui m'intéressent tout comme toi. Lorsque j'en ai le temps je passe parfois plusieurs heures à dépanner un e-commerçant qui en a véritablement besoin , et ce bénévolement je précise. Le forum est pour moi un terrain d' échange et de détente , pas mon terrain de chasse. Je n'ai véritablement rien à prouver à ce sujet.
  25. Je peux me tromper mais ça ressemble presque à une proposition de service là ... Et surtout je ne vois plus l'intérêt du topic et encore moins d'y avoir participer s'il doit se terminer en "PV" . Bref ça me semble décalé comme post, Sofresh sois tu
×
×
  • Create New...

Important Information

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