...du verbe Drupaler (1er groupe)

Hacked! et Diff ou comment savoir si Drupal a été hacké ou opéré à vif

23. février 2012 - 15:30 -- Wilfrid

Mettre à jour Drupal ? Relativement simple me direz-vous. Quoi que... Supposez que vous reprenez une installation : si cette dernière a été opérée à vif avec des modifications dans le core de Drupal et dans les modules contribués, la mise à jour de Drupal écrasera ces modifications, et des fonctionnalités vont disparaître.

Rappelons que le principe de Drupal est de ne jamais modifier ni les fichiers du core, ni les fichiers des modules contribués. Le framework permet en effet d'altérer 99% des fonctionnalités d'une installation donnée. Il est donc quasiment toujours possible d'altérer le fonctionnement d'un module en créant un autre module.

Heureusement, le module Hacked!, couplé au module Diff, permet de savoir si le développeur précédent a suivi la bonne pratique drupalienne...ou non.

Au moment où je rédige cet article, je viens d'avoir une surprise de taille sur une installation que je dois mettre à jour :

L'installation a donc été complètement hackée dans tous les sens. Le module hacked a en fait récupéré toutes les sources pour les versions du core et des modules installés et les a comparés aux fichiers existants. Il indique donc les fichiers ainsi supprimés et modifiés.

Grâce au module Diff, il est de plus possible de regarder les modifications qui ont été réalisées :

Ici, et pour une raison que j'ignore, une requête a été réécrite (et quelques lignes vide ajoutées...) dans node.module.

Je sais donc qu'il ne va pas être très facile de mettre à jour cette installation !

Autre intérêt de ces deux petits modules combinés : si votre installation a été hackée de manière externe, vous pouvez aller traquer les modifications potentiellements faites par le hacker aux fichiers de l'installation. C'est une des possibilités, mais loin d'être la seule bien évidemment.

Je connais la théorie, mais je veux tout de même hacker Drupal ou un module...

En pratique, il arrive qu'un module contribué (et parfois même le coeur de Drupal, surtout lors de la sortie de nouvelles versions) aient besoin de modifications par exemple si un bug existe toujours (et l'on ne peut pas encore corriger un bug à partir d'un autre module).  Les bonnes pratiques à mettre en oeuvre sont alors les suivantes :

-  Utiliser / créer un patch qui pourra être à tout moment désapliqué, et réappliqué suite à une mise à jour.

-  Réunir tous les patchs au même endroit afin de ne pas avoir à les chercher partout dans l'installation.

-  Documenter, c'est à dire liste tous les modules ainsi modifiés, le patch correspondant, une description du problème et de la résolution, et enfin le lien vers l'issue queue de Drupal (qu'il faut créer si elle n'existe pas déjà). Il sera ainsi possible lors de la prochaine mise à jour de vérifier si l'amélioration ou le bug a été intégré dans la nouvelle version et donc s'il faut réappliquer le patch.

Autre possibilité : supposons qu'un module réalise 70% de ce que vous souhaitez, mais que le développement d'un module supplémentaire s'avérerait complexe. Il n'est pas interdit de prendre ce module comme base de développement et d'en modifier largement le fonctionnement. Cependant, il est alors indispensable de renommer le module afin d'éviter qu'un jour il ne puisse être écrasé lors d'une mise à jour malencontreuse (donc renommer les fichiers 

Catégorie: 
3.25
Average: 3.3 (8 votes)
Votre vote: Aucun(e)

Ajouter un commentaire

Texte simple

  • Aucune balise HTML autorisée.
  • Les adresses de pages web et de courriels sont transformées en liens automatiquement.
  • Les lignes et les paragraphes vont à la ligne automatiquement.
CAPTCHA
Image CAPTCHA