Prestashop l’override des thèmes trop complexe

Comment garder une structure de thème toujours propre pour Prestashop ? Quand je fais l’installation d’un thème pour un client, très vite ça devient le bordel… pourquoi ? Il faut que je vous explique la situation écoutez bien….

Un thème Prestashop… ça fonctionne bien
Ben oui c’est pas très compliqué quand on installe un thème Prestashop, on a un nouveau répertoire dans /themes qui contient le thème installé, avec à l’intérieur une structure toujours similaire… Quand on fait l’installation basique ça va bien, mais plus j’avance dans le projet… plus je perds du temps… je mélange… je m’énerve.

Qu’est-ce qui est pénible ?
Ce que je n’aime vraiment pas c’est l’override des modules (écrasement du comportement de l’affichage des modules en plaçant les TPL et les CSS dans le thème). Du coup vous aurez par exemple dans votre arborescence de projet :

/themes/tontheme/modules/monmodule/fichier.tpl
/themes/tontheme/css/mododules/monmodule/styles.css

Bah… c’est cool non ? Cela semble clean et propre ! Mais je vais t’expliquer 1 ou 2 trucs…

Des arborescences similaires et à perte de vue
Juste ci-dessus j’ai montré vraiment un cas simple, mais très vite pour certains modules on se retrouve avec des arborescences gigantesques… et qui sont présentes 3 fois (1 fois sous modules, 2 fois dans le thème). Mais bien sûr il faut prendre uniquement les TPL et les CSS… le PHP et autre ne doit pas être pris en compte… du coup il faut-être méthodique pour pas perdre la tête.

Certains modules utilisent une foule de répertoire… du coup il faut naviguer loin dans le projet et le risque de confusion arrive souvent (surtout si on fait des recherches globales dans le projet pour modifier le CSS etc…). On perd du temps aussi à circuler dans ces arborescences qui se ressemblent… ou alors je suis le seul à ressentir ça…

Des overrides qui ne marchent pas
Les 3 premiers modules que j’installe, ok je fais l’effort de bien séparer la partie template à chaque fois… en mettant le CSS et le TPL dans le répertoire du thème… Seulement voilà pour les 2 autres modules Prestashop suivant, l’override ne marche pas. Du coup… il faudrait fouiner le code… et l’adapter… et suivant le module… je vous explique pas l’opération… c’est long et fastidieux de comprendre. Du coup ces modules… je peux pas les overrider correctement… alors je les laisse dans « modules »… En final cela perd son sens… car j’ai des modules qui sont overridés dans le thème et d’autres pas (qui restent sous /modules)… c’est donc un mélange et je sais plus lequel j’ai customisé…

Alors on fait quoi ?
Et bien actuellement je ne laisse pas de répertoires « modules » dans le thème, j’écrase directement l’original dans /module… cela me donne plusieurs avantages :

1) Il y a un seul fichier TPL / CSS et j’évite la confusion
2) Je ne parcours pas les arborescences inutilement
3) Localisation + rapide pour localiser un changement à faire
4) J’ai pas de problème d’override avec des modules qui ne le supportent pas

Et quand tu feras une mise à jour ?
Actuellement les mises à jour c’est pas trop mon truc, je ne fais pas de mise à jour avec les clients. Par contre, je suis plutôt orienté « refonte »… mais mise à jour pas vraiment…, car une fois que ça tourne bien on ne va pas toucher à la boutique.

Propose une solution… si t’es si malin !
Bon ben… moi je pense que séparer c’est bien… mais qu’il faudrait faire plus simple que de commencer à faire des tris… Idéalement le plus simple serait de copier tel quel l’intégralité du module dans le thème et là on retouche ce qu’on veut… Cela permettrait aussi de modifier le comportement du PHP sans forcément devoir toucher à celui sous /modules qui est considéré comme l’original… bon y’a aussi d’autres problèmes liés… mais bon je vois ça comme ça.

Bilan
Non je suis pas une « merde » ni un « gros porc » de faire de telles manipulations et de limiter le nombre de fichiers en bourrant tout dans modules…. Si je le fais c’est que j’ai trouvé que c’était moins contraignant et que c’était plus agréable pour travailler… Je sais que Prestashop a dû faire des efforts pour améliorer l’override du thème… mais tel qu’il est actuellement… ça me plaît moyen… du coup ben je me facilite la vie quitte à faire l’opposé des « pro-fans » de « on sépare tout dans 1000 dossiers différents ». Et voilà… si toi aussi t’es un fou et que tu fais ça, bienvenue dans le clan Fusion-man !

Notez mon billet, Google va adorer :
1 étoiles - J'aime pas !2 étoiles - Bof !3 étoiles - Bien !4 étoiles - Très bien !5 étoiles - Génial ! (2 votes, moyenne : 3,00 sur 5)
Loading...

27 commentaires sur “Prestashop l’override des thèmes trop complexe”

    1. Exact, mais c’est un cas courant… pas un cas isolé.
      Du coup il faudrait corriger le problème dans le module pour pouvoir « override » correctement.
      Le temps à passer peut-être vite conséquent… c’est pas vraiment prévu dans le budget du client et lui souvent il s’en « cogne »… d’override ou pas, pourvu que ça soit vite, bien et pas cher.

  1. Merci de ces précieux conseils, tu m’étonnes que ça devient vite le bord***…

    Je pense que je vais faire de la même façon dorénavant.

    Question bonus : Quelle version de Presta tu conseillerais aujourd’hui pour la création d’une boutique ? (stabilité, update futur, compatibilité module, fonctionnalités FO et BO).

    Je te remercie pour tout ces billets qui sont toujours bien sympa à lire 😉 Bonne continuation

    1. Merci pour ton commentaire et tes éloges 😉

      Peut-être de la 1.5 parce qu’on trouve aussi de nouveaux thèmes assez bien fait en responsive… Après c’est vraiment discutable au niveau des modules, on voit quand même pas mal de rustines sur 1.5… Même moi j’en ai fait (des rustines)… je voulais pas tout perdre du coup j’ai certains modules qui sont « moyens » compatibles… on le voit aussi dans les interfaces c’est moins « propre »…. car ces modules proviennent de la 1.4.

      L’avenir c’est la version 1.5 ça c’est clair… mais si un client qui fait du e-commerce possède Prestashop, c’est déjà à mon sens un grand pas en avant peut-importe sa version.

  2. Bonjour,

    Tout à fait d’accord, l’arborescence des modules comme « blockwishlist » ou « referalprogram » pour ne citer qu’eux, est tellement complexe que je préfère faire un module alternatif qui sera exporter en module additionnel lors de l’export du thème. C’est particulièrement pénible lorsque l’on veut personnaliser les icônes.

    Merci pour ce blog toujours pertinent.

    Andre

    1. Hello ! Je comprends tout à fait…
      Il faut bien se dire aussi que le but n’est pas de se vanter parce qu’on a le code / arborescence, le plus « structuré » possible… ça on s’en fou…
      Mais surtout de passer le temps prévu sur le module pour rester dans le budget du client… sinon on n’en fini pas et on peut pas réclamer le double ou le triple au client.

  3. Bin non pas d’accord mais pas du tout.

    Un thème a un espace à lui /themes/letheme/ et tout ce qui le concerne doit ce trouver dans cet espace.

    Le système actuel de surcharge des tpl/css/js est clair comme tu l’as dit :
    les tpl dans /modules/lemodule/, les css dans css/modules/lemodule/, les js dans js/modules/lemodule/

    On peut aussi faire à la barbare et modifier le module lui même mais :
    – c’est crade : tu codes dans un système défini avec des règles, tu dois donc les respecter. Elles ont des raisons d’être et ça assure la pérennité et la compréhension par le client ou les futurs intervenants de ce que tu as fais.
    – on perd le support possible sur le module. En tout cas moi si on me dit : j’ai modifié votre module, il ne marche pas aidez moi ou remboursez moi. Ma réponse est évidente.
    – en cas de mise à jour on perd tout (il y a des mises à jour de module automatique)
    – en cas de changement de thème ou de multi-boutique on sait plus où on en est.
    – comme dit plus haut tu n’es ou ne sera pas le seul intervenant sur le projet. Même si c’est ta boutique perso, tu ne seras peut être pas tout seul dans le futur.
    – pis bon « ouin ouin y a trop de répertoires ça me fatigue » ça fait pas très pro. s’il y a des répertoires il y a surement une logique derrière sinon on met tous les fichiers d’un thème (tpl, js, css, img) dans /themes/montheme/ et tout le monde pleure.

    l’idée de copier le module dans le thème pour le modifier non plus n’est pas bonne. Un thème est un thème, il ne doit pas modifier le comportement d’une boutique, il ne doit pas avoir de code exécutable, pas de PHP.
    C’est une question de logique et de propreté, autant que {php}{/php} en smarty doit être banni.

    Pour l’instant il manque la possibilité de surcharger le PHP des modules (dans /overrides/modules/ par exemple) mais
    faut faire avec. Si vraiment tu dois modifier le comportement d’un module pour ton thème (faudra m’expliquer pourquoi) tu le duplique ou tu fais un module qui le surcharge.

    En général j’aime bien ce que tu écris mais promouvoir une mauvaise pratique parce que c’est plus simple sur le moment beurk.

    1. Hello,

      Merci d’être venu donner ton avis 😉

      Tu as tout à fait raison il est important de respecter cette nomenclature, même si je trouve que dans le répertoire du thème il ne devrait pas y avoir besoin de créer 2 ou 3 fois l’arborescence pour 1 module… (CSS et JS… + TPL) ça triple les dossiers inutilement. Pourquoi ne pas faire simplement un seul répertoire « modules » et de conserver la même structure que le module « original »… ça permettrait aussi d’override le fichier « .php ». A mon sens je préférerais avoir un répertoire module dans le thème où l’on clone le module original (sans le dispatcher en morceaux).

      Mais par exemple quand je découvre actuellement des modules qui ne fonctionnent pas avec l’override… que faudrait-il faire ? Résoudre le problème ? Cela demande passablement du temps… et il faut trouver « comment » corriger. Imaginons même qu’on ne puisse corriger le problème… on se retrouve finalement avec 1 ou 2 modules qui ne sont pas présents dans le répertoire thèmes… mais dont les TPL ont été modifiés… est-ce que c’est plus clean ? Pas vraiment à mon sens….

      Modifier le comportement d’un module pour un thème est une chose qui peut arriver fréquemment… ex le client veut que bloc d’inscription à la newsletter sauve la langue du client… Obligé d’apporter une modification dans le coeur du module… c’est pas grave mais c’est pas super-clean non plus (si on veut chipoter)…

      Tu as entièrement raison en ce qui concerne le côté structurel, on ne mélange pas les vues, les modèles et les controlleurs… chacun à son rôle. Le problème c’est qu’actuellement l’override des modules Prestashop n’est pas encore complet (on peut gérer uniquement les vues TPL / CSS / JS…). Le fait aussi que l’override ne soit pas toujours bien pris en charge est aussi pénalisant… car il y’a trop de modules qui ne font encore pas l’effort de bien gérer ce comportement…

      Ahah « Ouin Ouin »… y’a trop de répertoires 😀
      Clairement qu’il y’a une logique derrière et qu’il faut la respecter, mais pour le moment c’est encore trop brouillon… si je prends le même cas avec la création d’applications sous CakePHP par exemple, l’aspect « override » des plugins est plus propre.

      Lorsque l’override des modules sera plus complet et mieux géré par tous ces modules en vente ci et là… certainement que je ferais l’effort de l’utiliser correctement. Pour le moment y’a encore un peu de chemin à faire, mais ça viendra je pense par la suite et par la force des choses… Je pense que ces problèmes sont aussi liés à la grande permissivité de Prestashop au niveau du développement des modules… qui n’impliquent pas forcément un cadre de travail assez stricte.

      Voilà tu as un peu mon opinion aussi 😉

      A bientôt !

      1. Salut,

        C’était plutôt pour remettre les choses en place. Que tu fasses comme ça ok, tu gères ça avec tes clients, que tu dises que c’est mieux de faire comme ça non.

        Si tu veux que le module d’inscription à la newsletter gère les langues, ce n’est pas le module de base qu’il te faut. Encore une fois à la prochaine mise à jour (par le client, un autre prestataire, dans un mois ou dans trois ans) tout ton boulot sera perdu et personne ne saura pourquoi.
        La bonne méthode est de cloner puis modifier le module de base ou de le refaire. Ça prend 15 minutes de plus certes.

        Le cas des modules ne gérant pas l’override est spécial, là tu n’as pas le choix (perso j’en ai pas encore vu). Par contre si tu l’as acheté, tu peux clairement demander un remboursement. Le module est pourri et ne respecte pas les normes de codage de Prestashop. Pour le côté brouillon oui c’est l’anarchie pourtant Prestashop est précis sur l’organisation d’un module : http://doc.prestashop.com/display/PS15/Creating+a+PrestaShop+module#CreatingaPrestaShopmodule-Organizingyourmodule

        Pour les trois répertoires par modules on peut voir aussi dans l’autre sens. Je viens faire une intervention sur un thème, je sais que tous les js sont dans /js/, les css dans /css/ et pas éparpillés dans /modules/*/. Si je cherche un css en particulier grep -r ‘maclass’ ./css/ et je suis pas pollué par ‘maclass’ dans les js ou les tpl.
        D’après moi c’était la logique de ceux qui on développé ce système.

        Ce qui m’a fait réagir c’est plutôt la réponse de Florian : « Tu as raison, je vais faire pareil. » Non ce n’est pas un exemple à suivre. Je comprend qu’on ait envie de faire ça, je comprend qu’on le fasse quand pas le temps/le budget/l’envie mais c’est pas bien, c’est du bâclage. On ne devrait pas faire comme ça et il faut en avoir conscience. Après on gère son karma comme on veut.

        C’est mon opinion évidemment chacun fait ce qu’il veux.
        Au plaisir de te lire.

        1. Hello,

          C’est surtout aussi pour expliquer mon fonctionnement, pour que d’autres se disent aussi… ah bon.. je me demandais comment font les autres, parce que moi aussi j’ai trouvé pas pratique.

          Certaines choses me font penser aussi à des débats que j’ai déjà eu sur d’autres systèmes PHP… d’un côté des les pro-fan du code et de la structure… et ensuite les autres. Dans mon cas, je dois gérer le projet au mieux et faire en sorte qu’il soit le plus facile et clair à manager… car ma tâche n’est pas uniquement développer, mais bien sûr de fournir un shop au client et que je puisse tenir dans les délais et le budget.

          Parfois il faudrait faire autrement, mais viser la structure idéale est parfois une perte de temps, suivant la méthode de fonctionnement… C’est un peu comme les mises à jour Prestashop, c’est actuellement quelque chose que je ne cautionne vraiment pas du tout… Voilà aussi un exemple de fonctionnement différent de ma part… car dans mon optique, les clients ne font pas de mises à jour, mais des refontes.

          Et à nouveau l’aspect « pratique » revient aussi en jeu… quand un override ne fonctionne pas pour un module… Si le module fait ce que j’ai besoin, je vais pas demander plus… dans mon sens pourvu que j’arrive à le mettre en place et que ça tourne. Sinon quoi demander un remboursement… je me retrouve ensuite les mains vides… sans forcément un module équivalent.

          Mais je pense que les mode de fonctionnement entre les prestataire sont très différents et cela dépend aussi à quel niveau on se trouve, pour que la préoccupation prioritaire change (si on est développeur dans la boîte etc…) . Je comprends ta logique et effectivement, dans un idéal il faut suivre le « dispatch » proposé par la solution e-commerce. Seulement entre la pratique, la réalité et la méthode de fonctionnement de chacun… il peut y avoir des grandes différences.

          Mon but n’est pas d’inciter les gens à ne « pas suivre les conventions », mais à leur montrer mon ressenti et ce que je trouve plus pratique.

          Voilà, voilà…

        2. Finalement après lecture de ces avis, je ne sais pas trop comment m’y prendre…

          N’étant pas un professionnel, j’ai créer quelques boutiques pour moi et mon entourage et je partais sur la solution de l’override « propre »… Je vais peut être continuer comme ça pour le moment tant qu’il n’y a pas de solution plus simple.

          Mais il y a du vrai et du moins vrai dans vos deux discours, merci d’avoir autant argumenter. Cela permet aux néophytes de se rendre compte qu’il y a un vrai boulot et que le temps est nécessaire pour un développement de qualité.

          Bonne continuation !

  4. Salut,

    à la fin on récupère des projets pourris par ce genre de pratique.
    Perso je ne me considère pas comme développeur ou webdesigner mais étrangement j’arrive à coder ou intégrer plus proprement que certains pseudo professionnels (c’est pas moi qui le dit).

    Je suis bien conscient que respecter ces pratiques est assez contraignant mais à perdre un peut de temps en fait gagner énormément par la suite. Lorsque je travail sur un dev de broceliande ou de samdha je ne passe pas 5 heures à comprendre le programme car sont codage respecte les bonnes pratiques et donc reste accessible même sans commentaires.

    Si les clients étaient déjà conscient que comme professionnel lorsque nous affirmons quelque chose c’est que cela doit pas être totalement faux nous ferais gagner 40% de temps en plus pour travailler 😉

    1. Salut,

      Ah ah… pour les clients, clairement qu’on gagnerait du temps s’ils faisaient un peu plus confiance (ouf ils ne sont pas tous comme ça).

      Il faut dire aussi que de mon côté je gère des « petits / moyens » clients, le temps à passer est compté, il faut faire vite et que ça soit « pratique et fonctionnel ».

      Sur des projets qui sont amenés à durer et à évoluer vraiment chaque année… je pense que c’est aussi différent (ça vaut la peine de prendre le temps de démêler la chose), mais le client doit offrir aussi un budget confortable pour qu’on puisse faire les choses bien.

      Bon il faut dire aussi que pour finir j’essaie aussi de choisir des modules de développeurs que je connais… parce que je sais qu’ils respectent bien cette logique du dispatch.

      En ce qui concerne la récupération de projets pourris… je pense qu’il y’a une multitude de phénomènes de « pourritude »… j’ai déjà vu ça. D’ailleurs à présent c’est rare que je reprenne un client qui change de prestataire et qui a déjà une boutique… c’est quasiment dans le 99% des cas un nid à problèmes.

  5. Bonjour, bien que sa soit un vieux ticket, je me permets de faire un post.
    j’ai du mal à comprendre ce qu’il y a de difficile ou contraignant à respecter les bonnes pratiques lorsqu’on travail sur une plate forme.
    Moi personnellement je ne pense pas que sa soit compliquer.
    Si nous nous mettons à modifier les tpl des modules natifs directement dans les répertoires respectifs, comment allons nous gérer le multi boutiques si les thèmes sont différents?

    – On parle de gain de temps sur les projets clients mais je ne sais pas si nous avons besoins de 1minute pour faire l’override du tpl d’un module dans le répertoire du thème utilisé!
    En plus il faut toujours commencer par override le css et actualiser. si sa ne marche pas alors pas la peine de continuer.

    Sauf erreur de ma part, j’ai pas encore eu de souci avec un module natif au niveau de l’override 8)

    1. Bonjour,

      Les modules Prestashop natifs respectent la convention d’override, les autres modules achetés via Prestashop Addons… sont bien plus hasardeux.

      Dans les modules natifs, on peut signaler qu’ils ne sont pas tous conventionnés de la même manière… certes ça fonctionne, mais on est encore loin d’une norme stricte pour les modules : https://www.webbax.ch/2013/07/17/prestashop-1-5-et-les-nouvelles-conventions/

      Pour le multi-boutiques, sur le principe cela fonctionne bien… c’est quand on commence à tout activer, pour arriver à des cas complexes + gestion du stock avancé… qu’il arrive des surprises.

      La version 1.5 se peaufine peu à peu… il faut lui laisser le temps.

  6. Oui je suis tout à fait d’accord avec toi qu’il faut laisser le temps à la 1.5 de murir bien que prestashop annonce la 1.6 pour la fin d’année.

    – Il serait peut être préférable que prestashop intègre l’override du css, js et tpl dans les tests de validations des modules sur l’addons.

    – Pour moi c’est inacceptable de ne pas essayer l’override avant de travailler directement sur le tpl de base.

    c’est vrai chacun ces pratiques. c’est difficile au début mais sa coule par la suite!

    1. Si tous les modules de Prestashop Addons géraient correctement l’override des TPL cela serait bien plus simple…

      Utiliser un override partiel du thème, parce que certains modules ne le prennent pas en charge… c’est pire pour le suivi du projet… car certains TPL doivent être modifiés sur le module source et d’autres non.

      Trouver pourquoi le TPL n’est pas pris en charge dans un module X ou Y… oui on peut chercher, mais passer des heures là dessus, n’est pas vraiment viable.

      Merci pour ton retour d’expérience !

  7. Bonjour,

    J’essaie moi aussi de comprendre l’architecture de Prestashop pour réaliser mon propre thème.

    J’ai retenu au fil de mes lectures qu’il était recommandé pour créer un thème d’overrider tous les modules dont on veut modifier l’apparence et qui ne sont pas gérés par le fichier global.css

    Ce que j’ai d’abord entrepris de faire pour le module blocktopmenu (module fourni avec le thème par défaut).

    J’ai essayé de suivre la logique qui est recommandée et j’ai donc créé un dossier modules dans le dossier css de mon thème. A l’intérieur de mon dossier modules, j’y ai mis mon fichier css : superfish-modified.css et j’ai actualisé ma page (F5). Résultat ? Rien.

    Alors j’ai cherché, j’ai lu différents fils de discussion sans véritablement trouver la réponse et j’ai essayé différentes arborescence pour trouver celle qui fonctionne. Donc pour  » overrider  » le fichier superfish-modified.css il faut le placer dans l’arborescence suivante :

    prestashop > themes > montheme > css > modules > blocktopmenu > css > superfish-modified.css

    Et là ça marche (en tous cas pour moi). Maintenant, je ne sais pas si c’est conforme et si c’est pérenne, mais ça marche.

    Toutefois, comme je commence seulement à me plonger dans la création de mon thème, si vous voyez dans cette approche quelque chose qui cloche, dites le moi. Je cherche à mettre en oeuvre les meilleures pratiques pour mon site.

    Merci pour vos articles et vos conseils.

    1. Bonjour,

      Merci pour votre visite et vos explications, je me permets de vous confirmer que c’est tout à fait correct… il faut bien mettre à cet emplacement le fichier CSS à overrider.

      Ne pas oublier de désactiver tous les caches + forcer la compilation… histoire d’éviter les mauvaises surprises.

      A noter aussi que parfois l’override est correctement structuré… et ça ne marche pas quand même, du coup la conclusion est qu’il y’a un problème dans la conception du module.

      A bientôt !

  8. J’adore tes articles avec tes avis très tranchés.

    Néanmoins de mon coté je préfère suivre les conventions. Ce qui m’énerve par dessus tout comme tu la évoqué est qu’on ne puisse pas surcharger le php des modules.

    Néanmoins depuis quelques semaines je suis tomber sur cert article : http://www.webaki.com/blog/override-module-8.html qui propose une méthode très astucieuse de faire cette surcharge. Si comme moi vous êtes intéressé par cela, je vous invite vivement à lire cet article. Perso je m’en sert désormais dans mes devs.

    Il y propose une méthode pour réécrire la classe parente dans le cache en changeant la portée des membres. Bon ca a aussi ces limites car ca ne marche que sur des classes

    1. Intéressant ce lien sur l’override des modules pour le fichier PHP… mais idéalement je pense que ça serait bien que Prestashop le gère nativement.

      Je pense aussi qu’il faudrait sur le plan pratique, à ne pas avoir à se poser trop de questions et pouvoir copier bêtement le module à overrider, sans devoir modifier ou étendre le code du module.

      Sinon cool je trouve que c’est une bonne idée…

  9. Franchement d’accord. Pour ma part, c’est assez simple. je suis payé par le client pour faire un site, pas par presta pour debugger leur merde. A force de me prendre la tete avec leur logique et l’abscence de doc coherent, j’ai entrepris de coder ma boutique tout seul.

    Miracle, en trois mois ca tournait du feu de dieu, et mieux encore, je pouvais changer ce que je voulais sans me prendre la tete avec les caprice de presta.

    Mon conseil : virer ce systeme en carton !

    1. Hello,

      Ahah… carrément un avis radical…

      Les thèmes Prestashop ont encore évolués depuis cet article, maintenant avec la notion responsive d’autres problèmes surviennent et pour avoir un thème avec un CSS clean et concis c’est plutôt rare.

      Certains gros éditeurs de thèmes Prestashop intègrent la notion de « Widget » dans Prestashop, ce qui complexifie encore plus l’intégration et la customisation rapide du thème.

      A refaire un pointage dans une année pour voir comment les choses auront évoluées.

      Merci pour ta visite !

  10. Bonjour,
    Je suis sous prestashop 1.6 et je me lance dans la conception de modules.
    Je voudrais savoir comment faire pour overrider un module déjà overridé lors de l’installation de mon module ?

    Je prends l’exemple du module blockcart qui est déjà overridé en 1.6

    je souhaite modifier la fonction add du fichier ajax-cart.js de ce module (sans avoir à le faire en dur) afin que lorsque mon module s’installe le fichier ajax-cart.js soit modifié et lorsque mon module ce désinstalle mon fichier ajax-cart.js conserve le comportement par défaut

    Merci

    1. Bonjour,

      Si vous désirez faire un module qui modifie le fichier « ajax-cart.js » dans le répertoire du thème courant, il faudrait en premier lieu que le module fasse un backup du fichier original.

      Ensuite, deux possibilités… soit le module « remplace » le fichier existant par un nouveau fichier incluant déjà les modifications (mais il y’a un risque de conflits selon le thème utilisé)…

      Ou alors il faut faire une fonction qui va faire un remplacement via un « fwrite » PHP directement dans la méthode du fichier javascript.

      Tout dépend de ce qu’on veut faire, il faut expérimenter.

Laisser un commentaire

Votre adresse de messagerie ne sera pas publiée. Les champs obligatoires sont indiqués avec *