Pour ce faire il faut savoir une chose plutôt simple : le plugin va, au moment où le blog sera affiché, fournir des règles CSS — qui seront bien entendu dépendantes des réglages effectués et enregistrés sur la page de configuration — qui seront ajoutés à celles prévues en standard dans la ou les feuilles de style livrées avec le thème.
Comment cela peut-il ? Eh bien très facilement car Dotclear fournit un certain nombre de behaviour, sortes de points d’entrée, qui permettent à un thème ou à un plugin de venir compléter ou modifier le traitement effectué par le cœur (ou le noyau) de Dotclear. Tout ça est du charabia je le consens alors je vais plutôt que de faire des grandes phrases montrer le code que je vais utiliser.
Première ébauche
Tout d’abord et comme pour tout plugin qui se respecte il lui faut un dossier avec un joli nom, disons ductileConfig
pour être original et il faut un fichier _define.php
à l’intérieur de ce dossier. Ce fichier contiendra ceci :
<?php # -- BEGIN LICENSE BLOCK --------------------------------------- # # This file is part of Dotclear 2. # # Copyright (c) 2003-2011 Olivier Meunier & Association Dotclear # Licensed under the GPL version 2.0 license. # See LICENSE file or # http://www.gnu.org/licenses/old-licenses/gpl-2.0.html # # -- END LICENSE BLOCK ----------------------------------------- if (!defined('DC_RC_PATH')) { return; } $this->registerModule( /* Name */ "Ductile Config", /* Description*/ "Configure your Ductile Theme", /* Author */ "Dotclear Team", /* Version */ '0.1', /* Permissions */ 'admin' ); ?>
Comme pour le thème nous ferons évoluer le numéro de version au fur et à mesure de nos développements.
C’est le minimum requis pour avoir un plugin fonctionnel, sauf qu’en l’espèce tu dois comprendre qu’il ne fait pas grand chose. Certes mais il ne gêne pas non plus, ce qui est assez satisfaisant, n’est-ce pas ?
Ensuite, et simplement pour illustrer le fonctionnement que j’exposais plus haut je crée un nouveau fichier _public.php
, fichier qui sera appelé lors de l’affichage public (évidemment) du blog. Voilà le début du code :
<?php # -- BEGIN LICENSE BLOCK --------------------------------------- # # This file is part of Dotclear 2. # # Copyright (c) 2003-2011 Olivier Meunier & Association Dotclear # Licensed under the GPL version 2.0 license. # See LICENSE file or # http://www.gnu.org/licenses/old-licenses/gpl-2.0.html # # -- END LICENSE BLOCK ----------------------------------------- if (!defined('DC_RC_PATH')) { return; } if ($core->blog->settings->system->theme != 'Ductile') { return; } // la suite va venir ici… ?>
Tu vois que j’ai mis un bloc de commentaire avec les infos de licence, etc, comme il est d’usage puis une ligne qui permet de vérifier que nous sommes bien en train d’exécuter du code au sein de Dotclear. De plus j’ajoute un test qui permet de s’arrêter aussitôt si le thème sélectionné n’est pas Ductile
puisque ce plugin ne concerne que celui-ci.
Ce qui est intéressant vient maintenant. Comme je le précisais au début, il faut utiliser un point d’entrée précis (un behaviour) pour fournir la ou les règles CSS supplémentaires définies par la configuration du thème. Ce behaviour se nomme publicHeadContent
et comme son nom peut le faire penser il va nous permettre de préciser du contenu à rajouter dans la partie <head>…</head>
de la page en cours d’affichage.
Voilà le code qui va venir s’insérer dans le fichier _public.php
, là où j’indiquais plus haut « // la suite va venir ici… » (vois le code ci-dessus).
$core->addBehavior('publicHeadContent',array('tplDuctileTheme','publicHeadContent')); class tplDuctileTheme { public static function publicHeadContent($core) { echo '<style type="text/css">'."\n".'a { color: #F00; }'."\n</style>\n"; } }
Tu devrais facilement reconnaître une règle CSS fort simple pour l’instant, qui ne fait rien de plus que de préciser que la couleur des liens sera désormais en rouge (#F00
).
Une alternative
Dotclear étant ce qu’il est, à savoir extrêmement bien conçu, il est tout à fait possible de faire en sorte que le thème transporte son propre système de configuration et gère l’ajout des règles CSS de surcharge lui-même. Dans ce cas, il suffirait (ou suffira) qu’on place le même fichier _public.php
dans le répertoire du thème, son contenu étant strictement identique, et qu’on prévoit un fichier _config.php
s’occupant de gérer les réglages disponibles pour la configuration.
C’est peut-être une meilleure façon de faire si on veut un thème auto-suffisant et réglable et c’est un point qu’il faudra trancher un jour ou l’autre.
Conclusion
Bien sûr le plugin final sera un peu plus complexe — je n’ai pas encore parlé de la partie administrative pour gérer la configuration du thème — car il faudra aller récupérer les choix enregistrés par l’administrateur[1] pour construire les règles CSS nécessaires et qui viendront surcharger celles que tu auras prévues.
Cela peut également signifier qu’il faut tenir compte de ce mécanisme dans la construction de tes feuilles de style et des règles qu’elles contiennent afin que leurs surcharges soit possible. Cela dit je ne doute pas un instant de ton génie pour te garder de toutes les chausse-trappes qui pourraient se présenter !
J’espère que ces quelques explications ne t’auront pas paru trop rébarbatives et m’en vais de ce pas siroter un petit café bien mérité…
Notes
[1] Tu as du constater dans la fiche du plugin, le fichier _define.php
, que celui-ci ne pouvait être utilisé que par un administrateur du blog.