Comment fonctionne Drupal?

Question

Est-ce que quelqu'un pourrait fournir un aperçu architectural du flux de contrôle de Drupal 7 ? Peut-être sous la forme d'un organigramme sur la façon dont une page est générée. Quelles ressources supplémentaires suggéreriez-vous de consulter concernant le fonctionnement de Drupal ?

Answer 1

Drupal peut être déroutant à ce sujet, en partie parce qu'il a une pile de fonctions relativement profonde. Bien que ce soit du PHP procédural, son architecture est purement basée sur des événements/écouteurs, et il n'y a pas de "flux" simple dans le script PHP principal que vous pouvez parcourir. J'ai récemment fait une présentation sur ce sujet très précis, 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 de devanture. Toutes les pages y passent, et l'URL/chemin "réel" demandé par l'utilisateur est passé à index.php en tant que paramètre.
• Le système de routage des chemins de Drupal (MenuAPI) est utilisé pour faire correspondre le chemin demandé à un module plugin donné. Ce module plugin est responsable de la construction du "contenu principal" de la page.
• Une fois que le contenu principal de la page est construit, index.php appelle theme('page', $content), qui transmet le contenu au système de thématisation/de mise en forme de Drupal. Là, il est enveloppé dans des 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 plugin tiers lancent des événements et écoutent pour y répondre. Drupal appelle cela le système de 'hook', et il est mis en œuvre en utilisant des conventions de nommage de fonctions. Le module 'blog', par exemple, peut intercepter les événements liés aux 'utilisateurs' en implémentant une fonction nommée blog_user(). Dans le jargon de Drupal, c'est appelé hook_user().

C'est un peu maladroit, mais en raison d'une particularité de PHP (il conserve une table de hachage interne de toutes les fonctions chargées), cela permet à Drupal de vérifier rapidement les écouteurs en itérant simplement sur une liste de modules plugins installés. Pour chaque module, il peut appeler function_exists() sur le modèle de nom correctement nommé, et appeler la fonction si elle existe. ("Je déclenche l'événement 'connexion'. La fonction 'mymodule_login' existe-t-elle? Je vais l'appeler. 'yourmodule_login' existe-t-elle? Non? Et 'nextmodule_login' ?" etc.) Encore une fois, un peu maladroit mais ça fonctionne plutôt bien.

Tout ce qui se passe dans Drupal se produit parce qu'un de ces événements est déclenché. Le MenuAPI ne sait que les URLs/chemins sont gérés par différents modules plugins parce qu'il déclenche l'événement 'menu' (hook_menu) et rassemble toutes les métadonnées auxquelles les modules plugins 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 le FormAPI de Drupal est responsable de la construction d'une page, et déclenche l'événement 'un formulaire a été soumis' pour qu'un module y réponde. La maintenance horaire se produit parce que hook_cron() est déclenché, et tout module avec mymodulename_cron() en tant que nom de fonction aura sa fonction appelée.

Tout le reste ne sont 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 menu détermine quelle est la "page actuelle", et de nombreux événements sont déclenchés dans le processus de construction de cette page. Les modules plugins peuvent se connecter à ces événements et changer le flux de travail/fournir des informations supplémentaires/etc. C'est aussi une partie des raisons pour lesquelles tant de ressources Drupal se concentrent sur la création de modules. Sans les modules, Drupal ne fait pas réellement grand-chose, à part dire : 'Quelqu'un a demandé une page! Existe-t-elle? Non? D'accord, je vais servir une erreur 404.'

Answer 2

Pour comprendre comment Drupal fonctionne, vous devez comprendre le mécanisme de distribution des pages de Drupal.

En bref, tous les appels/URL/demandes sont servis par index.php, qui charge Drupal en incluant divers fichiers/modules, puis en appelant la fonction appropriée, définie dans le module, pour servir la demande/l'URL.

Voici un extrait du livre Pro Drupal Development, qui explique le processus d'amorçage de Drupal,

Le Processus d'Amorçage

Drupal s'amorce sur 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 substitution de chaîne établie est appliquée. Voir les sections "Substitutions de Variables" et "Substitutions 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 de scalabilité, un système de mise en cache peut être appelé avant même qu'une connexion à la base de données ne soit tentée. La phase de cache de page précoce 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. Consultez 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 à la base de données.

Contrôle d'Accès Basé sur le Nom d'Hôte/IP

Drupal permet d'interdire des hôtes sur une base de 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 utilise la gestion de sessions intégrée de PHP, mais remplace certains des gestionnaires par les siens pour mettre en œuvre une gestion de session sauvegardée par 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 par souci d'efficacité toutes les propriétés ne soient pas disponibles (elles sont ajoutées par un appel explicite à la fonction user_load() au besoin).

Cache de Page Tardive

Dans la phase de cache de page tardive, Drupal charge suffisamment de code de support pour déterminer si oui 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 le cache de pages est activé, la page est renvoyée depuis 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 sur la langue à utiliser 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 le support de la langue, telles que le préfixe de chemin et la négociation de langue au niveau du domaine.

Chemin

Dans la phase du chemin, le code qui gère les chemins et les alias de chemin est chargé. Cette phase permet la résolution des URL lisibles par l'homme et gère la mise en cache et les recherches internes des chemins Drupal.

Complet

Cette phase termine le processus d'amorçage en chargeant une bibliothèque de fonctions communes, le support de thèmes, et le support pour le mappage de rappel, la gestion de fichiers, Unicode, les outils d'image PHP, la création et le traitement de formulaires, la gestion des emails, les tableaux automatiquement triables, et la pagination des jeux 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 crochet d'initialisation, de sorte que les modules ont la possibilité d'être notifiés avant le traitement officiel de la demande ne commence.

Une fois que Drupal a terminé d'amorcer, 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ère. La correspondance entre les URL et les fonctions qui les gèrent est réalisée en utilisant un registre de rappels qui gère à la fois l'association 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 demande du navigateur est associée avec succès et que l'utilisateur a l'autorisation d'accéder à ce rappel, le contrôle est remis à 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 satisfaire la demande. Par exemple, si une demande de contenu tel que http://example.com/ q=node/3 est reçue, l'URL est associée à la fonction node_page_view() dans node.module. Plus de traitement récupérera les données pour ce nœud dans la base de données et les mettra dans une structure de données. Ensuite, c'est le moment du thème.

Thématisation des Données

La thématisation consiste à 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 sélectionné par l'administrateur pour donner à la page web le bon look and feel. La sortie résultante est ensuite envoyée au navigateur web (ou autre client HTTP).

Answer 3

La réponse d'Eaton donne un bon aperçu. (Je suis nouveau ici donc je ne peux pas le modérer, d'où le commentaire.)

Le moment "aha" brutal pour moi a été de réaliser que tout se passe à travers index.php, puis à travers la cascade de modules (d'abord le noyau, 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/[votresite]/modules et étendez CELA, ou créez un nouveau module à ces endroits. Il en va de même pour les thèmes. Les répertoires des modules peuvent également contenir du code d'affichage, sous 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 confus. Les modules peuvent mélanger beaucoup de code d'affichage, et si vous regardez les modules ou les templates de quelqu'un d'autre, vous finirez par remonter à travers la pile. C'est la beauté / la douleur de travailler en PHP.

Ironiquement, "simplement construire une application" pourrait être la pire façon d'apprendre cela. Drupal fait tellement de choses prêtes à l'emploi 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 dit d'où vient une fonction avec un nom amusant comme l(), par exemple.

Answer 4

http://drupal.org/handbooks

Lisez les manuels, en particulier le guide du développeur de thèmes. Drupal supporte plusieurs moteurs de thèmes. Zen utilise phptemplate, donc faites attention à cette partie du guide.

Pour le développement de modules, l'API est documentée sur api.drupal.org.

surtout lorsque vous avez besoin d'obtenir les informations rapidement et rapidement http://www-128.ibm.com/developerworks/ibm/osource/implement.html

Answer 5

Ceci (pour Drupal 6) & cela (pour Drupal 7) est une assez bonne vue d'ensemble architecturale 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 en détail sans avoir quelque chose de concret à réaliser sera beaucoup plus difficile que d'essayer quelque chose.