Drupagora 2014 : Reprendre un projet avec Drupal quand on a des centaines de milliers de contenus
Télécharger en tant que PPTX, PDF1 j'aime1,299 vues
La reprise de contenu avec Drupal peut être complexe et nécessite une planification précise dès le cahier des charges. Il est crucial d'anticiper les défis liés à la migration, de définir des méthodes adaptées et de réaliser des itérations pour garantir la qualité du contenu transféré. Des exemples de projet, comme celui du ministère de l'agriculture, soulignent l'importance d'une approche organisée et la nécessité de s'assurer que toutes les données sont correctement identifiées et traitées.
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
- 3. La reprise des contenus c’est casse g****
- 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 ! »
- 5. Et puis, avec Drupal, c’est facile, non ?
- 7. Les points de vigilance Le client ou l'équipe métier n'anticipe souvent pas suffisamment ou ne sait pas ce que ça implique :
- 8. Ca prend du temps et de l’argent
- 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
- 14. Décider d’une reprise manuelle ou automatique ?
- 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
- 27. Importer, tester, recommencer, importer, tester, modifier les scripts, recommencer, importer, recommencer, Importer, tester, recommencer, importer, tester, modifier le script, recommencer, importer, recommencer, Importer, tester, recommencer, importer, tester, modifier le script, recommencer, importer, recommencer,
- 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 !!
- 30. Retour sur le projet du Ministère de l’Agriculture
- 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
- 34. Mais au final, on avait oublié plein de contenus !
- 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
- 36. Merci Questions? Marine Soroko – Core-Techs
Notes de l'éditeur
- #6: On se dit qu’on a plein de modules communautaires, que d’autres personnes ont déjà eu le même problème, …
- #8: 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
- #9: Il faut dire & répéter que ça prend du temps & de l’argent
- #10: Il faut dire & répéter que ça prend du temps & de l’argent
- #11: Il faut dire & répéter que ça prend du temps & de l’argent
- #12: Il faut dire & répéter que ça prend du temps & de l’argent
- #14: 13
- #15: 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.
- #17: 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.
- #21: On utilise Content Migrate CCK, Migrate Fields
- #22: 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
- #24: – 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).