Anúncio
Anúncio

Mais conteúdo relacionado

Anúncio

Similar a Drupal7 - Bonnes Pratiques (Partie 1)(20)

Anúncio

Drupal7 - Bonnes Pratiques (Partie 1)

  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
  52. Prochainement - Partie 2 ➢ Infrastructure ➢ Maintenance
  53. 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
Anúncio