La science derrière une migration réussie de Drupal 7 vers 9 (et pourquoi certains d'entre eux échouent)

Vous souvenez-vous de ce site Web génial que tout le monde dans votre entreprise aimait (ou du moins tolérait) et que vous avez été obligé de migrer vers un système plus récent ? Et l'équipe à qui vous avez fait confiance pour le faire a peut-être mordu plus qu'elle ne peut mâcher ? Ce qui était autrefois un site Web parfaitement beau et fonctionnel devient maintenant un gâchis de problèmes bizarres, de mauvaises performances ou parfois un site presque inutilisable.

Si cela vous semble familier et que vous rencontrez des problèmes étranges après avoir mis à niveau votre site Drupal 7 (ou 6) vers Drupal 9 (ou 8), veuillez lire cet article jusqu'à la fin . Nous allons aborder les problèmes courants auxquels les propriétaires de sites sont confrontés après avoir mis à niveau Drupal 7 (ou 6) vers Drupal 9 (ou 8) et comment ils peuvent être résolus. Cela ne couvrira pas tous les problèmes que nous rencontrons lorsque nous intervenons pour un sauvetage de migration, mais devrait au moins vous amener à un point où vous pourrez vous endormir la nuit.

Mise à jour Drupal 7 vers 9 - Le défi fondamental

La première question que vous vous posez probablement est : « Pourquoi ? La mise à niveau de Drupal 7 vers Drupal 9 (Drupal 8 a maintenant été supprimé) semble ne pas être si difficile du point de vue de la plate-forme.

Eh bien, Drupal 8 a tout changé. Il a fait l'objet d'une refonte complète de l'architecture afin que le CMS soit plus durable, pertinent et plus facile à maîtriser à long terme. Son adoption de technologies et de frameworks modernes comme la programmation orientée objet, Symfony, Twig, les dernières versions de PHP et (tellement) plus, a également permis à la communauté Drupal de se développer de manière exponentielle en accueillant un plus large éventail de compétences pour aider à construire Drupal. Cela signifie qu'il est désormais plus facile de trouver un expert pour créer et maintenir votre site Web Drupal. La bonne nouvelle est que la mise à niveau vers toutes les futures versions de Drupal (comme Drupal 8 vers Drupal 9) après cette migration initiale est extrêmement facile et ne nécessitera pas de reconstruction.

Mais revenons au problème actuel, de nombreuses organisations sont encore en train de migrer de Drupal 7 vers 9 , ce qui implique une reconstruction complète du site Web. La reconstruction elle-même est suffisamment complexe sans maintenir la structure de contenu actuelle qu'elle peut donner aux développeurs les plus expérimentés. Et dans la plupart des cas, les sites Web plus importants nécessitent encore plus d'attention car ils ont tendance à avoir plusieurs modules contribués et personnalisés qui n'ont pas de chemin de mise à niveau direct. Tout cela ensemble ouvre des possibilités infinies d'erreurs.

Pour les équipes qui n'ont pas tenté ce type de migration, le plus souvent, la première erreur de migration Drupal 7 à 9 est le manque de préparation. La première et la plus importante étape pour une migration Drupal réussie consiste à effectuer un audit de migration approfondi pour analyser chaque petit détail de la structure actuelle du site Web . Non seulement ce rapport vous aide à évaluer les implications de la migration, mais il vous donne également un aperçu des domaines à améliorer. La prochaine étape la plus importante consiste à décider si vous souhaitez autoriser un partenaire de développement Drupal spécialisé (quelqu'un qui respire Drupal jour après jour) à effectuer la migration. Tout comme vous préféreriez qu'un chirurgien cardiaque effectue un pontage plutôt qu'un chirurgien orthopédique ; avoir une entreprise spécialisée dans Drupal pour créer votre site Web Drupal mènera à une migration réussie.

Défis courants de migration de Drupal 7 à 9

L'une des sources de frustration les plus courantes après une migration Drupal 6/7 vers 8/9 est de ne pas savoir par où commencer face aux problèmes. Comment, avec ou sans compétences en codage, découvrir où se situent les vrais problèmes ? Facile - vérifiez vos journaux d'erreurs. Je sais, on dirait que vous ouvrez une autre boîte de vers en essayant de comprendre ce que disent les journaux, mais nous vous expliquerons les plus courants ci-dessous.

Plongeons directement dans certains des problèmes les plus courants rencontrés par les propriétaires de sites Drupal après une migration de Drupal 7 vers Drupal 9.

Le site Web est à peine opérationnel / cassé

1. Problèmes de serveur : votre serveur peut être compromis si vous ne disposez pas des autorisations suffisantes pour accéder à votre serveur. Un examen plus approfondi des journaux d'erreurs vous aidera à comprendre d'où provient le problème. S'il s'agit d'un problème de serveur, assurez-vous d'avoir suffisamment de droits pour accéder à votre serveur. Contactez votre fournisseur d'hébergement pour augmenter votre limite de mémoire si vous rencontrez un problème de manque d'espace. Si cela ne vous aide pas, créez un ticket avec eux en mentionnant votre problème de serveur.
2. Code personnalisé : si votre site Web Drupal 6/7 était plus complexe que prévu, il est probable qu'au lieu d'évaluer le code personnalisé et de le mapper correctement avant la migration, un simple lifting and shift a été effectué. Si vous avez des conditions personnalisées qui se déclenchent lorsque votre page se charge et qu'elle ne trouve pas le code personnalisé qui lui est associé, vous vous retrouverez avec une page cassée. La première chose à faire est de vérifier si vous avez correctement évalué le site Web dans votre audit de migration (si vous en avez fait un) pour vérifier les modules et le code personnalisés. Si le problème est dû à une condition personnalisée et que le code est manquant, vous aurez besoin de votre développeur Drupal pour créer l'implémentation du code personnalisé. Idéalement, le code personnalisé doit avoir été créé avant la migration de tout contenu.
3. Module Core/Contrib : Parfois, vous pouvez rencontrer un problème connu sur votre module core ou contribué qui a déjà une solution/correctif. Une petite recherche peut aider à l'identifier. Trouvez et appliquez le patch et vous devriez être prêt à partir.
4. Version/bibliothèques PHP obsolètes : votre nouveau site Drupal exécute peut-être encore une ancienne version de PHP ou des bibliothèques dont dépend votre code. Assurez-vous que votre site Web implémente la dernière version de PHP et d'autres bibliothèques. Vérifiez également si toutes les exigences et configurations du système sont remplies.

Impossible de modifier les pages (problèmes d'autorisation)

1. Erreur 500 : si vous ne parvenez pas à modifier les pages parce que vous rencontrez une erreur de serveur interne 500, cela peut être dû à diverses raisons (mauvaise configuration, mauvais code, mauvaise indexation, agrégation, etc.). Cependant, l'une des raisons les plus courantes est que cela peut être dû à une incompatibilité entre les formats de champ ou à des champs manquants. Par exemple, si votre champ de date de votre site Drupal 7 n'est pas migré au bon format ou si la valeur n'a pas été transformée au format Drupal 9, une erreur sera générée. Un autre exemple est si dans Drupal 7 vous avez utilisé le champ Images mais, dans Drupal 9, vous utilisez un champ média à la place. La meilleure façon de résoudre ce problème est de rectifier le script de migration pour stocker les données correctement. S'il n'y a que quelques champs à modifier, vous pouvez également créer une mise à jour de crochet.
2. Erreur 403 : Souvent, l'erreur 403 est due à un transfert incorrect des autorisations. Vérifiez si les autorisations sont correctement configurées. Si vous utilisez un module pour gérer vos utilisateurs, vérifiez s'il est disponible dans Drupal 9. Parfois, vous pouvez avoir des crochets ou des abonnés aux événements limitant l'accès à certains utilisateurs. Vérifiez ces conditions et assurez-vous qu'elles sont également mises en œuvre dans votre nouvelle installation.
3. La page des autorisations ne répond pas : votre site Drupal implémente peut-être un code personnalisé pour gérer les autorisations. Si ce code n'est pas implémenté dans le nouveau site Drupal 9, vous ne pourrez peut-être pas afficher ou modifier (ou les deux) la page des autorisations. Parfois, nous voyons des situations où les utilisateurs ont été migrés en masse sans migrer correctement leurs rôles et profils d'utilisateurs. En règle générale, avant de migrer les autorisations, le développeur doit créer des autorisations personnalisées et les attribuer aux rôles des personnes/autorisations.

Performances médiocres du site Web

1. Modules inutiles : les modules sont les éléments constitutifs de votre site Drupal, vous voudrez donc également les migrer. Mais parfois, nous voyons des modules inutiles obsolètes de Drupal 7 déplacés vers Drupal 9, ce qui peut causer toutes sortes de problèmes. D'autant plus qu'ils peuvent alourdir votre site. Voici quelques raisons pour lesquelles certains de vos modules n'ont pas besoin d'être migrés :
   • Le module (ou sa fonctionnalité) a déjà migré vers Drupal Core. Par exemple, le module de contribution Media a été déplacé vers le noyau de Drupal 8.5, ce qui élimine le besoin d'utiliser le module de contribution.
   • Sa fonctionnalité est simple et peut être insérée dans un autre module personnalisé. Par exemple, si un module node::postSave est utilisé uniquement pour un ou deux types de contenu pour choisir où l'utilisateur doit aller une fois le nœud créé, il pourrait être possible de déplacer le code vers un module personnalisé à la place.
   • Les exigences du module doivent être réévaluées. Parfois, un petit changement dans la convivialité peut considérablement améliorer les performances du site Web. Par exemple, tous les sites Web n'ont pas vraiment besoin d'un module de modération de contenu à moins que l'équipe de marketing de contenu ne soit grande et distribuée. Les principales fonctionnalités de flux de travail éditorial de Drupal (ébauche, publication) sont suffisamment bonnes pour la plupart des exigences commerciales qui ne nécessitent pas un flux de travail complexe/détaillé.
   • Parfois, des sous-modules sont installés avec des modules mais sont rarement/jamais utilisés. Ces sous-modules doivent être supprimés.
2. Répliquer la même architecture : bien qu'il soit plus facile de simplement soulever et déplacer et dépoussiérer une migration, ce n'est presque jamais une bonne approche. Surtout si l'ancienne architecture (Drupal 6/7) était désordonnée et moins robuste. Un changement dans la logique métier/les exigences peut également nécessiter une ré-architecture complète. Un audit approfondi du site vous indiquera exactement quels modules doivent être conservés et ce qui peut être éliminé en toute sécurité.

Les intégrations tierces ne fonctionnent plus

1. Version d'API obsolète : si votre site Web est connecté à différents outils tiers tels que Salesforce, Marketo, Mailchimp, etc., une migration mal exécutée peut affecter le fonctionnement de ces intégrations. C'est souvent que l'API que vous appelez dans le module d'intégration Drupal est une version plus ancienne. Le seul correctif est que l'intégration doit être écrite dans la dernière version de l'API tierce.
2. Problèmes de module d'intégration : vous devrez vérifier si les API tierces sont appelées correctement dans le module d'intégration. Les paramètres sont-ils transmis correctement ? Vérifiez comment ils sont définis et récupérés. Vérifiez la file d'attente des problèmes pour ce module d'intégration. Il pourrait y avoir un correctif disponible qui doit être appliqué. Des tests appropriés doivent être effectués pour s'assurer que l'API a été correctement portée sur Drupal 9.

Autres problèmes courants et correctifs

1. Installation du module : utilisez toujours composer pour installer les modules. Cela évitera les erreurs dues à des dépendances invalides/indisponibles.
2. Incompatibilité de la source de migration : quelle que soit votre source de migration (CSV, base de données, JSON, XML), assurez-vous que les champs source correspondent aux champs de destination. Si vous utilisez CSV comme source, gardez à l'esprit l'ordre d'importation - la priorité est importante pour le mappage des types de contenu.
3. Chemins d'accès aux images : souvent, les utilisateurs ajoutent des images directement dans le contenu de CKEditor. Ces images ne vont pas toujours vers le chemin désigné lors de la migration, car leur emplacement est généralement différent de celui où se trouvent les autres fichiers multimédias. Une migration méticuleusement planifiée devrait régler ce problème.
4. SEO : Une migration négligente de Drupal 7 vers 9 peut avoir un impact sur le référencement de votre site Web de plusieurs façons. L'un des problèmes les plus importants est celui des liens brisés. Assurez-vous que la structure et la navigation de l'URL existante sont préservées, car toute modification peut entraîner des tonnes de liens rompus. Un audit SEO complet doit être effectué pour s'assurer qu'il n'y a pas d'obstacles sur la route.
5. Style Drupal 7 : Souvent, des problèmes de migration de Drupal 7 vers Drupal 9 (en particulier des problèmes de performances) apparaissent parce que les développeurs utilisent le même style de codage que Drupal 7 au lieu de s'adapter aux changements apportés par Drupal 8. Exemples, (a) la façon dont vous tuez Le cache de pages est très différent dans Drupal 8. (b) Drupal 8 dispose d'une gestion de configuration intégrée, mais il n'est souvent pas implémenté correctement ou bien entretenu dans tous les environnements. (c) Nous avons également rencontré des cas où le projet Drupal 8 implémente toujours un style de code procédural.