Comment fonctionne Drupal?
Quelqu'un pourrait-il fournir une vue d'ensemble architecturale du flux de contrôle Drupal 7? Peut-être dans le sens d'un organigramme sur la façon dont une page est générée. Quelles ressources supplémentaires suggéreriez-vous de consulter pour savoir comment Drupal fonctionne?
Drupal peut être déroutant sur ce front, en partie parce qu'il a une pile de fonctions relativement profonde. Bien que ce soit procédural PHP c'est purement événement/écouteur piloté dans son architecture, et il n'y a pas de "flux" simple dans le script principal PHP pour que vous puissiez regarder. J'ai récemment fait ne présentation sur ce même sujet , et les diapositives sont publiées sur slideshare, mais un résumé rapide de haut niveau peut être utile.
- Le fichier index.php de Drupal fonctionne comme un contrôleur frontal. Toutes les pages y sont acheminées et l'URL/chemin "réel" demandé par l'utilisateur est transmis à index.php en tant que paramètre.
- Le système de routeur de chemin de Drupal (MenuAPI) est utilisé pour faire correspondre le chemin demandé à un module d'extension donné. Ce module d'extension est responsable de la construction du "contenu principal" de la page.
- Une fois le contenu de la page principale construit, index.php appelle le thème ('page', $ content), qui transfère le contenu au système de thème/skinning de Drupal. Là, il est enveloppé dans des barres latérales/en-têtes/widgets/etc.
- La page rendue est ensuite rendue à Apache et renvoyée au navigateur de l'utilisateur.
Pendant tout ce processus, Drupal et des modules d'extension tiers déclenchent des événements et les écoutent pour répondre. Drupal appelle cela le système 'hook', et il est implémenté en utilisant les conventions de dénomination des fonctions. Le module "blog", par exemple, peut intercepter les "utilisateurs" liés en implémentant une fonction nommée blog_user (). Dans le langage Drupal, cela s'appelle hook_user () .
C'est un peu maladroit, mais en raison d'une bizarrerie PHP (il conserve une table de hachage interne de toutes les fonctions chargées), il permet à Drupal de vérifier rapidement les auditeurs simplement en itérant sur une liste de plugins installés. Pour chaque plugin, il peut appeler function_exists () sur le modèle correctement nommé, et appeler la fonction si elle existe. ("Je déclenche l'événement 'login'. La fonction 'mymodule_login' existe-t-elle? Je l'appellerai. Est-ce que 'yourmodule_login' existe? Non? Que diriez-vous de 'nextmodule_login'?" "Etc.) Encore une fois, une touche maladroite mais elle fonctionne assez bien.
Tout qui se produit dans Drupal se produit en raison du déclenchement d'un de ces événements. Le MenuAPI ne connaît que les URL/chemins gérés par les différents modules de plug-in car il déclenche l'événement "menu" (hook_menu) et rassemble tous les modules de plug-in de métadonnées qui répondent. ("Je m'occuperai de l'url 'news/recent', et voici la fonction à appeler lorsque cette page doit être construite ...") Le contenu n'est enregistré que parce que FormAPI de Drupal est responsable de la construction d'une page, et se déclenche l'événement "un formulaire a été soumis" auquel un module doit répondre. La maintenance horaire se produit car hook_cron () est déclenché, et tout module avec mymodulename_cron () comme nom de fonction verra sa fonction appelée.
Tout le reste n'est finalement que des détails - des détails importants, mais des variations sur ce thème. index.php est le contrôleur, le système de menus détermine ce qu'est la "page actuelle", et de nombreux événements sont déclenchés dans le processus de création de cette page. Les modules d'extension peuvent se connecter à ces événements et modifier le flux de travail/fournir des informations supplémentaires/etc. C'est aussi la raison pour laquelle tant de ressources Drupal se concentrent sur la création de modules. Sans modules, Drupal ne fait rien d'autre que dire: "Quelqu'un a demandé une page! Existe-t-il? Non? D'accord, je vais servir un 404. '
Pour comprendre comment Drupal fonctionne, vous devez comprendre le mécanisme de diffusion de pages de Drupal.
En bref, tous les appels/urls/demandes sont servis par index.php qui charge Drupal en incluant divers fichiers/modules d'inclusion puis en appelant la fonction appropriée, définie dans le module, pour servir la demande/url.
Voici l'extrait du livre, Pro Drupal Development, qui explique le processus bootstrap de Drupal,
Le processus Bootstrap
Drupal s'initialise à chaque demande en passant par une série de phases bootstrap. Ces phases sont définies dans bootstrap.inc et se déroulent comme décrit dans les sections suivantes.
Initialiser la configuration
Cette phase remplit le tableau de configuration interne de Drupal et établit l'URL de base ($ base_url) du site. Le fichier settings.php est analysé via include_once (), et toute substitution de variable ou de chaîne établie à cet endroit est appliquée. Voir les sections "Remplacements de variables" et "Remplacements de chaînes" du fichier sites/all/default/default.settings.php pour plus de détails.
Cache de page précoce
Dans les situations nécessitant un haut niveau d'évolutivité, un système de mise en cache peut devoir être appelé avant même qu'une connexion à la base de données ne soit tentée. La première phase du cache de page vous permet d'inclure (avec include ()) un fichier PHP contenant une fonction appelée page_cache_ fastpath (), qui prend le relais et renvoie le contenu au navigateur. Le cache de page précoce est activé en définissant la variable page_cache_fastpath sur TRUE, et le fichier à inclure est défini en définissant la variable cache_inc sur le chemin d'accès du fichier. Voir le chapitre sur la mise en cache pour un exemple.
Initialiser la base de données
Pendant la phase de base de données, le type de base de données est déterminé et une connexion initiale est établie qui sera utilisée pour les requêtes de base de données.
Nom d'hôte/contrôle d'accès basé sur IP
Drupal permet l'interdiction des hôtes par nom d'hôte/adresse IP. Dans la phase de contrôle d'accès, une vérification rapide est effectuée pour voir si la demande provient d'un hôte interdit; si c'est le cas, l'accès est refusé.
Initialiser la gestion de session
Drupal tire parti de la gestion de session intégrée de PHP mais remplace certains des gestionnaires par les siens pour implémenter la gestion de session basée sur la base de données. Les sessions sont initialisées ou rétablies dans la phase de session. L'objet global $ user représentant l'utilisateur actuel est également initialisé ici, bien que pour plus d'efficacité toutes les propriétés ne soient pas disponibles (elles sont ajoutées par un appel explicite à la fonction user_load () si nécessaire).
Cache de page tardif
Dans la phase de cache de page tardive, Drupal charge suffisamment de code de prise en charge pour déterminer s'il faut ou non diffuser une page à partir du cache de page. Cela inclut la fusion des paramètres de la base de données dans le tableau qui a été créé pendant la initialiser la phase de configuration et le chargement ou l'analyse du code du module. Si la session indique que la demande a été émise par un utilisateur anonyme et que la mise en cache des pages est activée, la page est renvoyée par le cache et l'exécution s'arrête.
Détermination de la langue
À la phase de détermination de la langue, le support multilingue de Drupal est initialisé et une décision est prise quant à la langue qui sera utilisée pour servir la page actuelle en fonction des paramètres du site et de l'utilisateur. Drupal prend en charge plusieurs alternatives pour déterminer la prise en charge de la langue, comme le préfixe de chemin et la négociation de langue au niveau du domaine.
Chemin
À la phase du chemin, le code qui gère les chemins et l'alias de chemin est chargé. Cette phase permet de résoudre les URL lisibles par l'homme et gère la mise en cache et les recherches internes du chemin Drupal).
Complet
Cette phase termine le processus bootstrap en chargeant une bibliothèque de fonctions communes, la prise en charge des thèmes et la prise en charge du mappage de rappel, de la gestion des fichiers, Unicode, PHP toolkits d'image, la création et le traitement de formulaires, la gestion du courrier, les tables triables automatiquement et la pagination du jeu de résultats. Le gestionnaire d'erreur personnalisé de Drupal est défini et tous les modules activés sont chargés. Enfin, Drupal déclenche le crochet init, afin que les modules ont la possibilité d'être notifiés avant le début du traitement officiel de la demande.
Une fois que Drupal a terminé le bootstrap, tous les composants du framework sont disponibles. Il est temps de prendre la demande du navigateur et de la transmettre à la fonction PHP PHP qui Le mappage entre les URL et les fonctions qui les gèrent est réalisé à l'aide d'un registre de rappel qui prend en charge à la fois le mappage d'URL et le contrôle d'accès. Les modules enregistrent leurs rappels à l'aide du crochet de menu (pour plus de détails, voir le chapitre 4).
Lorsque Drupal a déterminé qu'il existe un rappel auquel l'URL de la demande de navigateur mappe avec succès et que l'utilisateur est autorisé à accéder à ce rappel, le contrôle est transféré à la fonction de rappel.
Traitement d'une demande
La fonction de rappel fait tout le travail nécessaire pour traiter et accumuler les données nécessaires pour répondre à la demande. Par exemple, si une demande de contenu telle que http://example.com/ q = node/3 est reçue, l'URL est mappée à la fonction node_page_view () dans node.module. Un traitement ultérieur récupérera les données de ce nœud dans la base de données et les placera dans une structure de données. Ensuite, c'est le moment de la thématisation.
Thématisation des données
Thématiser implique de transformer les données qui ont été récupérées, manipulées ou créées en HTML (ou XML ou autre format de sortie). Drupal utilisera le thème que l'administrateur a sélectionné pour donner à la page Web l'apparence correcte. La sortie résultante est ensuite envoyée au navigateur Web (ou à un autre client HTTP).
La réponse d'Eaton donne un bon aperçu. (Je suis nouveau ici, donc je ne peux pas le modifier, donc le commentaire.)
Le moment brutal "aha" pour moi a été de réaliser que tout se passe via index.php, puis à travers la cascade de modules (cœur d'abord, puis par site). Pour étendre la fonctionnalité de base, ne la réécrivez pas. Au lieu de cela, copiez le module dans/sites/all/modules/ou/sites/[votre site]/modules et étendez-le, ou créez un nouveau module à ces endroits. Idem pour les thèmes. Les répertoires de modules peuvent également contenir du code d'affichage, sous la forme de tpl, css, etc.
Si vous êtes habitué à des frameworks de type MVC plus stricts comme Rails, Django etc. tout cela devient un peu déroutant. Les modules peuvent mélanger beaucoup de code d'affichage, et si vous regardez quelqu'un les modules ou les modèles des autres que vous finirez par remonter dans la pile. C'est la beauté/la peine de travailler en PHP.
Ironiquement, "il suffit de créer une application" pourrait être la pire façon d'apprendre cela. Drupal fait tellement de choses qui sont tout simplement obscures jusqu'à ce que vous compreniez le flux de contrôle. Il n'y a rien dans un fichier tpl qui vous indique où une fonction avec un nom amusant comme l() vient, par exemple.
Lisez les manuels, en particulier le guide du développeur de thème. Drupal prend en charge plusieurs moteurs de thème. Zen utilise phptemplate, alors faites attention à cette partie du guide.
Pour le développement de modules, l'API est documentée sur api.drupal.org.
spécialement lorsque vous avez besoin d'obtenir des informations rapidement et rapidement http://www-128.ibm.com/developerworks/ibm/osource/implement.html
Cela dépend de la profondeur de compréhension que vous recherchez; si vous avez une bonne connaissance de php, je vous suggère de lire le code lui-même, en commençant par index.php, puis en passant par le fichier includes/bootstrap.inc, puis certains des autres scripts de ce répertoire.
Les fichiers clés incluent:
- menu.inc est très important pour comprendre le fonctionnement du système global, car il gère une grande partie du mappage implicite des URL au contenu.
- common.inc possède la plupart des fonctions par ailleurs mystérieuses qui constituent la base de l'API.
- module.inc gère les appels de hook mentionnés par Eaton
- form.inc s'occupe de l'affichage, de la soumission et du traitement des formulaires
- theme.inc gère la présentation.
Il y a aussi quelques fonctionnalités clés dans le répertoire modules /; en particulier, modules/node/node.module constitue la base du système de nœuds, qui est en général ce qui est utilisé pour encapsuler le contenu du site.
Le code est, en général, très bien commenté et clair. L'utilisation du balisage Doxygen dans les commentaires signifie que le code est effectivement la documentation canonique.
Cela permet également de le faire à l'aide d'un éditeur qui peut rapidement accéder à la définition d'une fonction. L'utilisation de vim en combinaison avec ctags fonctionne pour moi; vous devez dire à ctags d'indexer les fichiers .inc, .module, etc. en tant que fichiers php.
J'ai appris des charges en important le code drupal .php dans un projet NetBeans. Vous pouvez ensuite exécuter le débogueur netbeans et regarder les différentes phases de la page se réunir.
Les meilleurs livres sur le sujet sont "Pro Drupal Development" et "Using Drupal."
"Pro Drupal Development" comprend plusieurs organigrammes Nice et des résumés approfondis de chacune des API de Drupal (formulaires, thèmes, etc.). Il est destiné à être particulièrement instructif pour les personnes qui créent leurs propres modules et thèmes, mais a beaucoup de valeur pour le développeur PHP-savvy moyen qui veut comprendre Drupal. En plus de cela, j'ai créé un module personnalisé pour chaque site que j'ai construit, juste pour gagner le contrôle supplémentaire sur des choses comme cacher sélectivement des champs sur divers formulaires (ce que vous voulez généralement faire pour simplifier les formulaires de nœuds pour les utilisateurs finaux), il est donc bon d'avoir cette connaissance sous votre chapeau.
"Utiliser Drupal" est destiné au développeur de site qui veut savoir comment créer les bonnes choses comme les galeries, les blogs et les sites de réseaux sociaux. Il passe par plusieurs cas d'utilisation et montre comment configurer les modules existants pour effectuer chaque tâche. Dans le processus, il vous familiarise avec les modules complémentaires essentiels "Content Construction Kit" (CCK) et "Views", comment créer des blocs et des modèles personnalisés, et les tenants et aboutissants de la maintenance d'un Drupal site. Je recommande ce livre spécialement pour ceux qui veulent se mettre à jour et réellement UTILISER Drupal tout de suite. Dans le processus, vous comprenez l'organisation interne de Drupal.
This (for Drupal 6) & this (for Drupal 7) est une assez bonne architecture aperçu de drupal. Si vous voulez plus de détails alors je commencerais à écrire quelque chose la plupart de la documentation est bonne. Essayer de l'apprendre à un niveau de détail élevé sans quelque chose de concret à réaliser sera beaucoup plus difficile que d'essayer quelque chose.
Nouveau contributeur ici, 2 ans de retard sur la conversation ;-)
En réponse à https://stackoverflow.com/a/1070325/1154755
Pour étendre la fonctionnalité de base, ne la réécrivez pas. À la place, copiez le module dans/sites/all/modules/ou/sites/ [votre site] /modules et étendez-le, ou créez un nouveau module dans ceux-ci des endroits. Idem pour les thèmes.
En fait, je n'ai jamais eu à copier un module principal pour le mettre à jour. Drupal Les crochets devraient être tout ce dont vous avez besoin.
Pour les thèmes, oui, parfois c'est la seule façon de procéder, mais souvent, vous pouvez créer un sous-thème pour obtenir le résultat dont vous avez besoin.