Et les modifications perso ?

Les points évoqués ci-après relèvent autant de la personnalisation pour sauvegarde, dans le cas de mise-à-jour du site et de son CMS ou dans le cas d’un déplacement de site [1].

Et la réponse apportée par l’architecture de SPIP permet d’ignorer totalement ces problèmes, grâce aux concepts de bonne utilisation pour le "path" de SPIP, facilitant la surcharge des squelettes !

 Rappels sur la personnalisation

Personnaliser un site Web, c’est modifier l’apparence ou l’habillage graphique : cela s’obtient donc en modifiant les fichiers source du CMS, qu’il s’agisse des feuilles de styles CSS ou des Squelettes ou gabarit de template, du cœur-même du logiciel (le core) ou encore des nombreux modules complémentaire plugin) que votre webmestre aura ajoutés pour répondre mieux aux fonctionnalités voulues...
Bien évidemment, vous n’avez aucune documentation de ces diverses modifications et ajouts opérés, pas même la liste et source des plugins ou thèmes chargés, et sans doute re-modifiés : il "suffit d’aller voir dans le code" est la réponse courante, à charge de savoir manipuler l’interface du back-office du CMS [2]...

 Les fichiers de configuration

Chaque CMS utilise -au moins- un fichier de configuration, souvent situé à la racine du site, ou bien dans un dossier mieux protégé : normalement, le veritable fichier opérationnel n’est pas compris dans le source, et ne risque donc pas d’être écrasé ; néanmoins, il faudra vérifier les modifications opérées, par exemple pour des nouvelles définitions de constantes [3] une phrase de codage spécifique de sécurité, à reporter pour permettre la connexion privée]]..

 Paramétrages en base

En principe, la plupart des paramétrages spécifiques sont reportés en base de données : la sauvegarde SQL doit normalement suffire...
Cette sauvegarde n’évite pas quelques pièges classiques, ou plus surprenants :
 l’URL de base du site est très souvent enregistrée en base de données [4], parfois en plusieurs champs et tables, ce qui oblige à autant de manipulations de correction...
 de nombreux systèmes enregistrent le préfixe de jeux de tables dans un table (voire meme plusieurs) en base, rendant le transport entre jeux de tables "difficile" !
 d’autres informations fichiers peuvent être mémorisées, comme :
les emplacements des fichiers joints (si placés en un emplacement non-standard)
les noms de fichiers générés lors de leur téléchargement comme valeurs de paramétrages (souvent le cas des images et iconographie des thèmes) [5]
les sources et versions de certains plugins ou modules (en particulier, il faut garder la trace -et preuve/facture d’achat- des modules achetés), en espérant qu’ils seront mis-à-jour par leur éditeur au même rythme que le CMS core.
Plus vicieux, j’ai rencontré des modules nécessitant de réactiver (donc recharger -après avoir retrouvé le fichier image d’origine !) les illustrations, mémorisées avec un nom hashé : le système n’affichait qu’un masque grisé : voir ci-après...

 Les modules ajoutés

Pratiquement tout CMS se distingue par la variété des modules, plugins, bibliothèques, addons, thèmes etc.. disponibles (à un moment donné, pour la version courante..) au point d’en faire un argumentaire de vente : il est vrai que ce foisonnement peut être un véritable aubaine -gain de temps- lors de la création du site ! Mais... qu’en est-il des mises-à-jour ?
Il faut déjà distinguer entre plugins "externes", qui se rajoutent au fonctionnement du CMS, ceux qui dépendent d’une version spécifique -en fonction de points d’accroche, API ou pipelines abandonnés depuis-, et ceux qui écrasent certains fichiers du core : cela dépend, d’une part de l’architecture de principe du CMS, et ensuite de la rigueur de développement : en SPIP, le plus souvent, on ne peut rencontrer que des problèmes de préfixes ou de support de SGBD, quand les développeurs ont oublié de passer exclusivement par l’api d’accès SQL. Pour de vieux plugins, il faudra parfois rajouter une bibliothèque de vieilles_defs.php...
Ensuite, il faut souvent réinstaller les plugins (pour recréer leurs tables supplémentaires : cas de SPIP si vous ne restaurez pas une sauvegarde SQL complète après avoir installé les plugins source), voir réactiver ceux-ci (car il semble que certains CMS ré-initialisent leur cache à partir du seul écran d’activation du plugin..).

En cas de mises-à-jour, les nouvelles versions ne reprennent pas toujours les mêmes paramétrages, dans les mêmes champs, avec les mêmes noms, les mêmes effets : cela ne fait que vous rajouter un peu de complexité, que vous risquez de découvrir bien après la migration : d’où l’intérêt de Transporter un site en local !
A noter que SPIP intègre facilement dans son mécanisme de plugins un système automatisant les montées de versions (permettant d’assurer facilement la programmation-conversion des éventuelles modifications de structure des champs accessoires), qui généralise aux plugins l’automatisme du core garantissant La structure de base de données de SPIP 3.

 Les personnalisations in-situ

Même un module additionnel choisi spécifiquement pour fournir une fonctionnalité demandée par l’utilisateur réclamera souvent quelques personnalisations, minimes comme un changement de couleur dans la CSS, l’augmentation d’un paramètre de taille pour afficher une plus grande photo, et bien sur le remplacement des fichiers d’iconographie ; vous pourriez rencontrer d’autres interventions plus conséquentes, pour rajouter des choix de menus non paramétrés d’origine, appeler un lien de page ou un libellé supplémentaire, voir appeler un bloc spécifique rajouté par programmation directe du Webmestre...
Toutes modifications effectuées bien sur "en place", dans les arborescences de fichiers spécifiques internes du CMS ou des plugins, le plus souvent écrasées naturellement à la mise-à-jour, sauf en SPIP [6] ! : il faut retrouver toutes ces modifications (comment ?), les rapporter aux versions d’origines (non conservées !), et les reporter (sans erreurs) dans les nouvelles versions (compatibles ?) tout juste téléchargées (si celles-ci existent sont accessibles librement sans frais supplémentaires !).
Et ne parlons pas de modifications fonctionnelles, ( présentations, logiques et boucles d’affichage-parcours et ou nouveaux formulaires), qui ont imposé de modifier les sources du CMS [7], avec une compatibilité aléatoire.

Bien sûr, ces complexités sont moins apparentes, et encore plus couteuses en temps si votre webmestre n’est pas expérimenté avec le CMS à déplacer.... mais c’est un point immédiatement visible sous SPIP, très localisé :
 la liste des ./squelettes-dist modifiés (surchargés) dans ./squelettes
 la liste des ./plugins ajoutés aux ./plugins-dist
et vérifier la ./config : juste la base de données, et éventuellement mes_fonctions et mes_options.... c’est tout !