Update on February the 12th, 2010 : I'd advise to all people that stopped here googling the web about Spip to Drupal migration that they should consider looking at the concurrent spip2drupal Drupal project.
The last time I really did work on my own implementation was two years ago. I think you should not rely on my for this job.
Note for spip2drupal Drupal project developers : I can share what I did, and I think I did dawn robust code because I was working on a Spip site which live something like 5 or 6 Spip major upgrades, with a totally messed up database which means I had to handle *a lot* of edge cases.
I was originally using the Image Drupal project to handle Spip images, which is not anymore a recommended solution so my code is outdated; but it still remains a lot of work to handle different text encodings, database and encodings inconsistent states, and such things, so if you need help, ask me.
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.
Catégories sous SPIP
Salut,
A ma connaissance il n'y a pas de catégories en SPIP. Mais je pense que ce que tu voulais comparer c'est les catgéories sous Drupal et les rubriques sous SPIP. La terminologie n'est pas la même (elle est bcp plus généraliste sous Drupal) même si au final cela revient au même. Mais si tu parles de catégories à un Spipeur qui ne connait pas Drupal il va y avoir confusion, d'autant que les spipeurs ont tendance à créer des "catégories", justement, en utilisant des mots clés spip.
Bref, là ça devient de moins en moins compréhensible. Je pense qu'il faut préciser le terme dans ta présentation.
@+
En effet, on parle de
En effet, on parle de rubrique. Enfin si on regarde dans le code et dans la base de données de SPIP, on parle même de "mots" et de "groupes_mots" (correspondant respectivement aux "termes" et aux "vocabulaires" de la taxonomy Drupal).
Et de plus !
Et en plus, les rubriques sont encore autre chose, point de vue de mapping, créer un vocabulaire Drupal pour l'occasion et placer toutes les rubriques dedans semble une bonne solution.
Comment se passe le processus
ca me semble trés intéressant,
Pour ce qui est du
Pour ce qui est du découpage de la migration en une somme d'opérations minimes, j'utilise un "framework" que j'ai fait pour l'occasion assez proche de la batch_api de Drupal 6 (je suis ici sur du Drupal 5).
Le découpage se fait par une réécriture de requêtes SQL qui pose des LIMIT/OFFSET au bon endroit. Le module qui gère le "batch_api" (ou erzatz) se content lui de récupérer une valeur de fin lors lorsqu'une opération de migration se termine (qui se veut être l'endroit où il est rendu) pour relancer la même opération lors de la requête suivante en redonnant cet ID à la même méthode, jusqu'à avoir un retour indiquant qu'il n'y a plus de données à traiter, processus simple et utilisé un peu partout (on voit ça dans des cron parfois).
Après, en interne, les opérations de migration sont plutôt basiques, il s'agit d'une simple migration comme on aurait pu faire avec des scripts SQL; mais avec des scripts PHP qui utilise l'API Drupal.
Je vais pas m'étaler plus, car lorsque j'en aurais fini, je releaserais tout ce code, et essayerais de rédiger de la documentation.
Il faut garder en tête que ce découpage est de loin la partie la plus aisée de la migration de SPIP. Lorsqu'on arrive à essayer d'interprêter correctement la syntaxe SPIP en utilisant les fonctions d'un SPIP bootstrapé dans le Drupal, ça devient plus tordu, car SPIP pose une grosse partie de sa configuration dans des variables globales, ça devient alors dur de savoir exactement ce qu'il faut charger pour ne pas non plus bootstrapper le SPIP complet.
Au final, ça à abouti à l'écriture de requêtes de pre/post traitement des contenus migrés afin de corriger des erreurs d'interprêtation, et finaliser l'import des données.
Bon, j'ai rédigé ça à 1h du mat, donc ça doit paraître un peu flou :) Mais c'est une vraie aventure cette histoire!
Vivement la suite ! Merci
Vivement la suite ! Merci
Y aura-t-il un jour une
Y aura-t-il un jour une suite à ce billet? 2/3 et 3/3 verront un jour le jour?
Suite
Oui, il y en aura probablement une, mais vu l'état actuel du module, je prendrais des raccourcis sur l'histoire que je raconte.
Cette suite apparaîtra dès que je releaserais une version du module, j'espère toujours avoir le temps bientôt; il devrait de nouveau me servir pour un site associatif très rapidement, ce sera le bon moment pour faire un dernier lot de bugfixes.
Le problème aujourd'hui c'est que la release se fera sur du Drupal 5, et donc, pour en profiter, il faudra monter un Drupal 5, utiliser le module, puis le migrer en Drupal 6 par la suite (ce qui ne devrait pas poser de soucis car il n'utilise que très peu de modules contrib étranges).
le module est disponible?
Merci. où se trouve ce module? Je jouerais bien un petit tour avec, même s'il n'est pas complet. C'est déjà un pas important.
suite ?
Bonjour,
Bah, ça va être difficile car Drupal 7 est dans les tuyaux... Pourtant, c'est une idée intéressante... Où en est ce module ?
Il est très loin
Je n'ai malheureusement pas eu le temps de m'y remettre, et c'est pas mon planning actuel qui va me permettre de le faire!
Le module est toujours existant quelque part dans un coin pour Drupal 5. Avec toujours un poil de code métier spécifique à une migration particulière qu'il faut sortir de là. Peut être un jour aurais-je le temps de le nettoyer, c'est pas dit avant quelques mois.
Si je trouve le temps je pourrais toujours mettre le code à disposition (la précondition est que j'enlève le code spécifique au projet, c'est quasiment rien sur la totalité du code).
spip2drupal
http://drupal.org/project/spip2drupal
Note about existing spip2drupal project
I known this module exists, I found it some time ago while looking on drupal.org
It seems that this module uses the exact same technical solutions that I did 2 years ago while developing my own spip to drupal migration project. I had some advance:)
Seriously, it means that it must be good quality and I'd advise everyone to look at this project instead of asking me questions. After two years of non activity on my own project, you can consider I abandoned it.