Problèmes connus lors de la mise à jour de Drupal 6 ou 7 vers Drupal 8

Drupal 6 à 8

Catégories d'agrégateurs

Dans Drupal 8, la notion de catégories d'agrégateurs n'existe plus et n'a donc pas été migrée vers Drupal 8.

Protocoles autorisés

Drupal 8 conserve désormais les protocoles dans le paramètre du conteneur « filter_protocols », donc si vous avez modifié la variable « filter_allowed_protocols », veuillez la saisir dans le fichier services.yml.

Dictionnaires autorisés pour le champ de référence taxonomique

Dans Drupal 6, la liste des types de contenu applicables pour un dictionnaire donné est définie dans les paramètres du dictionnaire. Dans Drupal 8, les dictionnaires autorisés peuvent être définis dans les paramètres du champ de lien vers le terme de taxonomie. Ce paramètre n'est actuellement pas migré, ce qui permet de référencer tous les dictionnaires dans Drupal 8. Vous pouvez modifier manuellement les paramètres du champ de lien vers le terme de taxonomie dans Drupal 8 après la mise à jour et choisir les dictionnaires autorisés.

[Corrigé] Formats de date

Seuls les formats par défaut court, moyen et long sont migrés. Tous les autres formats par défaut ont un format de secours et doivent être reconfigurés après la migration.

Champs absents du formulaire d'édition ou de la page d'affichage

Une autre source de confusion est lorsqu’une migration semble réussie, mais que vous ne voyez pas vos champs dans le formulaire d’édition. Rendez-vous sur la page d’administration des types de contenu et ouvrez l’onglet « Gestion de l’affichage du formulaire » pour chaque type de contenu. Les champs ajoutés par la mise à jour peuvent être cachés dans le formulaire d’édition. Si c’est le cas, déplacez-les vers le haut pour qu’ils soient visibles. De même, s’ils ne s’affichent pas dans la vue du nœud, il se peut que les champs ajoutés par la migration soient cachés dans l’onglet « Gestion de l’affichage », et vous devrez peut-être les rendre visibles. Pour la migration des champs personnalisés vers un objet, le module Migrate Plus peut être utile.

La page d’accueil se charge mais le thème ne fonctionne pas

Lors de la migration, il arrive parfois que la page soit blanche et ne charge que quelques éléments, donnant l’impression d’un thème cassé. Visiter /user puis revenir à la page d’accueil résout généralement ce problème.

Interface utilisateur des menus

Les variables menu_primary_links_source et menu_secondary_links_source ne sont pas migrées car elles n’ont pas d’équivalents dans Drupal 8.

Modules et thèmes

Avant de commencer la migration, activez les nouveaux modules et thèmes ainsi que le thème d’administration (le cas échéant).

Types de contenu des nœuds

La configuration par défaut dans Drupal 6 comprend les types de contenu Story et Page. Les types de contenu par défaut dans Drupal 8 s’appellent Article et Basic Page (ce dernier ayant le même nom machine 'page' que dans Drupal 6).

• La migration mappe le type de contenu Drupal 6 Page sur le type Drupal 8 Page, car les noms machines correspondent.
• La migration créera un type de contenu Story pour Drupal 8. Vous souhaiterez peut-être supprimer le type Article par défaut de Drupal 8 s’il n’est pas nécessaire. Pour plus d’informations, consultez #2236289 : La migration des nœuds « story » de D6 crée un nouveau type de contenu dans D8.

Traductions de nœuds

Dans Drupal 6 et 7, les traductions des nœuds étaient stockées dans différents nœuds, tandis que dans Drupal 8, elles sont maintenant combinées avec leurs nœuds de langue d’origine. Le système de migration effectuera la fusion des traductions des nœuds, mais cela signifie que certains liens peuvent pointer vers des nœuds qui n’existent plus. Voir #2746527 : [META] Gestion améliorée des données liées aux traductions des nœuds Drupal 6 et 7 avec des IDs différents.

Notez que les révisions des nœuds traduits ne sont pas encore migrées. Voir #2746541 : [backport] Migration des versions D6 et D7 des révisions des nœuds vers D8 pour plus d’informations.

Aperçu de la mise à jour multilingue de Drupal 6 vers Drupal 8.

Catégories de profil

Les champs regroupés par le module profil dans Drupal 6 ne seront pas regroupés dans Drupal 8.

Champ de profil (liste de sélection)

Le réglage « valeurs autorisées » du champ résultant dans Drupal 8 sera une combinaison de toutes les valeurs personnalisées sélectionnées et des valeurs autorisées actuelles dans Drupal 6, et non seulement les valeurs autorisées dans Drupal 6.

Statistiques

Les paramètres du journal d’accès et les statistiques ne sont pas migrés i18n. La consolidation des statistiques i18n a été migrée depuis Drupal 8.5.2. Voir #2930101 : i18n/statistiques - le compteur de nœuds ne s’actualise pas pour les traductions

Texte / formats d’entrée

Les formats de filtre non reconnus par Drupal 8 seront migrés en tant que filter_null, un filtre qui retourne simplement une chaîne vide. Cela signifie que tout format d’entrée utilisant un format de filtre inconnu ne montrera pas le contenu des champs, bien que le contenu soit en base de données. Cela peut prêter à confusion. Voir #2618332 : Meilleure gestion du remplacement des filtres manquants avec filter_null et #2630578 : Formats dupliqués dans la mise à jour D6

Les formats de filtre non reconnus incluent le tristement célèbre filtre de code PHP et tout autre filtre fourni par un module contrib qui n’est pas disponible dans votre installation Drupal 8.

Le filtre PHP n’est pas supporté dans le noyau Drupal 8 — c’est une très mauvaise pratique — mais vous pouvez utiliser le module PHP si vous en avez vraiment besoin.

Pour corriger cela, vous avez plusieurs alternatives :

• Vérifiez si les modules fournissant les filtres ont une version Drupal 8 et installez-les
• Éditez et sauvegardez les formats d’entrée concernés. Cela supprimera la référence à format_null et le contenu commencera à s’afficher. Notez que, puisque le filtre d’origine n’existe pas, le contenu ne sera pas filtré et des jetons non remplacés peuvent apparaître, voire le site peut être vulnérable à des problèmes de sécurité.
• Modifiez le contenu et changez pour un autre format d’entrée. Cela déplace les mêmes problèmes que le point précédent.

Fuseaux horaires et dates

Drupal 6 utilise un décalage de fuseau horaire pour calculer l’heure locale. Drupal 7 et 8 utilisent le nom du fuseau horaire. Malheureusement, la fonction PHP timezone_name_from_abbr(), qui convertit le décalage en noms de fuseaux horaires, génère différents noms selon que l’heure d’été est activée ou non sur votre serveur. Par exemple, un décalage de 3600 est converti en Europe/Paris si l’heure d’été est désactivée, et en Europe/Londres si elle est activée. La migration est configurée pour ignorer l’heure d’été. Selon la configuration de votre serveur, le réglage du fuseau horaire Drupal 8 peut être incorrect après migration (#2353679 : variable de migration manquante D6->D8 : date_default_timezone).

Dans les fuseaux horaires avec heure d’été, une date peut être interprétée différemment par Drupal 8 comparé à Drupal 6. Par exemple, si l’heure est proche de minuit, la date peut être considérée comme un autre jour. Cela cause des problèmes, surtout si des tokens de date sont utilisés pour construire des chemins (ex : alias d’URL, chemins de champs de fichiers). Deux solutions possibles sont indiquées dans #2926421 : Gestion des incohérences de dates entre D6 et D8.

Alias d’URL

Lors de la migration des alias d’URL pour une langue non activée sur le nouveau site Drupal 8, aucun alias ne fonctionnera tant que la langue ne sera pas activée sur le nouveau site Drupal 8.

Views

Views n’est pas encore migré, vous devrez recréer manuellement les vues dans Drupal 8. Pour plus d’informations, voir #2500547 : Chemin de mise à jour pour Views depuis Drupal 6 et 7 et le module Views Migration.

Configuration du bloc d’activité utilisateur

Les réglages de l’activité utilisateur ne sont pas migrés. Ils doivent être édités manuellement dans la vue correspondante sous filtres / accès (#2169327 : Migrer la configuration du bloc d’activité utilisateur).

Drupal 7 à 8

[Corrigé] Dictionnaires autorisés pour le terme taxonomique

Dans Drupal 7, le dictionnaire autorisé pour le champ de lien vers le terme taxonomique est défini dans les paramètres du champ. Ce paramètre n’est actuellement pas migré, ce qui permet de référencer tous les dictionnaires dans Drupal 8. (voir #2763637 : Les champs de termes taxonomiques D7 ne migrent pas avec les dictionnaires autorisés). Vous pouvez modifier manuellement les paramètres du champ de lien vers le terme taxonomique dans Drupal 8 après la mise à jour et choisir les dictionnaires autorisés.

Adresses IP bloquées

La colonne id de la table ban_ip dans Drupal 7 n’est pas migrée.

Types de commentaires

Drupal 7 permet aux commentaires d’avoir différents champs selon les types de contenu. En général, les commentaires ont les champs Auteur, Sujet et Commentaire. Comme différents commentaires D7 peuvent avoir différents champs, la migration crée des types de commentaires D8 distincts pour chaque type de contenu :

• Le type de contenu Foo aura le type de commentaire comment_node_foo
• Le type de contenu Bar aura le type de commentaire comment_node_bar

La seule exception est les commentaires du forum. Lorsque le module Forum D8 est activé, un type de commentaire comment_forum est automatiquement créé. Les commentaires du forum D7 sont migrés vers ce type de commentaire.

Note importante : profil d’installation standard Drupal 8 et type de contenu Article
Si votre site Drupal 8 a été installé avec le profil standard, vous aurez un type de contenu appelé Article.

• Ce type de contenu inclut un champ commentaire nommé « commentaire ».
• Le système de migration ne peut pas supposer que le site D8 a été installé avec le profil standard. Par conséquent, un type de commentaire comment_node_article sera créé, et les commentaires des articles D7 seront migrés vers ce type.

En conséquence, votre type de contenu Article aura deux champs de commentaires :

• commentaire, provenant du profil standard D8 et non utilisé
• comment_node_article, créé par la migration

Vous ne voudrez probablement pas avoir deux champs commentaires pour le type Article, donc vous devrez supprimer manuellement le champ commentaire du type Article (admin/structure/types/manage/article/fields). Une fois fait, vous pouvez aussi supprimer le type de commentaire comment (admin/structure/comment) si vous ne l’utilisez pas ailleurs.

Il est recommandé de supprimer le champ commentaire inutile du type Article avant d’exécuter les migrations, car Drupal 8 core comporte actuellement un bug lié à la suppression du champ commentaire, voir #2906470 : Commentaires et enregistrements comment_entity_statistics perdus après suppression d’une instance de champ commentaire.

Code PHP

Les formats de filtre non reconnus par Drupal 8 seront migrés en filter_null, un filtre qui retourne simplement une chaîne vide. Cela signifie que tout format d’entrée utilisant un format de filtre inconnu ne montrera pas le contenu des champs, bien que le contenu soit en base de données.

Les formats de filtre non reconnus incluent le tristement célèbre filtre de code PHP et tout autre filtre fourni par un module contrib qui n’est pas disponible dans votre installation Drupal 8.

Le filtre PHP n’est pas supporté dans le noyau Drupal 8 — c’est une très mauvaise pratique — mais vous pouvez utiliser le module PHP si nécessaire.

Pour corriger cela, vous avez plusieurs alternatives :

• Vérifiez si les modules fournissant les filtres ont une version Drupal 8 et installez-les
• Éditez et sauvegardez les formats d’entrée concernés. Cela supprimera la référence à format_null et le contenu commencera à s’afficher. Notez que, puisque le filtre d’origine n’existe pas, le contenu ne sera pas filtré et des jetons non remplacés peuvent apparaître, voire le site peut être vulnérable à des problèmes de sécurité.
• Modifiez le contenu et changez pour un autre format d’entrée. Cela déplace les mêmes problèmes que le point précédent.

Champs de texte simple

Paramètres de traitement de texte contradictoires dans Drupal 7
Dans Drupal 7, les paramètres de traitement de texte sont définis au niveau de l’instance du champ. Autrement dit, un même champ peut être utilisé pour deux (ou plus) types de contenu, avec des paramètres de traitement du texte « Texte simple » pour un type et « Texte filtré » pour un autre.

Drupal 8 a des types de stockage distincts pour les champs Text (simple) et Text (filtré). Il existe aussi Text (simple, long) et Text (filtré, long). L’important est que ce choix se fait au niveau du stockage dans la définition du champ. Autrement dit, le choix simple/filtré ne peut pas varier selon le type de contenu.

Le système de migration ne fait aucune hypothèse. Si une contradiction dans les paramètres de traitement est détectée, ces champs sont ignorés avec un message dans le journal. Le constructeur de site a deux options :

1. Modifier les paramètres de traitement sur le site Drupal 7 pour que tous les types de contenu utilisant ce champ aient les mêmes paramètres.

• Faites attention à la manière de concilier les paramètres pour éviter des failles de sécurité XSS (Cross-Site Scripting).
• Si le champ Drupal 7 était en « Texte simple » et que des utilisateurs non fiables pouvaient publier dans ce champ, il se peut que ces champs contiennent des entrées malveillantes. Cela n’a pas causé de XSS sur Drupal 7 car le champ était en Texte simple et le contenu malveillant n’était pas interprété. Si vous changez maintenant le champ en Texte filtré, assurez-vous que le format de texte n’autorise pas HTML complet ou autre contenu dangereux.

2. Si vous avez besoin d’avoir deux paramètres de format différents dans Drupal 8, vous devez créer une migration personnalisée qui scinde le champ Drupal 7 en deux champs Drupal 8 distincts. Pour plus d’informations sur la personnalisation des migrations lors de la mise à jour vers Drupal 8, consultez : Personnaliser les migrations lors de la mise à jour vers Drupal 8.

Texte avec résumé + formatage du texte simple dans Drupal 7
Drupal 7 possède un type de champ Long text and summary. Le type de champ correspondant dans Drupal 8 est Text (filtré, long, avec résumé). Dans Drupal 7, on peut configurer l’instance de champ pour que le traitement soit en texte simple. Les champs Text (filtré, long, avec résumé) sont toujours en texte filtré dans Drupal 8.

Le système de migration ne fait aucune hypothèse. Si un champ Long text and summary a des paramètres de format texte simple, il est ignoré avec un message dans le journal. Le constructeur a les mêmes deux options que ci-dessus :

1. Changez le format de champ de Texte simple à Texte filtré dans Drupal 7.

• La remarque concernant le XSS s’applique ici aussi.

2. Créez une migration personnalisée et définissez votre propre logique pour migrer ces champs vers Drupal 8. Pour plus d’informations, voir : Personnaliser les migrations lors de la mise à jour vers Drupal 8.

Statistiques

Les réglages du journal d’accès et les statistiques ne sont pas migrés i18n. La consolidation des statistiques i18n a été migrée depuis Drupal 8.5.2. Voir #2930101 : i18n/statistiques - le compteur de nœuds ne s’actualise pas pour les traductions.

Views

Views ne sont pas encore migrés, vous devrez créer manuellement les vues dans Drupal 8. Pour plus d’informations, voir #2500547 : Chemin de mise à jour pour Views depuis Drupal 6 et 7 et le module Views Migration.

Conflits potentiels d’ID (de D6 ou D7 à Drupal 8)

Problème

Comme indiqué sur la page Préparer une mise à jour, le site Drupal 8 doit être complètement vide lors de la mise à jour. Le processus de migration conserve les identifiants du site source lors de leur importation dans le site Drupal 8. Si du contenu a été créé sur le site Drupal 8 avant la mise à jour (par exemple, un nœud avec nid 1), il est probable que les identifiants entrent en conflit.

Le travail est en cours pour détecter automatiquement les conflits potentiels d’identifiants et avertir l’utilisateur, voir #2876085 : Vérification des conflits potentiels d’identifiants avant mise à jour. Pour l’instant, les administrateurs doivent vérifier eux-mêmes les conflits. Si les conflits d’identifiants ne sont pas traités correctement, le contenu ou d’autres entités comme les termes et fichiers taxonomiques peuvent être écrasés, causant une perte de données. Il est aussi possible que les objets liés soient corrompus, par exemple un contenu lié à un mauvais terme taxonomique.

Scénarios pouvant provoquer des conflits d’ID

• Le site Drupal 8 cible était déjà utilisé lors de la mise à jour, et du contenu y avait déjà été créé.
• La migration initiale a été effectuée. Après la migration initiale, du contenu ou d’autres objets ont été créés sur les deux sites source et cible. Lors du transfert du contenu mis à jour/créé depuis la source, les identifiants peuvent entrer en conflit avec le contenu existant sur Drupal 8.
• Le site Drupal 8 cible était vide, mais des modules ajoutés ou personnalisés ont inséré des données à des fins propres, par exemple le module Forum principal de Drupal 8 crée un terme de taxonomie pour sa catégorie de discussion générale, qui aura typiquement l’ID #1 dans la nouvelle installation. Si les données sources contiennent un terme taxonomique avec l’ID 1, cela écrasera le nom de la catégorie du forum.
• La source peut contenir des données sans ID, mais la destination en a besoin. Par exemple, Drupal 6 traite les images personnalisées comme des fichiers non gérés sans ID, mais Drupal 8 exige un ID pour les fichiers gérés. Pendant la migration, les champs de fichiers gérés seront créés avec des IDs pouvant entrer en conflit avec des fichiers encore à migrer.
• Les conflits d’ID liés aux traductions ne sont pas détectés automatiquement.

                                     - Si vous effectuez une mise à jour complète sur un site Drupal 8 vide, tout devrait bien se passer.
                                     - Si vous effectuez une migration partielle après la mise à jour initiale et avez ajouté des traductions sur votre site Drupal 8 avant de migrer le contenu mis à jour/créé, la deuxième migration peut écraser ces traductions.

Solutions

Migration personnalisée pour les éléments en conflit
Vous pouvez configurer une migration pour le contenu problématique afin que de nouveaux IDs soient générés pour ces éléments. Notez que cela impactera leurs chemins internes et possiblement leurs URLs publiques. Faites particulièrement attention à corriger tous les liens vers les objets modifiés.

Manipuler les valeurs AUTO_INCREMENT
Lorsque la destination Drupal 8 ne contient pas de données conflictuelles, mais que la migration pourrait créer des conflits, vous pouvez manipuler la valeur AUTO_INCREMENT des tables de la base Drupal 8 afin que les IDs des entités créées ne rentrent pas dans la plage des entités migrées. La migration des images personnalisées citée ci-dessus en est un exemple.

Accepter que les données soient écrasées
Il est toujours possible de continuer la migration malgré tout. Ce n’est probablement pas souhaitable dans la plupart des cas, car cela peut entraîner une perte de données.

Mise à jour de sites multilingues (de D6 ou D7 à Drupal 8)

Pour toutes les migrations multilingues issues des modules d’internationalisation Drupal 6 et 7 (i18n) et du module de conversion d’entités Drupal 7, le module principal Drupal 8 Migrate Drupal Multilingual Module (migrate_drupal_multilingual) doit être activé sur le site Drupal 8.

Aperçu de la mise à jour multilingue de Drupal 6 vers Drupal 8.