Les bonnes pratiques et les erreurs à éviter avec un site Drupal. - Architecture - Sécurités - Performances

1. Drupal
Bonnes Pratiques

2. Bonnes pratiques - Partie 1
➢ Architecture
➢ Sécurités
➢ Performances

3. Architecture

4. Architecture
➢ Structurer votre contenu
➢ Configurer l’affichage
➢ Organiser les fonctionnalités

5. Architecture
CONTENU

6. Architecture: Contenu
Le contenu est l’essence de votre site, sa raison d’exister.
Première étape : déterminer la structure.
Une architecture de contenu claire permet de garantir :
○ Bonne performance.
○ Meilleure expérience utilisateur.
○ Maintenance facilitée.

7. Architecture: Contenu
➢ Planifier vos structures :
○ Champs
○ Types de contenus
○ Vues
○ ...

8. Architecture: Contenu
Erreur: Trop de types de contenus différents.
Conséquence: Confusion pour les créateurs de contenus.
Exemple: Des types de contenus “News” et “Articles” qui
sont quasiment identiques.
Solution: Réutiliser et standardiser les types de contenus.

9. Architecture: Contenu
Erreur: Nouveaux champs pour chaque type de contenu.
Conséquence: Gaspillage de ressources et freine la
performance.
Exemple: Un champ ville de l’établissement et ville de
l’enseignant.
Solution: Réutiliser et standardiser les champs.

10. Architecture: Contenu
Erreur: Des types de contenus sans nodes.
Conséquence: Un type de contenu non nécessaire ajoute
une complexité inutile.
Solution: Réévaluer vos besoins quand vous concevez
votre site.

11. Architecture
Affichage

12. Architecture: Affichage
Drupal est un outil puissant qui permet
d’afficher du contenu dans différentes régions,
différents formats, et avec des affichages
divers.

13. Architecture: Affichage
➢ Planifier l’architecture d’affichage.
➢ Optimiser et réutiliser autant que possible.
➢ Commencer avec un thème de base solide.
➢ La facilité pour changer l’apparence du site
est une indication de la bonne architecture
d’affichage.

14. Architecture: Affichage
Erreur: Une nouvelle Vue pour chaque liste.
Exemple: Trois vues distinctes pour des emplois à
Londres, Paris et Lisbonne.
Solution: Analyser chaque Vue que vous créez pour
déterminer si vous pouvez réutiliser une Vue existantes.

15. Architecture: Affichage
Erreur: Code PHP dans la base de données ou dans des
fichiers templates.
Exemple: Un code PHP qui détermine la visibilité des
blocks de score dans une section sports.
Solution: Écrire le code PHP, ou des requêtes SQL dans
des modules.

16. Architecture
Site / Fonctionnalité

17. Architecture: Site / Fonctionnalité
➢ Gardez votre site léger, en utilisant le minimum de code
et modules.
➢ Utilisez les modules contrib à chaque fois que
c’est possible au lieu d’écrire du code spécifique.
➢ Devenez un expert des modules contrib clés, tels que
Vues et Panels.
➢ Suivez les standards Drupal pour le code personnalisé.
➢ Réévaluez votre architecture régulièrement.

18. Architecture: Site / Fonctionnalité
Erreur: Trop de rôles qui rendent la maintenance et les
contrôles de sécurité compliqués.
Exemple: Un site avec de nombreux rôles, mais la plupart
non utilisés.
Solution: Évaluer les rôles et permissions pour votre site.
Regrouper par rôles fonctionnels permet d’allouer
facilement les permissions.

19. Architecture: Site / Fonctionnalité
Erreur: Créer du code personnalisé alors qu’un module
contrib répond déjà à ce besoin.
Exemple: Un module pour créer des formulaires qui
peuvent être envoyés par mail aux administrateurs de site.
Solution: Dans ce cas, le module largement testé
Webform offre cette fonctionnalité, avec beaucoup de
flexibilité.
Assurez-vous qu’aucun module contrib ne répond pas déjà
à vos besoins.

20. Architecture: Site / Fonctionnalité
Erreur: Toucher au core ou aux modules contrib. Le
comportement deviendra imprévisible. Les mises à jour
difficiles.
Solution: Si le core ou le contrib ne répond pas
exactement à votre besoin, vous pouvez construire un
module personnalisé qui utilise des hooks.

21. Architecture: Site / Fonctionnalité
Erreur: Personnaliser du code avec les mauvais hooks.
Exemple: En utilisant hook_init, qui se charge sur chaque
page, pour un élément utilisé uniquement sur la page
d’accueil.
Solution: Planifier avec soin votre utilisation de code
personnalisé. Trouver les bons hooks et la bonne syntaxe
en utilisant la documentation http://api.drupal.
org/api/drupal.

22. Architecture: Never hack core !

23. Architecture: Never hack core !
Y a t-il des exceptions à cette règle ?
NON

24. Architecture
OUTILS

25. Architecture: Outils
Theme Developer :
www.drupal.org/project/devel_themer
En activant ce module, vous pouvez passer votre souris sur
différents emplacements de la page pour voir à quel
template correspond chaque section.

26. Architecture: Outils
Hacked! :
www.drupal.org/project/hacked
Ce module scanne les modules
et détermine s’ils ont été modifiés.
Utilisé avec le module Diff,
les résultats vous disent quelles lignes changé.
A ne surtout pas utiliser sur un sites en production !

27. Sécurités

28. Sécurités
Les bonnes pratiques en matière de sécurité
sont essentielles pour protéger votre site contre
les attaques des hackers.

29. Sécurités
Drupal intègre un haut niveau de sécurité lorsqu’il est utilisé
correctement.
Toutes les interventions visant à configurer votre site
peuvent toutefois introduire de nouveaux risques.
Il est donc important de n’accorder des autorisations de
configuration qu’aux utilisateurs de confiance.

30. Sécurités: MAJ Noyau & Modules
Vous pouvez omettre la mise à jour de certains modules
lorsque cette mise à jour n’apporte que des corrections ou
des améliorations qui n’ont pas d’effet direct sur votre site.
En revanche, il est toujours préférable d’appliquer les
mises à jour de sécurité le plus rapidement possible.

31. Sécurités: Password
Les mots de passe peuvent potentiellement créer des
brèches dans la sécurité de votre site.
Servez-vous du module Password Policy pour imposer une
série de contraintes à vos utilisateurs lors de la définition
de leurs mots de passe.
www.drupal.org/project/password_policy

32. Sécurités: Types de fichiers
Limitez les types de fichiers autorisés et réservez le droit
de chargement aux utilisateurs de confiance uniquement.
Adaptez vos autorisations en fonction des types de
contenus spécifiques et vérifiez les types de fichiers
autorisés pour le chargement de champs.

33. Sécurités
Attaques !!

34. Sécurités: Attaques !!
➢ À éviter :
○ Injection SQL
○ XSS—Cross-site scripting
○ CSRF—Cross-site request forgery

35. Sécurités: Injection SQL
Erreur: Utiliser des requêtes SQL au lieu de l’API Drupal.
Exemple:
db_query("select * from table where id=$_GET[‘id’]");
permet une attaque du type
.com/index .php?id=1 union select * from users;
Solution: Utiliser la couche d’abstraction de base de
données de Drupal.

36. Sécurités: XSS--Cross-site scripting
Erreur: L’affichage des paramètres visiteurs sans les vérifier permet d’injecter
des scripts côté client dans les pages visualisées par d’autres utilisateurs.
Exemple:
<?php echo "Your number is ". $_GET['id']; ?>
permet les attaques du type index.php?id=<script>alert("UAAAT??");
</script>
Solution: Nettoyer les entrées des utilisateurs non fiables avant tout retour au
navigateur pour rendu.
docs.acquia.com/articles/introduction-cross-site-scripting-xss-and-drupal

37. Sécurités: CSRF--Cross-site request forgery
Erreur: URL contenant des caractères génériques (%) qui ne sont pas
protégés et code de formulaire saisi directement dans le site.
Une requête HTTP Post from forms peut provenir de n’importe où, et pas
uniquement de votre site comme vous pourriez vous y attendre.
Solution: Utiliser l’API Form de Drupal, qui protège contre ces attaques en
insérant un jeton dans chaque formulaire. Lors de la restitution d’un URL censé
être protégé, assurez-vous qu’une confirmation est demandée avec l’API Form,
ou bien utilisez un jeton avec l’URL et vérifiez que ce jeton est présent et valide
au moment du traitement de la réponse.
docs.acquia.com/articles/introduction-cross-site-request-forgery

38. Performances

39. Performances
La performance est cruciale pour garantir une
expérience optimale aux visiteurs de votre site.
Si le site est lent, les fonctionnalités proposées,
même intéressantes, ne suffiront pas à
maintenir l’engagement des visiteurs.

40. Performances
La première action à entreprendre pour
améliorer la performance, c’est analyser ce que
fait le site web.
Une fois que vous avez la réponse, optimisez
le plus possible, puis implémentez la mise en
cache.

41. Performances
Outils d’Analyse

42. Performances: Outils d’Analyse
➢ Devel pour visualiser les requêtes de base de données
exécutées sur chaque page.
www.drupal.org/project/devel
➢ XhProf est généralement le meilleur outil pour
commencer. Le profilage vous permettra d’identifier
facilement les problèmes à traiter.
www.php.net/manual/en/book.xhprof.php

43. Performances: Outils d’Analyse
➢ New Relic - Analyse votre site et répertorie les requêtes
de BDD, externes et les pages spécifiques.
newrelic.com
➢ Yottaa - Se concentre sur les performances front. Ce
service permet de connaître la rapidité de chargement
de votre site à différents endroits dans le monde.
www.yottaa.com

44. Performances
Optimiser

45. Performances: Optimiser
➢ Les requêtes complexes qui prennent trop de temps et
n’utilisent pas d’index.
➢ Les fonctions qui sont appelées trop souvent.
➢ Les modules inutiles qui sont activés.
➢ Configuration incorrecte du cron.
➢ Ne pas agréger les fichiers CSS et JavaScript.

46. Performances: Optimiser
➢ Ne pas utiliser le pager Views
par défaut qui requiert une
requête COUNT additionnelle.
Préférez Views Litepager
➢ Utiliser le module Fast 404 pour servir les 404 statiques
(images, icônes, CSS, ou autres fichiers statiques) et
éviter le bootstrap de Drupal.

47. Performances: Optimiser
➢ Le module Database Logging est activé.
Les erreurs peuvent rapidement encombrer votre BDD.
Une solution courante consiste à utiliser syslog à la
place, mais cela ne fait que masquer le problème en
rendant les journaux moins accessibles.

48. Performances
Mise en cache - Les erreurs courantes

49. Performances: Cache - Les erreurs
➢ Le plus fréquemment : absence totale de
stratégie de mise en cache.
➢ Les caches sont purgés trop souvent.
➢ Mise en cache basique, avec des caches
Blocks ou Panels.

50. Performances
Ressources / Documentations

51. Performances: Ressources / Docs
➢ Conseil pratiques relatifs aux performances dans la bibliothèque d’Acquia
docs.acquia.com/cloud/performance
➢ When and how caching can save your Drupal site
www.acquia.com/fr/blog/when-and-how-caching-can-save-your-drupal-site
➢ When and how caching can save your site. Part 2: authenticated users
www.acquia.com/fr/blog/when-and-how-caching-can-save-your-site-part-2-
authenticated-users

53. Prochainement - Partie 2
➢ Infrastructure
➢ Maintenance

54. Sources
Thank You / Merci : Heather James
Manager of Learning Services - Acquia Inc.
➢ www.acquia.com/blog/5-mistakes-avoid-your-drupal-website-number-1-architecture
➢ www.acquia.com/blog/5-mistakes-avoid-your-drupal-website-number-2-security
➢ www.acquia.com/blog/5-mistakes-avoid-your-drupal-website-number-3-performance
➢ www.acquia.com/blog/5-mistakes-avoid-your-drupal-website-number-4-infrastructure
➢ www.acquia.com/blog/5-mistakes-avoid-your-drupal-website-number-5-maintenance