Le passage de Dotclear 1 à Dotclear 2 a été une opération lourde pour les développeurs, qui sont repartis de zéro pour faire un code plus propre, plus sûr, plus performant… Mais tous ces changements ne se sont pas faits sans quelques inconvénients. Je vous avais déjà parlé de la disparition de l’option permettant de le mettre que les extraits dans le flux RSS, et vous avais proposé une solution de contournement. Aujourd’hui, je vais m’attaquer à un autre problème : la disparition du PHP dans les thèmes.
En effet, dans Dotclear 1, chaque thème contenait un fichier template.php, qui définissait le design du thème ainsi que quelques autres fichiers .php pour certaines portions de l’interface. Ce système n’était pas un modèle de propreté, puisqu’il mélangeait le graphisme et la programmation, mais il avait l’avantage d’offrir une très grande souplesse, puisqu’on pouvait insérer à peu près n’importe quel bout de code PHP dans ces fichiers pour réaliser une personnalisation poussée.
Dans Dotclear 2, tout cela est terminé : les templates des thèmes sont de simples fichiers HTML*, contenant quelques balises spécifiques qui seront remplacées dynamiquement par le moteur de traitement de Dotclear. Chacune de ces balises est associée à une fonction PHP, donc il suffit en fait de créer de nouvelles balises pour insérer vos routines personnalisées.
Pour celà, il y a trois solutions, deux propres, et une moins propre. La première, c’est tout simplement de profiter du système de plug-ins pour créer un plug-in qui va définir vos différentes balises et le code associé. Cette solution est intéressante si vous voulez définir de nombreuses balises et si vous voulez pouvoir facilement les porter d’un blog à un autre. Pour la réalisation, vous pouvez vous inspirer du plug-in MoreTpl disponible sur DotAddict. La seconde solution consiste à définir les balises et leurs fonctions dans un fichier _public.php placés dans le répertoire du thème. Ce fichier se construit sur le même modèle que celui du plug-in, mais les balises qui y seront définies ne pourront être utilisées que dans le thème concerné : c’est la meilleure solution si vous voulez définir des balises pour un thème que vous voulez diffuser.
La troisième solution, c’est ma solution « Infobidouillesque » 🙂 Plutôt que de créer un plug-in ou un fichier _public.php pour le thème, ce qui va nécessiter le chargement de fichiers supplémentaires, nous allons nous attaquer directement au fichier où sont définis les balises livrées par défaut. Et c’est là qu’on remercie Dotclear 2 pour la propreté de son code…
Une recherche sur le nom d’une de ces balises dans les fichiers de Dotclear 2 permet d’identifier rapidement le fichier à modifie : il s’agit de inc/public/class.dc.template.php. Dedans, on retrouve tout d’abord une fonction __construct, dans laquelle vous devrez déclarer le nom de votre balise et la fonction associées, puis diverses fonctions utilitaires liées à la gestion des balises (jusqu’à la ligne 300 environ), puis enfin toutes les fonctions associées aux balises de base. Vous n’aurez donc qu’à ajouter le code que vous voulez dans une nouvelle fonction.
Par exemple, nous allons ajouter une balise BlogID, qui renverra l’ID du blog dans un système mutli-blogs. Tout d’abord, on rajoute la ligne suivante quelque part dans la fonction __construct (idéalement, aux environs de la ligne 60, dans le bloc définissant les balises Blog*, ou dans un bloc regroupant toutes vos balises personnalisées, soit au début, soit à la fin de la fonction) :
|
1 |
$this->addValue('BlogID',array($this,'BlogID')); |
Ensuite, on crée une fonction qu’on ajoute dans la classe dcTemplate :
|
1 2 3 4 5 |
/*dtd <!ELEMENT tpl:BlogID - O -- Blog ID --> */ public function BlogID($attr) { $f = $this->getFilters($attr); return '<?php echo '.sprintf($f,'$core->blog->id').'; ?>'; } |
Remarquez bien la structure du code : la fonction ne doit pas exécuter directement le code correspondant à la balise, mais plutôt générer ce code et le retourner à l’appelant.
En poussant l’exploitation des balises personnalisées à l’extrême (mais là, ça devient carrément sale…), on pourrait presque revenir à un mode de fonctionnement à l’ancienne : un template ne contenant qu’une seule balise, qui génère tout le code PHP équivalent au template.php de Dotclear 1. A priori, il doit en effet être possible de référencer une balise existante dans le code généré par une autre balise, en appelant directement la fonction correspondante et en exécutant le code retourné. Par exemple, un appel à $core->tpl->EntryExcerpt() devrait permettre de récupérer le code à exécuter pour la balise EntryExcerpt. Par contre, n’ayant pas testé cette dernière possibilité, je ne garantis pas son exploitabilité…
Vous pouvez également modifier le contenu du fichier inc/public/class.dc.template.php pour changer le comportement des balises existantes si elles ne vous conviennent pas.
Il existe également une option permettant d’autoriser le code PHP dans les fichiers templates (tpl_allow_php dans le about:config), mais ce code devient alors modifiable depuis l’interface d’administration, puisqu’elle permet maintenant l’édition des fichiers templates. Je déconseille donc cette solution, qui pourrait s’avérer peu sûre et qui va « polluer » les templates avec du code qui n’a pas grand chose à y faire… A n’utiliser donc qu’en cas d’absolue nécessité, si la définition de nouvelles balises ne vous permet pas de faire ce que vous voulez.