Un projets de refonte est souvent périlleux, notamment quand un grande nombre de contenus est à reprendre. Pendant cette conférence nous traiterons de cette problématique en mettant en exergue les bonnes pratiques et les points de vigilance pour réussir sa migration.
Cette conférence s'adresse autant à un prestataire souhaitant éviter les multiples embuches qu'à un chef de projet client souhaitant mettre toutes les chances de réussite de son coté. Nous baserons nos conseils sur un cas client : une migration pour le ministère de l'Agriculture.
Drupagora 2014 : Reprendre un projet avec Drupal quand on a des centaines de milliers de contenus
1. Reprendre un projet avec Drupal
quand on a des centaines de milliers
de contenus
2. Au programme
> La reprise des contenus c’est casse g***
> L’importance de définir la reprise dès le cahier des
charges
> Les méthodes possibles avec Drupal
> Retour sur le projet du Ministère de l’Agriculture
4. Les erreurs les plus courantes
• « Oh, on verra ça à la fin, après les développements »
• « on va embaucher des stagiaire payées au lance-pierre »
• « Ca prendra pas beaucoup de temps »
• « on reprend tout à l’identique »
• « on réécrit tout de toute façon »
• A la fin du projet : « Mais, ???!!! On croyait que vous vous en chargiez ??!! »
• « On va faire tourner une moulinette, et puis ça ira tout seul ! »
9. Il faut dire et répéter
que ce n'est que eux
qui pourront piloter
ce chantier, car c'est
eux qui connaissent
leur contenu
10. Il faut faire un projet
à part, le paralléliser
avec la conduite
technique du projet
et identifier les
adhérences.
11. Il faut sensibiliser aux
différences de l’avant
– après : la méthode
de gestion des
contenus ne sera
évidemment pas la
même et cela aura un
impact sur la façon
dont on va reprendre
les contenus !
12. Les grandes lois de la reprise de
contenu
1. Il n’y a pas de méthode universelle.
2. Il faut construire à chaque fois une méthode, et savoir
qu’on devra revenir dessus.
3. Il faut procéder par itérations successives.
13. La reprise des contenus, ça se
définit dès le cahier des
charges
15. Faire une matrice de reprise des
contenus
Titre de la page URL de la page Etat du contenu
Niveau de
retraitement souhaité
Positionnement cible dans
futur site
Type de contenu
cible
Titre 1 www.test.fr trop détaillé illustrations à fournir thématique article
Titre 2 www.test.fr inadapté pour la cible A simplifier actualité
Titre 3 www.test.fr Difficile à comprendre A réécrire agenda
Titre 4 www.test.fr inexistant illustrations à fournir FAQ
Acceptable …
16. Faire une matrice à partir :
• De Google
• Du back-office existant
• Du parcours du site existant (ou plan du site)
17. Reclassifier les contenus en « types de
contenus » made in Drupal
• Actu ?
• Evènement ?
• Page éditoriale ?
• Glossaire ?
• Rubrique ?
• Fiche métier
• …
Cette « re-classification » est plus ou moins facile selon les sites pré-existants.
18. 1. Evaluer la capacité de reprise
automatique – une mission à part
• Reprendre depuis un ancien Drupal ?
• Exploiter les modules de la communauté Drupal
• Connexion possible à la base de données ?
• Quelle est la structure de la base de données ?
• Quelle est la qualité des données stockées en base de données ?
• Un / des exports XML sont-ils possibles ?
• Un crawler est-il envisageable ?
19. Les « n »
méthodes
automatiques
de reprise des
contenus
20. Reprendre depuis un ancien Drupal ?
Il existe des logiques de migration D5 – D6 – D7 qui embarquent les
contenus.
Mais cela dépend très très fortement de la qualité du développement
original.
Très souvent, c’est aussi compliqué que dans un projet d’un autre CMS.
21. Le test des modules
Cela suppose d’avoir un CMS connu :
• Avec Typo3
• Avec Spip
• Avec Joomla
• Avec Wordpress
• …
Et que cela prenne en compte toutes les spécificités du projet antérieur.
22. La reprise directe en base de données
Identifier toutes
les tables
contenant des
contenus à
reprendre
Identifier toutes
les entrées des
tables et les
faire
correspondre
avec le
structure de
contenu Drupal
Identifier tous
les besoins de
retraitement du
WYSIWYG
Lancer un script
de reprise par
type de
contenu
Utiliser un ETL ?
23. Les modules de migration avec Drupal
• Avec Migrate
• Avec Feeds & Feeds Tamper
24. Un crawler ? Oui, mais…
• Il faut être certain de pouvoir parcourir toutes les pages
• Disposer d’un sitemap
• Ne pas avoir de pages orphelines
• Le balisage HTML doit être cohérent
• Il faut associer ce crawler au traitement de la matrice des contenus
25. Dans tous les cas, il faut retraiter le
HTML
• Identifier les balises à retraiter
: styles, tableaux, balises
propres au CMS initial
• Identifier les images et les
fichiers pour les importer
• Recréer les liens relatifs entre
les pages
26. Quelques trucs et astuces
• Utiliser un module / développement adhoc, permettant de basculer
d’une structure de contenu à une autre
• Permettre de « flagguer » des contenus qui ne doivent pas être
réimportés / écrasés lors des itérations
28. Et finir par la reprise manuelle :
- Exceptions qui ne peuvent être traitées
automatiquement
- Réécriture nécessaire
29. Les facteurs déterminants d’une
reprise manuelle
• Le temps de réalisation
de la moulinette
automatique est
supérieur au temps
évalué de reprise
manuelle
• Le contenu généré en
HTML n’est pas propre
du tout
• Indicateur 1 : multiplier par 10 le temps
évalué pour la reprise automatique ;-)
• Indicateur 2 : réintégrer une page de
contenu de 800 caractères, avec deux
images et trois fichiers à télécharger, ça
prend 30 minutes !!
31. Contexte
• Un site sous Spip
• Un site avec plusieurs couches de développement successives
• Un volume de contenus non identifiés
• De multiples collaborateurs et rédacteurs aux pratiques hétérogènes
32. On a tenté de normer le périmètre de
reprise…
• Redéfinition d’une charte éditoriale complète
• Tableur de 20 000 lignes de repositionnement des contenus
• Identification des types de contenu cible
• …
~20 jours / homme d’accompagnement
33. Des scripts très compliqués ont été mis
en place pour repositionner les
contenus
• Exploitation du tableur Excel pour les scripts Migrate
• Positionnement dans l’arborescence
• Regroupement de contenus
• Association automatique de vocabulaires
• …
• Retraitement des contenus HTML pour supprimer les styles et balises
de SPIP
~30 jours / homme pour la V1
35. On a donc fait machine arrière
• V2 avec tous les contenus sans exclure des éléments
• Retraitement de scripts pour simplifier les retraitements de
positionnement
• Rajout d’une fonction de transfert d’une structure à une autre
• Rajout d’un flag sur chaque contenu pour autoriser / refuser son
import
Puis une V3, V4, …
Et, reprise manuelle !
~20 jours / homme pour la
finalisation
On se dit qu’on a plein de modules communautaires, que d’autres personnes ont déjà eu le même problème, …
Adhérences techniques : on ne peut lancer la reprise que lorsqu’on a un socle technique Drupal avec les structures de contenus faites.
Il faut savoir que toutes les logiques itératives d’import écrasent les contenus = prévoir de ne pas faire de saisie manuelle
Il faut dire & répéter que ça prend du temps & de l’argent
Il faut dire & répéter que ça prend du temps & de l’argent
Il faut dire & répéter que ça prend du temps & de l’argent
Il faut dire & répéter que ça prend du temps & de l’argent
13
Il est important à ce stade, pour faire un chiffrage, de décider d’une reprise manuelle / automatique. Si on veut avoir un budget / délai global !!!
Mais non, à ce stade, ce n’est pas possible. Il faut aller étape par étape.
De google, oui, mais, c’est souvent pollué : de nombreuses pages référencées plusieurs fois, d’éléments constitutifs de pages référencés plusieurs fois.
Du back-office, si c’est possible
Du parcours du site existant : oui, si vous le connaissez bien.
On utilise Content Migrate CCK, Migrate Fields
Les modules sont obsolètes ou en développement.
Spip2Drupal : version 6 pas encore en stable
Joomla to Drupal : users, sections, categories dans taxonomies, contents items to nodes
Worpress Import : uniquement version 6
Typo3 Migrate : extension de Migrate : users, standard typo3 pages, news and news categories
– pas de traitement conditionnel ;
– support déficient du multilinguisme.
Attention, les fichiers Excel ou XML doivent être propres !!
Feeds tamper permet de modifier des données avant qu’elles soient sauvées (ex : format de Dates)
Avec Feed, vous définissez le mode de récupération :
Fetcher mode de récupération des données (par défaut, fichier ou via HTTP) ;
Parser grammaire selon laquelle les données sont présentées (RSS, CSV, etc.) ;
Processor choix de l’entité de destination (par défaut : nœud, terme de taxonomie, utilisateur) + mise en correspondance (« mapping ») avec champs et
propriétés.
Mais pb avec Feeds :
+ Gestion native des importations périodiques ;
+ importateurs exportables ( !) en code avec Features ;
+ support d’XPath ;
~ support limité du pré-traitement des champs avec Feeds
Tamper ;
autant de feeds importer que de types de contenus, et quelques modules de nettoyage (Feeds Tamper)
Migrate offre un cadre de développement orienté objet permettant
d’effectuer des migrations de données y compris dans des situations
complexes.
Migrate fournit un framework d’import de données depuis différentes sources vers Drupal. Il permet de créer son import en définissant la source, la destination et le mapping nos données. On peut jouer et rejouer nos imports facilement (fonction de rollback) en utilisant l’interface utilisateur ou Drush.
Module en lui-même réservé aux développeurs, mais :
utilisable par tous → interface utilisateur puissante offerte par
ce module (analyse, lancement des importations, progression,
arrêt, retour en arrière (rollback)) ;
pilotable avec Drush ;
il existe des modules basés sur Migrate répondant à des cas
d’utilisation précis : migration depuis Wordpress, phpBB, un
autre Drupal...
MigrateSource description des champs de données à la
source ;
MigrateDestination description des champs de données à la
destination ;
MigrateFieldMapping correspondance des champs entre source et
destination ;
MigrateMap garde trace des champs de la source (et
leurs types) dont découle un objet dans la
destination, utile pour le rollback.
Feeds : permet dans de nombreux cas aux site builders de
gérer eux-même les importations (mais pourquoi toujours en
alpha ?) ;
Migrate : un socle rigoureux, robuste et puissant, tant pour le
développeur que pour l’utilisateur. Standard de facto dans
l’écosystème (passage d’une version majeure à une autre,
D6 → D8 et D7 → D8) ;
importation vers tout type d’entité Drupal, y compris les
vôtres (cf. juin).