drupal7 - bonnes pratiques (partie 1)

54
Drupal Bonnes Pratiques

Upload: alexandre-marie

Post on 18-Dec-2014

227 views

Category:

Internet


2 download

DESCRIPTION

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

TRANSCRIPT

Page 1: Drupal7 - Bonnes Pratiques (Partie 1)

Drupal

Bonnes Pratiques

Page 2: Drupal7 - Bonnes Pratiques (Partie 1)

Bonnes pratiques - Partie 1

➢ Architecture

➢ Sécurités

➢ Performances

Page 3: Drupal7 - Bonnes Pratiques (Partie 1)

Architecture

Page 4: Drupal7 - Bonnes Pratiques (Partie 1)

Architecture

➢ Structurer votre contenu

➢ Configurer l’affichage

➢ Organiser les fonctionnalités

Page 5: Drupal7 - Bonnes Pratiques (Partie 1)

Architecture

CONTENU

Page 6: Drupal7 - Bonnes Pratiques (Partie 1)

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.

Page 7: Drupal7 - Bonnes Pratiques (Partie 1)

Architecture: Contenu

➢ Planifier vos structures :

○ Champs

○ Types de contenus

○ Vues

○ ...

Page 8: Drupal7 - Bonnes Pratiques (Partie 1)

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.

Page 9: Drupal7 - Bonnes Pratiques (Partie 1)

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 del’enseignant.

Solution: Réutiliser et standardiser les champs.

Page 10: Drupal7 - Bonnes Pratiques (Partie 1)

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.

Page 11: Drupal7 - Bonnes Pratiques (Partie 1)

Architecture

Affichage

Page 12: Drupal7 - Bonnes Pratiques (Partie 1)

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.

Page 13: Drupal7 - Bonnes Pratiques (Partie 1)

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 architectured’affichage.

Page 14: Drupal7 - Bonnes Pratiques (Partie 1)

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.

Page 15: Drupal7 - Bonnes Pratiques (Partie 1)

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.

Page 16: Drupal7 - Bonnes Pratiques (Partie 1)

Architecture

Site / Fonctionnalité

Page 17: Drupal7 - Bonnes Pratiques (Partie 1)

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.

Page 18: Drupal7 - Bonnes Pratiques (Partie 1)

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.

Page 19: Drupal7 - Bonnes Pratiques (Partie 1)

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.

Page 20: Drupal7 - Bonnes Pratiques (Partie 1)

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.

Page 21: Drupal7 - Bonnes Pratiques (Partie 1)

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 paged’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.

Page 22: Drupal7 - Bonnes Pratiques (Partie 1)

Architecture: Never hack core !

Page 23: Drupal7 - Bonnes Pratiques (Partie 1)

Architecture: Never hack core !

Y a t-il des exceptions à cette règle ?

NON

Page 24: Drupal7 - Bonnes Pratiques (Partie 1)

Architecture

OUTILS

Page 25: Drupal7 - Bonnes Pratiques (Partie 1)

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.

Page 26: Drupal7 - Bonnes Pratiques (Partie 1)

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 !

Page 27: Drupal7 - Bonnes Pratiques (Partie 1)

Sécurités

Page 28: Drupal7 - Bonnes Pratiques (Partie 1)

Sécurités

Les bonnes pratiques en matière de sécurité sont essentielles pour protéger votre site contre

les attaques des hackers.

Page 29: Drupal7 - Bonnes Pratiques (Partie 1)

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.

Page 30: Drupal7 - Bonnes Pratiques (Partie 1)

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.

Page 31: Drupal7 - Bonnes Pratiques (Partie 1)

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

Page 32: Drupal7 - Bonnes Pratiques (Partie 1)

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.

Page 33: Drupal7 - Bonnes Pratiques (Partie 1)

Sécurités

Attaques !!

Page 34: Drupal7 - Bonnes Pratiques (Partie 1)

Sécurités: Attaques !!

➢ À éviter :

○ Injection SQL

○ XSS—Cross-site scripting

○ CSRF—Cross-site request forgery

Page 35: Drupal7 - Bonnes Pratiques (Partie 1)

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.

Page 36: Drupal7 - Bonnes Pratiques (Partie 1)

Sécurités: XSS--Cross-site scriptingErreur: 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

Page 37: Drupal7 - Bonnes Pratiques (Partie 1)

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

Page 38: Drupal7 - Bonnes Pratiques (Partie 1)

Performances

Page 39: Drupal7 - Bonnes Pratiques (Partie 1)

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.

Page 40: Drupal7 - Bonnes Pratiques (Partie 1)

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.

Page 41: Drupal7 - Bonnes Pratiques (Partie 1)

Performances

Outils d’Analyse

Page 42: Drupal7 - Bonnes Pratiques (Partie 1)

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

Page 43: Drupal7 - Bonnes Pratiques (Partie 1)

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

Page 44: Drupal7 - Bonnes Pratiques (Partie 1)

Performances

Optimiser

Page 45: Drupal7 - Bonnes Pratiques (Partie 1)

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.

Page 46: Drupal7 - Bonnes Pratiques (Partie 1)

Performances: Optimiser

➢ Ne pas utiliser le pager Views par défaut qui requiert unerequê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.

Page 47: Drupal7 - Bonnes Pratiques (Partie 1)

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.

Page 48: Drupal7 - Bonnes Pratiques (Partie 1)

Performances

Mise en cache - Les erreurs courantes

Page 49: Drupal7 - Bonnes Pratiques (Partie 1)

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.

Page 50: Drupal7 - Bonnes Pratiques (Partie 1)

Performances

Ressources / Documentations

Page 51: Drupal7 - Bonnes Pratiques (Partie 1)

Performances: Ressources / Docs

➢ Conseil pratiques relatifs aux performances dans la bibliothèque d’Acquiadocs.acquia.com/cloud/performance

➢ When and how caching can save your Drupal sitewww.acquia.com/fr/blog/when-and-how-caching-can-save-your-drupal-site

➢ When and how caching can save your site. Part 2: authenticated userswww.acquia.com/fr/blog/when-and-how-caching-can-save-your-site-part-2-authenticated-users

Page 52: Drupal7 - Bonnes Pratiques (Partie 1)
Page 53: Drupal7 - Bonnes Pratiques (Partie 1)

Prochainement - Partie 2

➢ Infrastructure

➢ Maintenance