Rechercher :
Accueil » Contributions Connexion

Question Comment suivre, réussir et éventuellement comprendre l'installation de multiples contributions?
Réponse ... surtout quand on ne parle pas couramment OsC.

1 - Choisir sa "propre version de base"

D'abord s'assurer que la date de mise à jour est la plus récente (les trous de sécurité les plus récemment découverts y sont comblés).

Ensuite, pour prendre l'exemple de la version française, elle n'est pas vraiment "de base" : des fichiers sont ajoutés, modifiés, utilisés et ne seront pas repris dans beaucoup de contributions développées à partir de la MS2 vraiment de base, c'est-à-dire anglo-saxonne.
Et les fichiers (et modifications) "french" homologues des "english" n'y seront pas présents.
Je ne parle pas des contributions partant de versions allemandes, espagnoles, on peut s'en sortir ... mais aussi néerlandaises, japonaises...
Je ne parle pas non plus des forks (OsC modifiés dont le suivi n'est pas assuré ici ) !

2 - Faire le point des contributions à installer avant toute installation

Un cahier des fonctionnalités attendues (des charges) est préférable avant l'installation pour limiter les additions/sauvegardes successives et laborieuses.
Les conseils sont de mettre le minimum de contributions, mais toutes les contributions indispensables.
Donc pas de meilleure contribution, seulement des contributions correspondant à de réels besoins.
Ne pas oublier les contributions légalement obligatoires selon les pays.

3 - Tester chaque contribution séparément

. La première question est "en local" ou pas "en local".
Il est des essais qui peuvent parfois fortement déplaire à l'hébergeur !
Il est donc préférable de tester en local, les outils sont indiqués dans le site.
En revanche, l'environnement en local et chez l'hébergeur sont le plus souvent différents;
ces différences et leur impact sur le fonctionnement ne sont pas toujours faciles à analyser.
Les surprises peuvent être bonnes ou mauvaises.
En conséquence, il n'est pas nuisible de tester chez l'hébergeur les contributions qu'on a souhaité tester d'abord en local.

. De plus, il faut bien lire les fichiers d'installation dans leur ensemble.
(pour les esprits brouillons, une impression du fichier et un suivi point par point en cochant s'impose)

. Généralement, il faut s'attendre à une ou plusieurs de ces phases :
- modification manuelle de fichiers (s'assurer que les modifications sont "commentées", soit avec le nom de la contribution "contribution debut" /.../ "contribution fin", soit avec "ma modif a moi debut" /.../ "ma modif a moi fin", soit avec les deux).
Les recherches des fichiers ET à l'intérieur des fichiers en seront ensuite facilitées.
- remplacement de fichiers
par sécurité et pour un retour en arrière facilité, garder les anciens fichiers en les renommant fichier.php devient fichier_OLD.php par exemple
commentons, commentons ...
- addition de nouveaux fichiers
commentons, commentons ...
- intervention SQL :
quand elles ne sont pas automatisées avec l'installation, il est demandé d'ouvrir l'outil de gestion (des tables, ...) de la base de données, à savoir PHPMyAdmin le plus souvent, et d'y "injecter" un fichier d'instructions SQL à l'endroit propice.
Ces instructions SQL vont soit modifier les tables existantes dans leur struture et/ou leur contenu, soit ajouter de nouvelles tables.

. la seconde question est "test de la contribution isolée"ou non :
un test sur une MS2 d'origine permet de voir déjà si elle fonctionne : elle peut avoir eu un développement un peu ancien qui ne supporte pas l'évolution d'OsC.

4 - Etablir la séquence des contributions à installer

Un exemple :
installer Multi-Stores multiple shop system en upgrade : l'auteur déclare "for the clinically insane AND heavily pre-modded store".
En l'occurrence, après avoir établi sa liste avec contrib1, contrib2 et Multi-Stores multiple shop system, il vaudra mieux installer d'abord Multi-Stores multiple shop system, puis contrib1, contrib2.

5 - Etablir un tableau croisé Contributions / Fichiers modifiés-ajoutés

Un tableur suffit.
Un tableau croisé permettra aisément de déterminer les fichiers communément modifiés, mais aussi de vous y retrouver quand voous aurez tout oublié.
Considérer aussi la création des nouvelles tables;
par exemple, l'exploitation de EasyPopulate y sera sensible.

6 - Comparer les modifications dans les fichiers communs à plusieurs contributions

Il faut rentrer dans le code, et c'est là où la compréhension devra commencer à se mettre en marche.
Dans un premier temps, si les mêmes lignes sont modifiées par deux contributions et que vous n'en percevez pas les conséquences, il est temps de poster;
vous limiterez ainsi les lignes de code postées et augmenterez vos chances de réponses à vos interrogations.

7 - Faire les modifications nécessaires et tester ...

... successivement après l'installation de chaque contribution ... sans en oublier !

8 - Tester et encore tester

Faire tester tout ... ou presque (attention aux modules de paiement et autres qui impliquent des dépenses) par des tierces personnes.
Auteur : corbin Mise à jour le 25/04/2007

Retour