[bonnes pratiques] hacks et upgrade : clonage de modules ?  Début

  • Mon prochain site sera pn8 (j'ai installé la RC4 en local pour y travailler en attendant la version finale).

    pn8 est bien évidemment très intéressant pour la gestion des personnalisations : de présentation (thème/xxxx/templates/modules/...) et de traduction. Le fait que les personnalisations ne sont pas "dans" les modules (mais dans le thème) permet de penser aux upgrades du noyau et des addons "relativement sereinement". (retour d'expérience : j'ai suffisamment hacké les sources de surlesplanches.com 0.764 pour que cela freine vivement mon envie d'upgrader en pn8).

    Toutefois, certains modules nécessitent parfois des adaptations DANS LE CODE lui-même. 3 exemples :

    > modules/Quotes : n'est pas multilingue. Je souhaite l'adapter (fait en RC2 mais le Quotes RC4 a changé, du côté des catégories.)
    > modules/FAQ : n'est pas multilingue. Je souhaite l'adapter.
    > system/legal : je souhaite ajouter 2 sections (A propos, propriétés intellectuelles) aux 3 sections existantes (terms of use, privacy, accessibility).

    Je souhaiterais connaître votre point de vue sur la meilleure manière de procéder, les "bonnes pratiques du hack" (sans perdre les adaptations à l'upgrade suivant) !

    Je pensais "clonés" les modules concernés (parce que j'imagine mal de "faire dans la dentelle" avec un repérage "manuel" des fichiers modifiés ... parce qu'on en oublie toujours un). Est-ce la manière que vous employez ?

    J'ai essayé de cloner, de la manière suivante ... :

    > désactivation / retrait du module
    > renommage du dossier (ex : "modules/Quotes" en "modules/myQuotes")
    > remplacement (en respectant la casse) de "quotes", "Quotes", "QUOTES" par "myquotes", "MyQuotes", "MYQUOTES" dans tous les fichiers du module
    > renommage des fichiers "pntemplates/quotes*.htm" en "pntemplates/myquotes*.htm"
    > régénération de la liste de module
    > installation / activation

    (pour "system/legal", je fais une copie ... vers "modules/mylegal")

    A première vue cela semble marcher, mais je ne suis sûr de rien ...

    Que pensez-vous de cette méthode de clonage de module ?

    Laurent

    PS : j'avais adapté Quotes pour une prise en charge multilingue dans la RC2. Je l'avais envoyé à Gilles et Yokav (je crois), mais la RC4 n'intègre pas mon hack (ce que je peux comprendre, il y a probablement plus sérieux à traiter) ... d'où le sujet : comment on fait pour ne pas perdre ses hacks lors d'une montée de version ?

    PS2 : je ne sais pas si j'ai posté au bon endroit (là ou documentation).
  • Bonjour Laurent,

    ta façon de faire est très bonne de tout renommer, mais c'est vrai que tu vas perdre les montées de version, le mieux, afin de ne rien perdre lors d'une nouvelle version est d'utiliser un programme gérant les différences entre dossiers/fichiers etc... afin de repérer les différences et de les répercuter. Je pense que c'est la seule solution, malheureusement !



    Gilles  ><>°

  • pour gérer çà je partirai plutôt sur une migration 0.8

    -un dossier ressource avec les archives des modules utilisés
    -un dossier projet avec la dernière version de ton projet
    -éventuellement un dossier version , avec les projets que tu as mis en prod

    pour calculer la différence de deux modules, utiliser winmerge, (il est peut être même possible de générer des rapports )

    notes que dans ton cas, si tu veux vraiment rester sur ta version, tu as peu être plus intérêt à porter le système de template overriding à pn0.764

    à voir







    modifié par : mumuri, 02 Jn 2008 - 22:08



    Membre du PSR Project (Pagesetter replacement)
  • sous nux quelques programmes pour la gestion des différences:
    meld et kompare (en interface graphique qui doivent aussi pouvoir s'interfacer avec un svn)
    ou encore diff pour les adeptes de la ligne de commande.




    Mon espace d'expressions libres

    Un site de guide haute montagne sous zikula
  • mumuri


    pour gérer çà je partirai plutôt sur une migration 0.8

    -un dossier ressource avec les archives des modules utilisés
    -un dossier projet avec la dernière version de ton projet
    -éventuellement un dossier version , avec les projets que tu as mis en prod


    Je fonctionne comme cela, avec un dossier par version,
    cela se complique dans il y a changement de structure sur la DB ...
    Sur du dev local en solo, un index de version sur le nom de la base me suffit.
    Mais je n'ai pas trouvé de solution "propre" pour bosser à plusieurs ...
    Bon, il y normalement indépendance fonctionnelle des tables, mais cela me fait flipper ...
    Si vous avez des idées ...




    Laurent Dubois - Consultant commercial
    Réseaux : Ziki Viadeo Xing Linkedin
  • 4 visiteurs

Données pour les 20 dernières minutes