Une migration sous SPIP - 1/ analyse

La plus grande valeur d’un site, c’est son contenu (et accessoirement ses URLs déjà significatives).
Migrer un site plutôt que le reconstruire apporte une économie importante, en temps et donc en valeur ; mais question : comment assurer la migration d’un site de contenu.

Cette série d’articles rapporte une expérience pratique de reprise sous SPIP d’un site développé sur un petit CMS maison, à convertir en SPIP 3.1 grâce aux facilités de SPIP.

Accessoirement, des articles introduiront des fonctions utilitaires généralistes, rendant accessible une migration de presque n’importe quel site dynamique sous SPIP sans programmation.
Un plugin suivra peut-être.....

Article publié le 5 juillet 2017, et actualisé en juillet 2017


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).

  1. [(#REM) inserer_base_tables = squelette de départ : affichage brut ]
  2. <h3>Liste des tables de la base à migrer </h3>
  3.  
  4. <h4>Accès Restreint</h4>
  5. <BOUCLE_acces_restreint(acces_restreint)>
  6.    #IDACCESRESTREINT, #UTILISATEUR , #MOTDEPASSE <br />
  7. </BOUCLE_acces_restreint>
  8. #COMPTEUR
  9. </B_acces_restreint><hr />
  10.  
  11. <h4>Rubriques</h4>
  12.   <b>IDRUBRIQUE</b>, IDRUBRIQUEHAUT, LIBELLE , VISIBILITE, POSITION  , MONLIEN <br />
  13. <BOUCLE_rubriques(rubrique){par idrubriquehaut}{par idrubrique}>
  14. <b>#IDRUBRIQUE</b>, #IDRUBRIQUEHAUT, #LIBELLE , #VISIBILITE, #POSITION  , #MONLIEN <br />
  15. </BOUCLE_rubriques>
  16. #COMPTEUR
  17. </B_rubriques><hr />
  18.  
  19. <h4>Articles</h4>
  20. <h4>Diaporamas</h4>

Télécharger

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 :

  1. [(#REM) inserer_base_rubriques = squelette de départ : affichage brut ]
  2. <h4>Rubriques</h4>
  3.   <b>IDRUBRIQUE</b>, IDRUBRIQUEHAUT, LIBELLE , VISIBILITE, POSITION  , MONLIEN <br />
  4. [(#REM) boucle complétée pour examiner les valeurs de visibilité ]
  5. <BOUCLE_rubriques(rubrique){par visibilite}{fusion visibilite}{par idrubriquehaut}{par idrubrique}>
  6. <b>#IDRUBRIQUE</b>, #IDRUBRIQUEHAUT, #LIBELLE , #VISIBILITE, #POSITION  , #MONLIEN <br />
  7. [(#REM)  ET maintenant  inserer_objet ( Rubrique #ID_RUBRIQUE ) ]
  8. </BOUCLE_rubriques>
  9. #COMPTEUR
  10. </B_rubriques><hr />

Télécharger

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.

  1. [(#REM) inserer_base = squelette principal de menus ]
  2.  
  3. <h3>Menu principal des tables de la base à migrer </h3>
  4.  
  5. <ul>
  6. <li>Liste des <a href=#URL_PAGE{inserer_base_tables}">tables</a> de la base à migrer. </li>
  7. <li>Lister les <a href=#URL_PAGE{inserer_base_rubriques}">rubriques</a> à insérer. </li>
  8. </ul>

Télécharger

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.

  1. [(#REM) noisette pour appel du menu de travail réservé aux Webmestres]
  2. [(#AUTORISER{webmestre}|sinon_interdire_acces]
  3. [ <p>Accéder au <a href="#URL_PAGE{inserer_base}">menu spécial d'inserer_base</a>.</p>]

Télécharger

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)..


Merci de nous signaler les coquilles, imprécisions ou erreurs qui figureraient dans cette page.

[1Un autre plugin pour automatiser ce processus ? Demandez !

[2Ces codes d’accès sont certainement stockés dans un fichier source du CMS, donc vous pourriez les retrouver grâce a votre accès FTP, mais... c’est plus clair de les noter !

[3Visualisez votre base avec un phpMyAdmin... ou mieux, le plugin Adminer.

[4Il est possible de le faire dans d’autres dossiers, mais comme il s’agit d’un objectif de remplacement.....

[5Cette analyse va nécessiter un peu d’investigation sous Adminer...

[6Vous remarquerez que le codage des données est actuellement en iso-generic ; nous verrons les transcodifications nécessaires !

[7Avec un nom de table écrit en minuscules pour être accédé tel quel sans préfixe.

[8Aucun rapport avec le (très utile) plugin SPIP du même nom... une simple coïncidence dans notre cas !

[9Bonjour la sécurité : voyez plutôt l’encodage des mots de passe en SPIP !

[10On viendra ensuite sur la notion de idsecteur, plus difficile à reconstituer...voir la structure des rubriques de SPIP

[11Si nous utilisions Z ou Zpip, l’apparence serait reprise de votre thème...


Liens A2A visibles seulement pour les inscrits.
Liens visibles seulement pour les inscrits.

Article publié le 5 juillet 2017, et actualisé en juillet 2017 .

Répondre à cet article