Suite aux propositions de FredoMkb, CFG en version 1.0.8 peut maintenant éviter d'afficher tous les fonds (onglets) dans la page ecrire/?exec=cfg .
Pour ce faire, s'il y a un fond que vous ne souhaitez pas voir afficher sur cette page dans les onglets, il faut ajouter l'option dans /fonds/cfg_mon_fond.html :
[(#REM) onglet=non]
Pour rappel :
----------------
Dans un fond, vous pouvez mettre des liens vers d'autres fonds avec l'option [(#REM) liens*=mon_fond]
Ainsi, petit exemple avec 3 fichiers fonds/cfg_squelette.html et fonds/cfg_squelette_options_1.html et fonds/cfg_squelette_options_2.html
Vous pouvez mettre dans cfg_squelette.html :
[(#REM) liens*=squelette_options_1]
[(#REM) liens*=squelette_options_2]
dans cfg_squelette_options_1.html :
[(#REM) onglet=non]
[(#REM) liens*=squelette]
[(#REM) liens*=squelette_options_2]
dans cfg_squelette_options_2.html :
[(#REM) onglet=non]
[(#REM) liens*=squelette]
[(#REM) liens*=squelette_options_1]
Ainsi, sur la page ?exec=cfg, seul le lien vers le fond cfg_squelette.html s'affiche (1 seul onglet), qui propose alors des liens vers les autres pages.
* Matthieu Marcillaud tapuscrivait, le 27/09/2007 13:09:
Bonjour,
Suite aux propositions de FredoMkb, CFG en version 1.0.8 peut maintenant éviter d'afficher tous les fonds (onglets) dans la page ecrire/?exec=cfg .
Pour ce faire, s'il y a un fond que vous ne souhaitez pas voir afficher sur cette page dans les onglets, il faut ajouter l'option dans /fonds/cfg_mon_fond.html :
[(#REM) onglet=non]
Et c'est bien que ça laisse l'accès direct depuis la page ecrire/?exec=admin_plugin (en 1.9.3)
Dans un fond, vous pouvez mettre des liens vers d'autres fonds avec l'option [(#REM) liens*=mon_fond]
Est-ce vraiment une bonne idée d'utiliser #REM à faire quelque chose ?
Je pense que le sens de cette balise commentaire est qu'elle ne fait rien !
Oui, tu as raison... mais dans ce cas, c'est empirique
Toggg a commencé comme cela, et aussi en utilisant les commentaires html <!-- --> . Je ne fais que perpétuer.
C'est vrai qu'un nom de balise adéquat pour définir les variables de cfg serait meilleur, encore que... ... M'enfin, ça fonctionne et tout le monde s'en sort !
Le truc, c'est qu'il faut passer des infos à CFG d'une manière ou d'une autre. On se retrouve avec 2 notations [(#REM)] et <!-- --> un peu bancales toutes les 2 : la première est lue facilement par cfg, mais ne peut pas recevoir de balise, ni de champs à traduire <:chose:>, la seconde nécessite que cfg calcule le fond (c'est lourd) mais peut recevoir du coup des balises et des <::>...
Z'en pensez quoi ? Je ne sais pas trop comment s'en sortir (si l'on devait sortir de quelque chose)...
Matthieu Marcillaud wrote:
> Dans un fond, vous pouvez mettre des liens vers d'autres fonds avec
> l'option [(#REM) liens*=mon_fond]
Est-ce vraiment une bonne idée d'utiliser #REM à faire quelque chose ?
Je pense que le sens de cette balise commentaire est qu'elle ne fait rien !
Je me suis en effet fait la même réflexion, je pense
que le système de parametrages de CFG avec des balises #REM
devrait être revu, ce qui implique des modifications importantes
à mon avis, mais pour l'heure, c'est la méthode choisie
et qui fonctionne pas trop mal, si faut juste la rendre
un peu plus souple je pense...
Le truc, c'est qu'il faut passer des infos à CFG d'une manière ou d'une autre. On se retrouve avec 2 notations [(#REM)] et <!-- --> un peu bancales toutes les 2 : la première est lue facilement par cfg, mais ne peut pas recevoir de balise, ni de champs à traduire <:chose:>, la seconde nécessite que cfg calcule le fond (c'est lourd) mais peut recevoir du coup des balises et des <::>...
Pour les langues, ca serait facile pour CFG de faire le remplacement lui-même, non?
<:toto:> est remplacé par le résultat de _T('toto')
Pat
Oui, je pense aussi. De toute façon, c'est du côté du core ça, le plugin cfg ne surcharge pas admin_plugin.
MM.
Des lignes de code présentes dans le core et concernant un plugin, ça m'a plutot surpris, d'autant plus qu'il existe d'autres moyens de le faire... Mais bon, l'intégration de CFG à SPIP est peut-être déjà une chose acquise !
Des lignes de code présentes dans le core et concernant un plugin, ça
m'a plutot surpris, d'autant plus qu'il existe d'autres moyens de le
faire...
tu penses à quoi ? là c'est juste l'ajout d'un lien, j'ai hésité à
forker pour si peu (péché véniel ?)
Mais bon, l'intégration de CFG à SPIP est peut-être déjà une
chose acquise !
pas pour l'immédiat : je crois que cfg a trop de code pour être
vraiment intégrable comme ça ; en plus il est loin d'être
internationalisé (et c'est pas facile)...
Des lignes de code présentes dans le core et concernant un plugin, ça
m'a plutot surpris, d'autant plus qu'il existe d'autres moyens de le
faire...
tu penses à quoi ? là c'est juste l'ajout d'un lien, j'ai hésité à
forker pour si peu (péché véniel ?)
Non bien sûr, c'est mieux que de forker
yavait tjrs la solution d'utiliser le pipeline 'affiche_gauche'
sinon, il se trouve que lors de l'appel de install('test') pour les plugins, on se retrouve au bon endroit. un simple echo suffit :
switch ($action){
case 'test':
if (_request('exec') == 'admin_plugin') {
debut_cadre_enfonce();
echo icone_horizontale(blablabla);
fin_cadre_enfonce();
}
