Une migration sous SPIP - 1/ analyse

On supposera tout de même que votre site est dynamique, et qu’il se structure autour d’une arborescence d’objets éditoriaux, qui pourraient se transformer en rubriques et articles (comme les catégories et posts de WP : voir l’analyse et le travail de WordPress à SPIP).

 Les pré-requis

Le site à reprendre est déjà hébergé dans un environnement AMP (Apache MySQL Php).
C’est le seul pré-requis : il faut avoir accès aux données en tables.... S’il s’agit de pages statiques, vous pouvez parfaitement insérer les liens à ces pages comme articles virtuels [1] et continuer l’écriture de nouveaux articles sous SPIP.

Vous récupérerez donc, les codes de connexion FTP (ou bien vous vous ferez copier spip_loader.php en place pour travailler / mais attention à garder une copie de l’index.php du site d’origine !).
Et vous vous ferez fournir les codes d’accès à la base MySQL [2], nécessaires pour l’installation de la connexion de SPIP à la base de données. Au cas (extrêmement improbable, mais) où une table déjà existante porterait un nom commençant déjà par spip_ [3], vous penserez à définir un prefixspécifique pour votre SPIP !

 En préparation

Il faut donc installer un SPIP à-côté (sans la même base de données et sur le même hébergement [4] dans le mème dossier (racine de l’hébergement), en prenant seulement garde à ne pas écraser le fichier index.php d’origine qui existe très probablement sur le site actuel.

Pour faciliter votre travail, vous pouvez aussi vous installer deux plugins techniques, Adminer pour pouvoir plus facilement visualiser le contenu et la structure des tables d’origine, et SkelEditor pour pouvoir créer ou modifier des squelettes de travail en conversion directement dans votre gestion.
Dans notre cas particulier, tout le travail de préparation décrit ci-après a été mené depuis une copie de la base de données d’origine, ré-installée sur un serveur local !

 Un peu d’analyse

La première étape est d’identifier les tables de contenu à migrer [5], et sera facilitée si vous disposez de connaissances sur le fonctionnement de l’edition actuelle du contenu du site...

Voici par exemple les données initiales [6], trouvées dans notre cas.

Les tables de contenu à migrer...

Grace aux possibilités multi-tables de SPIP il est facile de visualiser l’ensemble des données d’une, ou des 4 tables à gérer : voici un premier squelette (simpliste et simplissime).

Pour comprendre ce squelette, il suffit de remarquer que la boucle BOUCLE_acces_restreint(acces_restreint) [7]reprend sur une ligne les noms des champs, mis en majuscules avec un # dièse devant, pour que SPIP sache afficher le contenu de cette table.

migreer cms acc

L’affichage de la table Accès_Restreint [8]ne montrera que deux utilisateurs, avec mot de passe en clair [9] ; le système de gestion des auteurs de SPIP permettra plus de souplesse...

 La gestion des rubriques

Aucun problème pour identifier l’objet éditorial concerné (voir plus haut), car il porte (presque) le mème nom que dans SPIP.
Par contre la liste des rubriques, et la structure d’un enregistrement de rubrique, va révéler quelques subtilités, qui nous permettront de mettre en évidence certains facilités de SPIP : d’abord on s’intéresse à la structure arborescente de ce plan de rubriques. Cette structure est recomposée par le lien implicite entre idRubrique et idRubriqueHaut, comme en SPIP chaque enregistrement de clé idrubrique contient bien un rappel vers l’idparent, clé de la rubrique parente [10].
Comme SPIP, on s’attend à disposer de la rubrique parente déjà créée quand on vient inséerer une nouvelle rubrique en-dessous ; mais l’affichage en liste montre que cette hiérarchie des idrubrique croissants n’est pas respectée... On devra donc créer les rubriques en triant le processus sur le idrubriqueHaut croissant, comme spécifié ci-dessus par les critères de cette boucle...
Autre chose, un champ spécifique de position donne l’ordre d’affichage des rubriques de meme niveau dans l’un des deux menus : cette facilité sera traduite en SPIP en reportant ces numéros en début du #TITRE de chaque rubrique, sous le strict format du numéro (sans espaces devant), suivi d’un point et d’un blanc avant le libellé littéral.

 Pour créer des rubriques SPIP

Le morceau de squelette ci-dessous nous permet donc d’afficher l’ensemble des rubriques, dans un ordre logique de création, et nous avons meme vérifié en rajoutant des critères {fusion ...} qu’il n’y avait pas d’usage de codes spécifiques dans #VISIBILITE ou dans #MONLIEN :

Il ne restera plus qu’a rajouter le code php de création, ce que nous verrons dans un article suivant : Une migration sous SPIP - 2/ en privé.

 Un peu d’organisation

Mais avant d’aller plus loin, organisons quelque peu nos pages de travail : on va créer une page de menus spécifiques pour accéder à nos pages de travail : un simple fichier nommé inserer_base.html sans grand formatage [11], où nous rajouterons des liens vers nos pages de travail.

Que nous appellerons naturellement par : https://...../spip.php?page=inserer_base
Libre à vous de rajouter un lien d’appel direct dans votre squelette sommaire.html, eventuellement en le protégeant pour réserver son apparition aux seuls webmestres : voici la noisette correspondante.

Et voila le travail !

Une simple page de menu de travail

Bien sûr ces fichiers de squelettes sont enregistrés dans le dossier ./squelettes (voire dans le sous-dossier de contenu sous Z)..