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).
[bonnes pratiques] hacks et upgrade : clonage de modules ?
-
- Rang : Apprenti
- Inscrit le : 22.03.06
- Dernière visite : 24.12.08
- Messages : 210
-
- Rang : Grand Maître
- Inscrit le : 03.07.05
- Dernière visite : 28.12.08
- Messages : 2278
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 ><>° -
- Rang : Franc-Maçon
- Inscrit le : 12.10.05
- Dernière visite : 06.12.08
- Messages : 735
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) -
- Rang : Apprenti
- Inscrit le : 08.10.05
- Dernière visite : 24.12.08
- Messages : 258
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 -
- Rang : Récupérable
- Inscrit le : 28.09.05
- Dernière visite : 04.10.08
- Messages : 134
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
- Modéré par :
- Admins
Utilisateurs en ligne
- 4 visiteurs
Données pour les 20 dernières minutes
