cTools est l’un de ces modules critiques de Drupal 7 dont beaucoup d’autres dépendent. Il fournit de nombreuses API et fonctionnalités qui facilitent la vie lors du développement de modules. Les vues et les panneaux ne sont que deux exemples de ces puissances qui en dépendent.
cTools met à disposition différents types de fonctionnalités. La mise en cache d’objets, l’exportabilité de la configuration, les assistants de formulaire, les boîtes de dialogue et les plugins ne sont que quelques-uns. Une grande partie du crédit que vous attribuez normalement aux vues ou aux panneaux est en réalité due à cTools.
Dans cet article, nous allons jeter un œil aux plugins cTools, en particulier comment nous pouvons créer les nôtres. Après une brève introduction, nous allons immédiatement passer à un module personnalisé qui utilisera les plugins cTools pour rendre la définition des blocs Drupal plus agréable (plus en phase avec la façon dont nous les définissons dans Drupal 8).
Introduction
Les plugins cTools de Drupal 7 (conceptuellement pas si différents du système de plugins de Drupal 8) sont destinés à définir facilement des fonctionnalités réutilisables. C’est-à-dire pour la capacité de définir une logique métier isolée qui est utilisée dans un certain contexte. L’objectif est de configurer ce contexte et ce type de plug-in une seule fois, et de permettre aux autres modules de définir ensuite automatiquement les plug-ins pouvant être utilisés dans ce contexte.
Si vous développez des sites Drupal depuis plus d’un an, vous avez probablement rencontré des plugins cTools sous une forme ou une forme. Je pense que le premier type de plugin que nous traitons habituellement est le plugin content_type qui nous permet de créer nos propres volets de panneau personnalisés qui affichent du contenu dynamique. Et c’est génial. Certains des autres que vous avez pu rencontrer dans le même domaine de Panels sont probablement le contexte et l’accès (règles de visibilité). Peut-être même des relations et des disputes. Ceux-ci sont tous fournis par cTools. Les panneaux s’ajoutent à cette liste en introduisant des dispositions et des styles que nous utilisons normalement pour créer des dispositions de panneaux et des styles de volets individuels. Ce sont je pense les plus courants.
Cependant, tout ce qui précède est dans une certaine mesure une boîte noire pour beaucoup. Tout ce que nous savons, c’est que nous devons définir un crochet pour spécifier un répertoire, puis fournir un fichier d’inclusion avec une définition et un code logique et le reste se produit par magie. À l’avenir, j’aimerais que nous examinions comment un type de plug-in est défini afin que, le cas échéant, nous puissions créer nos propres plug-ins pour représenter des fonctionnalités réutilisables. Pour le démontrer, nous allons créer un module qui transforme le système de crochet embêtant de définition de blocs Drupal personnalisés en une approche basée sur un plugin similaire à celle utilisée par Drupal 8.
Le code final (+ un peu plus) peut être trouvé dans ce référentiel si vous souhaitez suivre. Et je m’attends à ce que vous connaissiez les étapes nécessaires à la définition de blocs Drupal personnalisés.
Le module block_plugin
Comme je l’ai mentionné, je voudrais illustrer la puissance des plugins cTools avec un type de plugin personnalisé qui rend la définition des blocs Drupal 7 plus saine. Au lieu d’implémenter les 2 crochets principaux (hook_block_info() et hook_block_view()) nécessaires pour définir un bloc, nous pourrons avoir des fichiers de plugin séparés chacun responsable de toute la logique liée à son propre bloc. Plus besoin de changer de cas et de changer l’implémentation du hook à chaque fois que nous avons besoin d’un nouveau bloc. Alors, comment faisons-nous cela?
Tout d’abord, créons notre fichier block_plugin.info pour commencer avec notre module :
Nom = Bloquer Brancher
la description = Utilisant Plugins cTools à définir Drupal le noyau bloque le noyau = 7.x
dépendances[] = outils
Assez simple.
Le type de plugin
Afin de définir notre type de plugin d’actualités, dans le fichier block_plugin.module, nous devons implémenter hook_ctools_plugin_type() qui est responsable de la définition de nouveaux types de plugins que cTools reconnaîtra :
fonction block_plugin_ctools_plugin_type() {
revenir déployer(
‘bloquer’ => déployer(
‘étiquette’ => ‘Bloquer’,
‘utiliser des crochets’ => FAUX,
‘traiter’ => ‘block_plugin_process_plugin’
)
);
}
Dans ce crochet, nous devons renvoyer un tableau associatif de toutes les définitions de type de plug-in dont nous avons besoin, codées par le nom de la machine du nom du type de plug-in. Aujourd’hui, nous ne créons qu’un seul bloc appelé. Pour plus d’informations sur toutes les options disponibles ici, n’hésitez pas à consulter le fichier d’aide plugins-creating.html dans le module cTools. Inutile de répéter toutes ces informations ici.
La clé de processus définit un nom de fonction qui se déclenche chaque fois que cTools charge pour nous un plugin et est responsable de la mise en forme ou du massage des données du plugin avant de l’utiliser. C’est une sorte de fonction d’assistance qui prépare le plugin pour nous à chaque fois afin que nous n’ayons pas à nous en soucier. Voyons donc ce que nous pouvons faire à l’intérieur de cette fonction :
fonction block_plugin_process_plugin(&$ plugin, $info) {
// Ajouter un titre d’administrateur de bloc
si (!isset($ plugin[‘admin title’])) {
$ éclaté = exploser(‘_’, $ plugin[‘name’]);
$nom = »;
pour chaque ($ éclaté comme $partie) {
$nom .= ucfirst($partie) . ‘ ‘;
}
$ plugin[‘admin title’] = $nom;
}
// Par défaut, nous affichons également un titre de bloc, mais celui-ci peut être écrasé
si (!isset($ plugin[‘show title’])) {
$ plugin[‘show title’] = vrai;
}
// Ajout d’une fonction de vue de bloc
si (!isset($ plugin[‘view’])) {
$ plugin[‘view’] = $ plugin[‘module’] . ‘_’ . $ plugin[‘name’] . ‘_voir’;
}
// Ajout d’une fonction de formulaire de bloc
si (!isset($ plugin[‘configure’])) {
$ plugin[‘configure’] = $ plugin[‘module’] . ‘_’ . $ plugin[‘name’] . ‘_configure’;
}
// Ajout d’une fonction de sauvegarde de bloc
si (!isset($ plugin[‘save’])) {
$ plugin[‘save’] = $ plugin[‘module’] . ‘_’ . $ plugin[‘name’] . ‘_enregistrer’;
}
}
Ce rappel reçoit le tableau de plug-in comme référence et des informations sur le type de plug-in. La tâche à accomplir consiste à modifier ou à ajouter dynamiquement des données au plugin. Alors, qu’est-ce que nous réalisons ci-dessus?
Tout d’abord, si le développeur n’a pas défini de titre d’administrateur pour le plugin de bloc, nous en générons un automatiquement en fonction du nom de machine du plugin. C’est ainsi que nous avons toujours un titre d’administrateur dans l’interface du bloc Drupal.
Deuxièmement, nous choisissons de toujours afficher le titre du bloc afin de marquer la clé de titre d’affichage du tableau de plug-in comme TRUE. Lors de la définition du plugin de bloc, le développeur a la possibilité de le définir sur FALSE, auquel cas nous n’afficherons pas de titre de bloc (sujet).
Troisième, quatrième et cinquième, nous générons une fonction de rappel pour la vue de bloc, enregistrons et configurons les actions (si elles n’ont pas déjà été définies par le développeur pour un plugin donné). Ces rappels seront utilisés lors de l’implémentation de hook_block_view(), hook_block_configure() et hook_block_save(), respectivement. Nous ne couvrirons pas les deux derniers dans cet article, mais n’hésitez pas à consulter le référentiel pour voir à quoi ils peuvent ressembler.
Et c’est à peu près tout ce dont nous avons besoin pour définir notre type de plugin personnalisé. Cependant, nous devrions également implémenter hook_ctools_plugin_directory() qui, comme vous le savez peut-être, est responsable de dire à cTools où un plugin d’un certain type peut être trouvé dans le module actuel :
fonction block_plugin_ctools_plugin_directory($module, $ plugin) {
si ($module == ‘block_plugin’ && in_array($ plugin, array_keys(block_plugin_ctools_plugin_type())) ) {
revenir ‘plugins/’ . $ plugin;
}
}
Cela devra également être implémenté par tout autre module qui souhaite définir des plugins de blocs.
Blocs Drupal
Maintenant que nous avons le type de plugin, écrivons le code qui transforme n’importe quel plugin de bloc défini en un bloc Drupal. Commençons par l’implémentation de hook_block_info() :
fonction block_plugin_block_info() {
$blocs = déployer();
$ plugins = block_plugin_get_all_plugins();
pour chaque ($ plugins comme $ plugin) {
$blocs[DELTA_PREFIX . $plugin[‘name’]] = déployer(
‘Info’ => $ plugin[‘admin title’],
);
}
revenir $blocs;
}
Ici, nous chargeons tous les plugins à l’aide d’une fonction d’assistance et définissons les informations minimales requises pour le bloc. Ici, vous pouvez également ajouter plus d’informations, mais nous gardons les choses simples pour plus de concision.
Nous savons que chaque plugin aura un nom de machine (le nom du fichier d’inclusion essentiellement) et un titre d’administrateur car nous en générons un dans la phase de traitement s’il n’en existe pas. Le DELTA_PREFIX est une constante simple dans laquelle nous définissons le préfixe que nous voulons pour le nom de la machine de bloc car nous devons le réutiliser et devrions pouvoir le changer facilement si nous voulons :
définir(‘DELTA_PREFIX’, ‘block_plugin_’);
Notre fonction d’assistance que nous avons vue précédemment ressemble à ceci :
fonction block_plugin_get_all_plugins() {
revenir ctools_get_plugins(‘block_plugin’, ‘bloquer’);
}
C’est un simple wrapper autour de la fonction cTools respective. Et d’ailleurs, nous avons également la fonction suivante chargée de charger un seul plugin par son nom de machine :
fonction block_plugin_get_plugin($nom) {
revenir ctools_get_plugins(‘block_plugin’, ‘bloquer’, $nom);
}
Celui-ci est très similaire au précédent.
Afin de compléter nos définitions de blocs Drupal, nous devons implémenter hook_block_view() :
fonction block_plugin_block_view($delta = ») {
$ plugin = block_plugin_plugin_from_delta($delta);
si (!$ plugin) {
revenir;
}
$bloc = déployer();
// Titre facultatif
si (isset($ plugin[‘title’]) && $ plugin[‘show title’] !== FAUX) {
$bloc[‘subject’] = $ plugin[‘title’];
}
// Bloquer le contenu
$bloc[‘content’] = $ plugin[‘view’]($delta);
revenir $bloc;
}
Alors que se passe-t-il ici ?
Tout d’abord, nous utilisons une autre fonction d’assistance pour essayer de charger un plugin basé sur le delta du bloc actuel et ne faisons rien si nous n’avons pas affaire à un bloc de plugin.
Deuxièmement, nous construisons le bloc. Si l’utilisateur a spécifié une clé de titre sur le plugin et que la clé de titre d’affichage n’est pas fausse, nous définissons le sujet du bloc (son titre essentiellement) comme valeur du premier. En ce qui concerne le contenu réel du bloc, nous appelons simplement le rappel de vue défini dans le plugin. Et c’est tout.
Voyons rapidement aussi la fonction d’assistance chargée de charger un plugin basé sur un delta de bloc :
fonction block_plugin_plugin_from_delta($delta) {
$prefix_length = tendu(DELTA_PREFIX);
$nom = substr($delta, $prefix_length);
$ plugin = block_plugin_get_plugin($nom);
revenir $ plugin ? $ plugin : FAUX;
}
Rien de bien compliqué ici.
Définir les plugins de bloc
Puisque nous avons dit à cTools qu’il peut trouver des plugins de bloc dans le dossier plugins/block de notre module, allons-y et créons ce dossier. Dans celui-ci, nous pouvons ajouter notre premier bloc à l’intérieur d’un fichier avec l’extension .inc, par exemple my_block.inc :
< ?php $ plugin = déployer(
‘Titre’ => t(‘C’est mon bloc’),
);
/** * Renvoie un tableau restituable qui représente le contenu du bloc */
fonction block_plugin_my_block_view($delta) {
revenir déployer(
‘#taper’ => ‘balisage’,
‘#balisage’ => ‘Yo bloc!’
);
}
Comme nous le faisons avec tous les autres plugins (content_type, context, etc.), la définition du plugin se présente sous la forme d’un tableau à l’intérieur d’une variable appelée $plugin. Et pour notre cas, tout ce dont nous avons besoin à ce stade est un titre (et même pas cela puisque sans lui, le bloc n’affichera tout simplement pas de titre).
En dessous, nous avons défini notre fonction de rappel pour afficher le bloc. La dénomination de cette fonction est importante. Il correspond au modèle que nous avons utilisé pendant la phase de traitement (module_name_plugin_name_view). Si nous voulons le nommer différemment, tout ce que nous avons à faire est de référencer le nom de la fonction dans la clé de vue du plugin $ et il utilisera celui-ci à la place.
Et c’est fondamentalement ça. Nous pouvons maintenant vider nos caches et accéder à l’écran d’administration des blocs où nous pouvons trouver notre bloc et l’ajouter à une région. L’affichage de ce bloc sur la page devrait déclencher le rappel de vue pour ce plug-in de bloc et rendre le contenu.
Conclusion
Dans cet article, nous avons parlé un peu des plugins cTools et vu comment nous pouvons définir notre propre type de plugin. Nous avons utilisé ce dernier pour transformer le système de blocs Drupal en un système de plugin rudimentaire. Cela peut être étendu davantage pour permettre également aux crochets de configuration liés au bloc d’être remplacés par des rappels à l’intérieur du fichier d’inclusion du plug-in. De plus, comme mentionné précédemment, vous pouvez également vous assurer que toutes les données disponibles dans hook_block_info() peuvent être définies dans le plugin. Je vous laisse ces tâches.
