Inclure des modèles personnalisés dans nos plugins WordPress
Je pense que l’un des aspects les plus sous-estimés – ou peut-être l’un des aspects rarement discutés du développement de plugins personnalisés – est la possibilité d’inclure des modèles personnalisés dans nos plugins WordPress.
Et, pour être honnête, je comprends: je suis quelqu’un qui est assez convaincu de ce que devrait être un plugin et de ce que devrait être un thème.
C’est-à-dire:
- les thèmes sont pour la présentation,
- les plugins sont des fonctionnalités.
Si j’inclus des modèles dans un plugin, est-ce que je ne fais pas la même chose que lorsque les développeurs incluent des fonctionnalités dans leurs thèmes ?
Comme pour tant de choses en développement, je pense que cela dépend. Je veux dire, ajouter beaucoup de fonctionnalités qui vous enferment dans un thème est quelque chose dont je ne suis pas fan. De même, si vous avez un plugin destiné à présenter des données sur le front-end et qui est indépendant du thème, cela a du sens.
Il faut donc être judicieux dans ses décisions.
Quoi qu’il en soit, il existe un ensemble commun d’étapes que nous pouvons utiliser lors de l’inclusion de modèles personnalisés dans nos plugins WordPress.
Et c’est ce que ce post va montrer.
Si vous comptez inclure des modèles personnalisés dans le plug-in, je suppose que vous utilisez à la fois des modèles uniques et des modèles d’archive. Sinon, utilisez uniquement les crochets et le code ci-dessous dont vous avez besoin.
Pour les deux, cependant, sachez ceci :
En utilisant ces crochets, vous pouvez indiquer à WordPress où résident les modèles personnalisés dans votre plugin.
Organisation des modèles
Pour moi, j’ai généralement un répertoire de modèles dans mon plugin qui se situe au même niveau que les répertoires assets, src et vendor.
Cela permet de savoir facilement où ils résident et fournit un moyen cohérent de les inclure dans tous les plugins que vous avez créés. Après tout, il y a quelque chose à dire pour être cohérent dans les conventions que nous utilisons.
Y compris les modèles
En supposant que vous ayez un modèle single-acme.php et un modèle archive-acme.php, il est facile de l’inclure. Et bien que je sois plus fan de l’utilisation de la programmation orientée objet, je montrerai pour inclure ces modèles à l’aide de code procédural.
Il est facile de convertir ce code en code orienté objet si vous le souhaitez. De plus, je vais supposer que vous l’incluez également pour les types de publication personnalisés.
Vous pouvez toujours omettre une condition pour un type de publication personnalisé si vous souhaitez simplement inclure ces modèles, mais d’après mon expérience, je trouve qu’il est rare que ces situations n’utilisent pas de types de publication personnalisés, mais je ne connais pas votre situation.
Cela dit, voici le code.
Définir des crochets
Tout d’abord, nous devons définir les crochets. C’est relativement simple puisque nous allons utiliser les crochets décrits ci-dessus.
Tout d’abord, le template unique :
Et puis le modèle d’archive :
Et maintenant, nous pouvons implémenter le code pour chacune des fonctions.
Ajout du code
Donc, d’abord, nous allons regarder le modèle unique :
Et maintenant le modèle d’archive :
Si vous avez prêté une attention particulière au code, vous savez qu’il y a très peu de différences. En fait, le processus général peut être décrit comme suit :
- définir le crochet,
- localiser le modèle,
- vérifier le type de message personnalisé,
- le modèle existe, utilisez-le
- sinon, utilisez le modèle par défaut
Et c’est le processus pour les modèles uniques et d’archives.
Écrire des modèles compatibles
Et enfin, et c’est important surtout si vous voulez rendre le modèle aussi agnostique que possible, j’essaie d’utiliser autant de balises de modèle WordPress intégrées que possible lors de l’affichage du contenu lié au plugin. Cela permet aux développeurs de thèmes de le styliser facilement pour l’adapter à leur thème.
Non, vous ne pourrez pas accueillir tous les thèmes, mais telle est la nature des thèmes WordPress. Le but est de prendre autant de travail de récupération et de rendu des données du modèle que possible afin que les développeurs frontaux puissent facilement le gérer.