Comment fonctionne Drupal? [fermé]

Quelqu'un pourrait-il fournir un aperçu architectural 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 sur le fonctionnement de Drupal?

Drupal peut être déroutant sur ce front, en partie parce qu'il a une pile de fonctions relativement profonde. Bien que ce soit du PHP procédural, il est purement piloté par les événements / écouteurs dans son architecture, et il n'y a pas de "flux" simple dans le script PHP principal que vous puissiez regarder. J'ai récemment fait une présentation sur ce sujet même , et les diapositives sont publiées sur slideshare, mais un rapide résumé 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 passé à 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 de plugin 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 theme ('page', $ content), qui transmet le contenu au système de thème / skinning de Drupal. Là, il est enveloppé dans les barres latérales / en-têtes / widgets / etc.
• La page rendue est ensuite renvoyée à apache et renvoyée au navigateur de l'utilisateur.

Pendant tout ce processus, Drupal et les modules de plugins tiers déclenchent des événements et écoutent leur réponse. 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 'user' associé 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), cela permet à Drupal de vérifier rapidement les écouteurs 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 vais l'appeler. Est-ce que 'yourmodule_login' existe? Non? Que diriez-vous de 'nextmodule_login'?" Etc.) Encore une fois, un peu maladroit mais ça fonctionne plutôt bien.

Tout ce qui se passe dans Drupal se produit à cause de l'un de ces événements. Le MenuAPI ne sait quelles URL / chemins sont gérés par les différents modules de plugin car il déclenche l'événement 'menu' (hook_menu) et rassemble tous les modules de plugin de métadonnées avec lesquels ils répondent. ("Je vais m'occuper 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 création 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 parce que hook_cron () est déclenché, et tout module avec mymodulename_cron () comme nom de fonction aura 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 courante" et de nombreux événements sont déclenchés lors du processus de construction 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 en partie 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 de dire: «Quelqu'un a demandé une page! Existe-t-il? Non? OK, je vais servir un 404. '

Pour comprendre le fonctionnement de Drupal, vous devez comprendre le mécanisme de diffusion de pages de Drupal.

En bref, tous les appels / urls / requêtes 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 requête / l'url.

Voici l'extrait du livre, Pro Drupal Development, qui explique le processus de bootstrap de Drupal,

Le processus Bootstrap

Drupal s'amorce à chaque demande en passant par une série de phases d'amorçage. 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 variable ou chaîne de remplacement qui y est établie 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 à une base de données ne soit tentée. La première phase de 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 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.

Contrôle d'accès basé sur le nom d'hôte / IP

Drupal autorise le bannissement des hôtes sur une base 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 banni; si tel 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 le sien 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

À la fin de la phase de cache de page, Drupal charge suffisamment de code de support pour déterminer s'il faut ou non servir une page à partir du cache de page. Cela inclut la fusion des paramètres de la base de données dans le tableau créé lors de la phase d'initialisation de la 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 de page est activée, la page est renvoyée à partir du cache et l'exécution s'arrête.

Détermination de la langue

Lors de 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, telles que le préfixe de chemin et la négociation de langue au niveau du domaine.

Chemin

Lors de la phase de 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 de chemin Drupal internes.

Plein

Cette phase complète le processus d'amorçage 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, de l'Unicode, des boîtes à outils d'image PHP, de la création et du traitement de formulaires, de la gestion du courrier, des tables triables automatiquement et de la pagination de l'ensemble de résultats. Le gestionnaire d'erreurs personnalisé de Drupal est défini et tous les modules activés sont chargés. Enfin, Drupal déclenche le hook init, afin que les modules aient la possibilité d'être notifiés avant le début du traitement officiel de la requête.

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 qui la gérera. 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 en utilisant le 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 requête du navigateur mappe avec succès et que l'utilisateur a l'autorisation d'accéder à ce rappel, le contrôle est transféré à la fonction de rappel.

Traitement d'une demande

La fonction de rappel effectue 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 tel 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 de la base de données et les placera dans une structure de données. Ensuite, il est temps de thématiser.

Thématiser les données

La thématisation implique la transformation des données 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'aspect et la convivialité corrects. La sortie résultante est ensuite envoyée au navigateur Web (ou à un autre client HTTP).

La réponse d'Eaton offre 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 (noyau d'abord, puis par site). Pour étendre les fonctionnalités de base, ne le réécrivez pas. Copiez plutôt le module dans / sites / all / modules / ou / sites / [yoursite] / modules et étendez CELA, 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 les modules ou les modèles de quelqu'un d'autre, vous finirez par revenir en arrière dans la pile. C'est la beauté / la douleur de travailler en PHP.

Ironiquement, «simplement créer une application» pourrait être la pire façon d'apprendre cela. Drupal fait tellement de choses hors de la boîte qui sont simplement obscures jusqu'à ce que vous compreniez le flux de contrôle. Il n'y a rien dans un fichier tpl qui vous indique d'où vient une fonction avec un nom amusant comme l (), par exemple.

Cela dépend de la profondeur de la 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 à includes / bootstrap.inc, puis à certains des autres scripts de ce répertoire.

La clé comprend des fichiers:

• menu.inc est très important pour comprendre le fonctionnement de l'ensemble du système, car il gère une grande partie du mappage implicite des URL au contenu.
• common.inc a la plupart des fonctions autrement mystérieuses qui forment 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 des fonctionnalités clés dans le répertoire modules /; en particulier, modules / node / node.module forme 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 aide également à le faire en utilisant un éditeur qui peut rapidement passer à la définition d'une fonction. Utiliser vim en combinaison avec ctags fonctionne pour moi; vous devez indiquer à ctags d'indexer les fichiers .inc, .module, etc. en tant que fichiers php.

J'ai appris des tas de choses 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 rassembler.

Les meilleurs livres sur le sujet sont "Pro Drupal Development" et "Using Drupal".

"Pro Drupal Development" comprend plusieurs organigrammes sympas et des résumés détaillés 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 moyen averti en PHP qui veut comprendre Drupal. En outre, j'ai créé un module personnalisé pour chaque site que j'ai construit, juste pour obtenir un contrôle supplémentaire sur des choses comme le masquage sélectif des champs sur divers formulaires (ce que vous voulez généralement faire dans le but de simplifier les formulaires de nœuds pour la fin- utilisateurs), il est donc bon d'avoir ces connaissances sous votre chapeau.

"Utilisation de Drupal" s'adresse au développeur de site qui souhaite savoir comment créer des éléments intéressants tels que des galeries, des blogs et des sites de réseaux sociaux. Il passe par plusieurs cas d'utilisation et montre comment configurer les modules existants pour faire chaque travail. Au cours du 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 site Drupal. Je recommande ce livre en particulier à ceux qui veulent se mettre à jour et utiliser Drupal tout de suite. Dans le processus, vous acquérez une compréhension de l'organisation interne de Drupal.

Ceci (pour Drupal 6) et ceci (pour Drupal 7) est un très bon aperçu architectural de Drupal. Si vous voulez plus de détails, je commencerais à écrire quelque chose que 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 les fonctionnalités de base, ne le réécrivez pas. Copiez plutôt le module dans / sites / all / modules / ou / sites / [yoursite] / modules et étendez CELA, ou créez un nouveau module à ces endroits. Idem pour les thèmes.

En fait, je n'ai jamais eu à copier un module principal pour le mettre à jour. Drupal Hooks devrait être tout ce dont vous avez besoin.

Pour les thèmes, oui, c'est parfois 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.