Dotclear

Ticket #1324 (closed enhancement: wontfix)

Opened 12 years ago

Last modified 7 years ago

Interraction thème / admin

Reported by: franck Owned by: xave
Priority: normal Milestone:
Component: module:core Version: 2.4
Severity: normal Keywords:
Cc:

Description

Il n'existe aucun moyen, pour un thème, d'intervenir côté administration (ailleurs que sur sa propre page de configuration).

Il serait souhaitable de prendre en compte le fichier _admin.php du thème actif du blog afin de permettre des traitements particuliers.

Par exemple, un thème pourrait prendre en charge un "avatar" d'auteur, avatar qui serait alors réglable dans les préférences utilisateur, via le ou les behaviours idoines (déjà utilisés par certains plugins).

Change History

comment:1 Changed 12 years ago by bruno

J'ai du mal à cerner le besoin réel derrière ça. Pour moi, la gestion d'un avatar ne devrait surtout par être liée à un thème, mais plutôt fournie par l'intermédiaire d'un plugin.

J'ai peur qu'en ouvrant un _admin.php aux thèmes, on se retrouve avec des thèmes fournissant des services dédiés, alors que ces derniers mériteraient un plugin partageable par d'autres thèmes.

comment:2 Changed 12 years ago by franck

Si j'ai ouvert ce ticket c'est que le besoin est réel. Ductile Focus n'attend que cette "feature" pour pouvoir être distribué.

Sinon ça veut dire qu'il faut coder un plugin entier uniquement pour gérer une URL d'image (je simplifie) dans les préférences utilisateurs. De plus DC n'intègre pas de système de dépendances entre thèmes et plugins et du coup on peut se retrouver avec l'un sans l'autre.

Quant à avoir des thèmes avec des services dédiés, etc, vu le nombre de thèmes soumis ces derniers mois, je pense qu'on est définitivement à l'abri de ce genre de problème :-)

D'un point de vue général, ça ne me semble pas aberrant d'avoir des spécificités côté utilisateur pour un thème (ie préférences utilisateurs), comme on en a pour un blog (les préférences et réglages du thème se font pour un blog seulement).

comment:3 Changed 12 years ago by bruno

Je ne conteste pas le besoin d'avoir une admin pour un thème, je trouve juste bizarre de faire porter un besoin transverse par un thème (ce qui veut dire qu'il n'est de facto pas réutilisable par d'autres thèmes). J'ai notamment un cas d'utilisation sur des widgets spécifiques à un thème, qui auraient besoin d'un _admin.php dédié (mais lié au thème lui-même, voire les thème mystique et le plugin mystiqueconfig). Ajouter un avatar me semble bien plus pertinent en tant que plugin qu'en tant que thème.

Quant aux gestions des dépendances thèmes/plugins, c'est effectivement une idée de longue date qui mériterait de refaire surface (d'autant que je ne pense pas que ce soit difficile à mettre en oeuvre).

comment:4 Changed 12 years ago by franck

Je ne vois pas pourquoi une spécificité liée à un thème et dépendant de l'utilisateur (avatar d'auteur en l'espèce) serait absolument partageable avec d'autres thèmes. Ce n'est qu'un réglage du thème dont la clé est le user-id (pour faire court), rien de plus.

On pourrait tout aussi bien imaginer un thème dont une variation ou une présentation dépendrait de l'âge de l'auteur des billets, … là aussi "réglable" dans les préférences utilisateurs. Etc etc

J'ai le sentiment qu'on ouvrirait des possibilités qui pourraient plaire aux concepteurs de thèmes (dans le sens de la simplification), mais je peux me tromper.

comment:5 Changed 12 years ago by bruno

Les impacts au niveau du code pour intégrer cette gestion de _admin ne sont pas si triviaux que ça. Il faudrait revoir la gestion des modules de type theme... voir notamment avec #1296

comment:6 follow-up: ↓ 7 Changed 12 years ago by franck

Pour l'instant le thème est chargé uniquement côté public ou lorsquil possède un configurateur (_config.php) et qu'on le met en œuvre (via l'apparence du blog).

Rien n'empêche de commencer par le charger également quand on règle ses préférences utilisateurs, histoire de le laisser intervenir de ce côté.

comment:7 in reply to: ↑ 6 Changed 12 years ago by bruno

Rien n'empêche de commencer par le charger également quand on règle ses préférences utilisateurs, histoire de le laisser intervenir de ce côté.

Sauf que pour être cohérent, il faudrait charger le _admin.php du thème dans inc/admin/prepend.php, sauf dans les pages non liées à un blog en particulier, qu'il faut traiter les cas des thèmes parents (le code actuel du chargement des parents est à revoir), qu'il ne faut alors plus instancier $core->themes dans admin/blog_theme.php sous réserve d'avoir des duplicate class, et qu'il faut prendre en compte la l10n...

Je n'ai pas dit que ce n'était pas faisable, seulement que les impacts sont assez éparpillés dans le code :)

comment:8 Changed 7 years ago by franck

  • Status changed from new to closed
  • Resolution set to wontfix
  • Milestone A definir deleted
Note: See TracTickets for help on using tickets.

Sites map