Tu as raison : le code n'est actuellement pas écrit pour faire une distinction entre cette liste "décorée" d'usagers et toutes les autres listes "décorées".
La liste des utilisateurs est construite par
users/index.php, qui fait appel à la fonction Skin::build_list($text, 'decorated') de skins/skinskeleton.php, laquelle appelle une constante DECORATED_IMG définie (dans ce même script) comme étant /icons/decorated.gif si cette image existe (ou une puce autrement).On peut toujours modifier
skins/skinskeleton.php en passant par skins/mon_skin/skin.php mais cela modifierait l'image dans toutes les listes décorées. Quelqu'un de plus familier avec PHP et l'organisation interne pourrait toujours se lancer dans l'écriture d'une instruction conditionnelle pour fournir une autre image lorsqu'on cherche à afficher la liste d'usagers, mais c'est encore hors de ma portée.Une solution serait de modifier
users/index.php mais cette modif serait écrasée à la prochaine mise à jour à moins d'être intégrée dans la distribution standard. Une nouvelle fonction à proposer ?Entre temps, tu peux toujours procéder par CSS pour cacher l'image sélectionnée par le script et en afficher une autre. C'est un "truc" car le code HTML continue de référer à l'image, mais ça fonctionne. Voici le truc (inscris le vrai nom de
ton_image.gif naturellement):
#users table.decorated td {
background: url("icons/ton_image.gif") left no-repeat;
border: none;
margin: 0;
padding: 6px 6px 6px 30px;
}
#users table.decorated td.image {
display : none;
}
On a si peu d'idée de ce qui est possible...
Oups ! à la réflexion, ce "truc" ne répond peut-être pas non plus à ton besoin. Il remplace toutes les images associées au utilisateurs, pas seulement
decorated.gif .Ainsi, si certains usagers ont choisi un avatar, il ne sera pas affiché. On ne verra que
ton_image.gif pour tous.On a si peu d'idée de ce qui est possible...
" Tu as raison : le code n'est actuellement pas écrit pour faire une distinction entre cette liste "décorée" d'usagers et toutes les autres listes "décorées". La liste des utilisateurs est construite parusers/index.php, qui fait appel à la fonctionSkin::build_list($text, 'decorated')deskins/skinskeleton.php, laquelle appelle une constanteDECORATED_IMGdéfinie (dans ce même script) comme étant/icons/decorated.gifsi cette image existe (ou une puce autrement). On peut toujours modifierskins/skinskeleton.phpen passant parskins/mon_skin/skin.phpmais cela modifierait l'image dans toutes les listes décorées. "
C'est exactement ce que j'ai constaté, hors moi je voudrais impacter seulement la liste des users. Je voulais confirmation, merci de me l'avoir donnée.
" Une solution serait de modifier users/index.php mais cette modif serait écrasée à la prochaine mise à jour à moins d'être intégrée dans la distribution standard. "
J'ai bien pensé à agir directement sur le code intrinsèque du moteur, mais ça me convient pas. Justement à cause du souci des mises à jour.
" Une nouvelle fonction à proposer ? "
Pourquoi pas. mais ce n'est pas une question de préférence et de votes des usagers, c'est toute l'approche sur la dérivation skin qui est concernée. Donc un débat avec les déveleppeurs.
Je ne m'attarde pas, j'ai mon yacs en double file...

Yacs on my blog | Suivez le blog Yacs | Yacs Showroom | Plugin Firefox de recherche dans Yetanoz |
Je ne suis pas certain que ce que tu soulèves remets en cause toute l'approche de dérivation des skins, comme tu le suggères, quoiqu'une discussion de ce genre serait certes bénéfique.
Çe que tu proposes m'apparaît vraiment comme une nouvelle fonction (reliée à la gestion des utilisateurs plutôt qu'aux skins à strictement parler): qu'on puisse formater spéciciquement la liste des utilisateurs plutôt que se contenter d'une liste
decorated . Ce serait une modification à faire au script users/index.php .Par contre, oui, il y a un tas de choses à repenser et à discuter au niveau des skins. Je t'endosse à fond là-dedans.
On a si peu d'idée de ce qui est possible...
Bonjour.
La "complexité" de la personnalisation d'un skin Yacs par un utilisateur lambda prend davantage d'ampleur, au vu des différentes réactions autour du sujet.
Je pense qu'il serait, à mon avis, fort utile pour yacs, de bénéficier d'un moteur de templates, et d'une uniformisation du code (au niveau des variables utilisées) des templates, tant au niveau du fichier template.php que de celui des nom_du_skin.css.
Un avantage certain serait le gain en productivité, au niveau de la création et de la personnalisation des skins.
@+
" Çe que tu proposes m'apparaît vraiment comme une nouvelle fonction (reliée à la gestion des utilisateurs plutôt qu'aux skins à strictement parler): qu'on puisse formater spéciciquement la liste des utilisateurs plutôt que se contenter d'une liste decorated . "
C'est à dire que : je voulais dire par là que la class #decorated# n'est malheureusement pas la seule incriminée. Il y a des bloc et des class dans ce genre qui ne sont pas modifiables dans YACs, même en dérivant un skin de référence, à moins de prendre le risque d'impacter un ou des fichiers de toutes façons écrasables par mises à jour du moteur.
" Par contre, oui, il y a un tas de choses à repenser et à discuter au niveau des skins. Je t'endosse à fond là-dedans. "
J'ai ai dérivé un certain nombre, plus ou moins profondément, mais pas crée un entier pour pouvoir faire des propositions aussi pertinentes que nécessaires. Je serais intéréssé à suivre quelques suggestions et même faire des tests.
Je ne m'attarde pas, j'ai mon yacs en double file...

Yacs on my blog | Suivez le blog Yacs | Yacs Showroom | Plugin Firefox de recherche dans Yetanoz |
Moi-même je te laisse le soin de créer une demande de nouvelle fonction histoire d'épurer un peu
Christian Loubechine
actupro
Actupro
quelques sites yacs : création site internet annuaire pro
Il y a des caractéristiques graphiques dans yacs sur lesquelles ont ne peut agir, même en dérivant un style. Même en modifiant carrément un template natif, quite à tout refaire en cas de mise à jour.
Un bon exemple est discuté dans ce fil.
Je n'ai aucune solution à apporter, je fais remarquer un état de fait. En conséquence, je ne vois pas quelle nouvelle fonction je pourrais proposer.
Par contre comme suggéré là haut, un débat avec le/les (j'ai jamais su) développeur serait de bon aloi.
Une bonne fois pour toute, savoir si un jour on aura une main mise possible sur l'intégralité de nos design, ou pas.
Râââ mais... c'te bête sur l'écran..pffff! Un parasite d'animal poilu encore.Annuaire des sites YACs
Plugin Firefox de recherche dans Yetanoz
Nouvelles fonctions suggérées
Je ne m'attarde pas, j'ai mon yacs en double file...

Yacs on my blog | Suivez le blog Yacs | Yacs Showroom | Plugin Firefox de recherche dans Yetanoz |












