Reply to comment

J'ai eu dans le cadre de mon travail la refonte d'un site contenant un grand volume de donnée. Le coeur de cette refonte reposait sur la migration du site d'une technologie vers une autre. La technologique d'origine est le CMS SPIP, celle d'arrivée le CMS Drupal.

Coeur de la problématique

La problématique est la suivante: réussir à migrer toutes les données du SPIP sans perte de donnée. Nous avons ici deux CMS, avec tout deux une gestion de contenu (articles pour SPIP, nodes pour Drupal). L'ensemble des fonctionnalités de base de ces deux CMS sont similaire, c'est à dire:

• Gestion des articles (un titre, un corps, un auteurs, ...)
• Gestion des utilisateurs (un login, un mot de passe, quelques méta-informations)
• Gestion des rôles (anonyme, authentifié, rédacteur, administrateur)
• Gestion des catégories

Le coeur de notre problématique se situe donc dans le mapping d'un schéma base de donnée vers un autre, en l'occurence celui de SPIP, vers celui de Drupal.

Premier problème complexe: la gestion des différences entre les deux CMS

Les deux CMS n'exploitent pas rigoureusement les même données. Voici les exemples pratiques qui seront le plus redondant entre ces deux CMS:

• Les formats de date différents: MySQL DateTime pour SPIP, UNIX Timestamp pour Drupal.
• La gestion des catégorie: SPIP ne peut intégrer un article que dans une catégorie, Drupal permet de tagger indéfiniement une node avec autant de termes que l'ont veut.
• La gestion des rôles: un utilisateur SPIP ne peut avoir qu'un seul rôle, sur trois qui sont prédéfinis (visiteur, rédacteur, administrateur), alors que Drupal permet d'en créer autant que l'on veut, leur affecter les permissions que l'on souhaite, et donner autant de rôle que l'on désire à un utilisateur.
• Et bien d'autres encore.

Nous allons donc devoir effectuer des opérations de transcription des données de SPIP vers les données de Drupal.

Par chance, on peut constater que l'étendue fonctionnelle de SPIP est beaucoup plus réduite que celle de Drupal, sur quasiment tous les aspects (sauf un, celui du formatage du texte, que nous verrons plus tard), ce qui facilitera beaucoup l'écriture des scripts de migration dans ce sens.

Solution au premier problème complexe: l'écriture de scripts PHP

La solution qui me vient tout de suite à l'esprit est l'écriture de scripts PHP afin de remplir cette mission. En effectuant des requêtes récupérant uniquement les données qui nous intéressent dans le SPIP, on pourra ensuite les traiter en utilisant toute l'API PHP afin de pouvoir convertir les données le plus simplement possible.

Mais n'oublions pas: le schéma Drupal est complexe

Le schéma de stockage de Drupal est beaucoup plus complexe que celui de SPIP (il suffit d'aller faire quelques SELECT aléatoirement dans la base de donnée de l'un et de l'autre pour s'en compte).

Cet état de fait rend complexe l'écriture de requêtes SQL servant à peupler la base de Drupal. De plus, ceci ne prend pas en compte la modularité de Drupal, qui rend le schéma encore plus complexe à analyser. Que ce soit les modules coeur, ou des modules tierce-partie, chacun effectuera ses propres opérations sur la base de données, sans forcément se soucier de ce que font les autres.

L'introspection d'un tel système, hautement modulaire, devient alors très fastidieuse, surtout si on travaille avec des contraintes de temps assez restrictives, ce qui nous pousse à chercher un autre solution.

Deuxième solution: utiliser Drupal comme un Framework

Drupal n'est pas qu'un simple système modulaire. Il propose un ensemble d'outils, une API complète, qui permet de manier de manière simple tout contenu qu'il gère: c'est pas ce biais que nous allons entrevoir la possibilité d'injecter une somme conséquente de contenu tout en minimisant les erreurs.

En faisant confiance au coeur de l'application, on met derrière nous toute la problématique de cohérence des données, et de stockage des méta-données (indéxation pour le moteur de recherche, liens entre les contenus et les catégories, opérations secondaires effectuées par tous les modules tierce-partie).

Nous allons donc écrire un module Drupal afin d'effectuer notre migration.

Suite...

La suite bientôt, décrira un peu plus en détail les problématiques de l'implémentation que j'ai pu rencontrer, et l'architecture technique qui en découle. Une troisième partie devrait suivre et décrire l'implémentation finale du projet.