Dans cette partie, nous allons nous intéresser à la phase de pré-production. Idéalement, avant de propulser un site, on se doit de mettre sur pied une pré-prod qui va plus ou moins servir de brouillon et qui va nous permettre de tester, débugguer voire développer tout ce dont on aura besoin pour le futur site.

La vérification du code

Parfois, on ne voit pas les erreurs qui peuvent exister dans un code. Coder, anciennement Code Sniffer s’occupe de cela. Il s’agit d’un module qui va scanner l’intégralité des modules installés et vérifier si le code est conforme aux standards. Par exemple, les else, elseif, les { et autres points-virgules.

Coder va différencier les erreurs critiques, les erreurs «normales » ou mineures mais également ce qui peut être analysé comme des erreurs mais qu’il va ignorer car il les considère comme des faux-positifs. Rassurez-vous, il les listera quand même.

Une fois le rapport généré, il sort une liste, en spécifiant le module et le fichier concerné, la ligne qu’il estime incorrecte, le niveau de sévérité ainsi qu’une explication et un renvoi vers la documentation Drupal qui explique les bonnes pratiques en la matière.

Si vous avez envie de creuser le langage PHP et comprendre son fonctionnement, je vous recommande son apprentissage par le biais de la Lean Academy qui propose exercices et tutoriels sur PHP mais aussi sur Javascript, JQuery, les fondamentaux Web mais aussi le Tuby et le Python.

On pourrait objecter que s’il s’agit de ce type de corrections – somme toute vu comme étant mineures par Coder – on peut procéder aux corrections en production. Ça serait une erreur car parfois, la simple correction d’un point-virgule dans le code peut générer une jolie erreur 500, ce qui n’est pas grave sur une plateforme de pré-production mais qui peut l’être sur une plateforme en production.

Autre point important : il conviendra de désactiver tous les systèmes de reporting par email car lors du scan, le watchdog peut s’emballer et littéralement noyer l’administrateur de mails.

 Il n’y évidemment pas que PHP qu’il conviendra de revoir mais aussi le code HTML et pour ça, le W3C validator fait très bien le job.

Les tests

Autre module essentiel et qui est intégré dans le core de Drupal : test. Il s’agit d’un module qui va tester le bon fonctionnement des modules mais il doit être cantonné aux plateformes de pré-production et être désactivé lors de la mise en production du site. En effet, s’il peut être très utile dans la phase de test et de débug, il va avoir tendance à générer des erreurs et des ralentissements d’exécution quand il fonctionne en production. Les retours d’expérience de Drupal France sont unanimes sur ce point. Pour ma part, j’ai constaté quelques petits soucis lorsqu’il était activé, soucis qui ont complétement disparu lorsqu’il a été désactivé. A titre personnel, je l’ai carrément supprimé du core.

Nous avons balayé les points essentiels de la sécurité sous Drupal. Le prochain volet sera consacré à la check-list des points évoqués précédemment ainsi qu’à certains projets Drupal exclusivement dédiés à la sécurité.