Une nouvelle version qui utilise dorénavant le dossier /var de l’installation pour stocker ses fichiers, plus précisément dans le sous répertoire /var/plugins/tidyAdmin/, sous les noms de admin.css pour la CSS personnalisée et admin.js pour le Javascript personnalisé.
Notez qu’à chaque sauvegarde la version précédente est copiée dans le fichier admin-backup.css ou admin-backup.js au même endroit.
Ce petit plugin, compatible avec les versions 2.13 et suivantes de Dotclear, permet de transformer légèrement l’aspect et le fonctionnement de l’administration de Dotclear et de gérer les jeux d’icônes alternatifs[1].
Le plugin permet l’installation de jeux d’icônes supplémentaires, voir le 2e onglet « Installation et mise à jour de jeux d’icônes », soit en déposant un fichier zip contenant le jeu d’icônes, soit en fournissant l’URL de téléchargement de l’archive :
Vous noterez la présence d’une case à cocher, intitulée « Préserver les dossiers et fichiers existants et non présents dans le fichier zip du jeu d’icônes », cochée par défaut, qui permet de préserver, lors d’une mise à jour, les fichiers qui ne font pas partie du jeu d’icônes standard, mais que vous avez rajoutés :
Si vous décochez cette case, alors le jeu d’icône correspondant sera intégralement supprimé avant que l’archive soit installée. Bien sûr ceci n’est valable que pour les mises à jour et n’a aucun effet pour une première installation.
Une fois un ou plusieurs jeux d’icônes installés, vous pourrez, sur le 1er onglet « Gestion des jeux d’icônes » activer, désactiver[2] ou supprimer ceux-ci :
Le 3e onglet permet de définir des règles CSS supplémentaires qui seront prises en compte pour l’affichage des pages d’administration. Un exemple est fourni que vous pouvez modifier à loisir. Pensez à vider le cache de votre navigateur une fois les règles enregistrées :
Enfin, le 4e onglet permet de définir un script Javascript supplémentaire qui sera pris en compte pour l’affichage des pages d’administration. Un exemple est fourni[3] que vous pouvez modifier à loisir. Pensez à vider le cache de votre navigateur une fois le script enregistré.
Notez enfin que seul les « super-admins » pourront avoir accès à ce plugin.
Ce billet servira de support pour cette version du plugin.
Notes
[1] Vous trouverez en pièce jointe du billet lié plusieurs jeux d’icônes prêts à l’usage.
[2] La désactivation revient à ajouter un . devant le nom du répertoire du jeu d’icônes, l’activation faisant l’inverse. Sur certains systèmes vous ne verrez donc pas forcément les jeux désactivés (les fichiers/dossiers commençant par un point sont habituellement masqués sur Mac OS X et Linux.
[3] Cet exemple permet d’activer l’affichage et le masquage du menu latéral au survol de la souris sur le séparateur et non plus au clic sur celui-ci.
1 De brol -
Bonjour,
Y a une faute de frappe dans le define pour le lien de support.
Pourquoi avoir fait un dossier “plugins” dans var ? N’y a-t-il pas risque de confusion si d’autres plugins créent un dossier “plugins” puis le nom de leur plugin dans le var ? (pour info, j’y ai déjà errorlogger et dcweather)
Merci
2 De Franck -
Le sous-dossier plugins dans var est une bonne façon d’isoler les paramètres des plugins du reste. Si c’est correctement codé, il ne doit pas y avoir conflit, le sous-répertoire plugins n’est créé que s’il n’existe pas déjà.
3 De Franck -
Pour préciser ce qui devrait normalement être une hiérarchie correcte dans /var :
/var → tout ce qui à rapport à l’installation dans son ensemble (quel que soient les plugins/thèmes installés/activés)
/var/plugins → tout ce qui a rapport aux plugins
/var/plugins/<plugin-id> → pour un plugin donné
/var/themes → idem pour les thèmes
/var/themes/<themes-id> → pour un thème donné
/var/blogs/<id-du-blog> → ce qui a rapport avec le blog en question, dans lequel on pourrait aussi répéter la même hiérarchie que celle définie jusque ici pour /var comme par exemple :
/var/blogs/<id-du-blog>/plugin/<plugin-id> → paramètres du plugin pour le blog en question
Par ailleurs Dotclear, quand il en a besoin, crée des dossiers à la racine de /var. C’est le cas pour le rapport associé au Content-Security-Policy rangé dans /var/csp/.
Une remarque : ce dossier /var n’a pas vocation à remplacer un stockage de paramètre effectué normalement dans la base, via les paramètres du blog (settings) ou les préférences utilisateurs (prefs).
Pour conclure, si on n’y met pas un peu d’ordre ça peut vite devenir un foutoir innommable.
4 De Franck -
Quant aux plugin errorlogger et dcweather, il me semble que leur fichiers sont créés dans le dossier /cache et pas dans le dossier /var ; a priori c’est plutôt adapté, même si on peut raisonnablement se poser la question pour le premier qui pourrait gagner à basculer dans /var pour conserver les fichiers log même si le cache est vidé.
Le dossier /cache vidé, contrairement au dossier /var, ne remet pas en cause, ni ne modifie le comportement de l’installation.
5 De brol -
Comme il n’y avait à l’époque strictement aucune doc pour se dépatouiller avec /var quand il est apparu, j’ai fait au mieux.
“Les développeurs de plugin sont fortement encouragés à créer leur propre répertoire au sein de ce répertoire /var afin de conserver un semblant d’ordre.” source : https://fr.dotclear.org/blog/post/2…
C’est donc ce que j’ai fait : un répertoire au nom de chaque plugin dans /var à la place de /cache.
Les deux plugins précités sont dispos chez moi pour qui est intéressé.
6 De Franck -
Je pense que pour dcweather il aurait mieux valu le laisser dans le cache, vu que c’est réellement ce qu’il y stocke !
7 De Philippe -
Plop ! Avec la version de développement de Dotclear, lorsque j’ajoute des règles supplémentaires dans l’admin, elles n’ont pas d’effet.
Dans le code source de la page de l’admin, je vois bien le lien vers :
<link rel="stylesheet" href="index.php?vf=plugins/tidyAdmin/admin.css&v=2.15-dev-r3925" type="text/css" media="screen" />mais l’url renvoie un message d’erreur
@@<br />
<b>Notice</b>: Use of undefined constant DC_VAR - assumed ‘DC_VAR’ in <b>/srv/data/(…)/dotclear/inc/load_var_file.php</b> on line <b>61</b><br />@@
Mettre DC_VAR entre guillemets dans load_var_file.php ne résout pas le problème, malheureusement :D
8 De Philippe -
Post-scriptum : dans dotclear/var/plugins/tidyAdmin j’ai bien un fichier admin.css avec mes règles, ainsi qu’un fichier admin-backup.css au contenu identique
9 De Franck -
C’est étrange cette histoire de DC_VAR absente, vu qu’elle est normalement définie dans le _config.php et que sinon elle est définie par l’appli.
10 De Philippe -
Oups : mon config.php ne contenait pas cette constante, ça marche tout de suite mieux maintenant.
Désolé pour le bruit.
11 De Franck -
Par contre ça devrait tout de même fonctionner sans la constante dans le fichier de configuration ! Faut que je teste ça…
12 De Franck -
Nope, pas de problème si la constante n’est pas définie ; tu as un truc bizarre dans ta config gars !
13 De Philippe -
PHP 5.6.30 ?
14 De Franck -
Bah non, je ne vois pas pourquoi une différence de version de PHP ferait que la constante ne serait pas définie (voir inc/prepend.php, lignes 214 à 216) !