Disons que ce n'est pas tout à fait dedans, mais c'est assez proche quand-même.

Eliminer le nom du template dans les chemins : je suis à fond pour !
Mais je n'ai pas trop encore cherché à comprendre comment sont évaluées les variables dans les templates.
Si j'utilise "{user:template}" il va le pêcher où ? c'est automagique, déjà récupéré dans le profil utilisateur ?
Et si j'utilise "{template:help_icon}" ou "{template:default_layout_stylesheet}" il va falloir les définir quelque part ?

Chris,

Bien entendu, l'idée est excellente.
Toi et z0rglub, avez juste un peu d'avance sur tout le monde, c'est normal, vu les infos du bugtracker.

Un petit schéma du futur design des templates ne serait sans doute pas de trop (même si j'en ai déjà une idée assez précise, elle n'est peut être pas exactement la même pour tous).
Surtout pour montrer en quoi cela va simplifier les efforts de customisation.

Merci d'avance.
Vincent

PS: Oh, oui. Le chemin des css dans le tpl d'header !!! A chaque fois: plouf, je l'ai oublié (maintenant il me suffit de 3 secondes pour dire "zut".
La toute première fois, on peut chercher un moment "Pourquoi nos adaptations du template ne sont pas visibles?"...
Merci z0rglub.

Chris,

C'est exactement ce que je pensais et...

Si on combine bien les choses "gérer le nom du thème dans les préférences utilisateur" et/ou dans les préférences du groupe...
Dans ce cas, inutile d'installer deux ou trois fois PWG pour gérer des sites.

Les groupes/utilisateurs voient des catégories différentes au travers de thèmes différents.
Si on y arrive et je suis persuadé que c'est plus simple qu'il n'y parait, reste les adresses.

Un bon rewriting des URL, on doit pouvoir rendre le tout transparent pour les visiteurs ou membres.
Il n'y a plus que le domaine ou sous-domaine ou redirection web pour chacun des sites.

(Encore une idée qui remonte la barre un cran plus haut).

Merci Chris.
Vincent

Vassae a écrit:

A lire le début, j'allais vous parler d'une gestion non commune aux templates mais plutot de la gestion de sous-templates se rattachant à un principal... et Chrisaga l'a fait avant moi :)

C'est ce que j'ai appelé le thème : couleurs, polices et icônes

Vassae a écrit:

[...]Et dans le sous-template (qui est un sous-répertoire du template principal) ne sont présents que les fichiers qui diffèrent. Tous les autres sont absents. Quand le programme ne les trouvent pas dans le sous-template, il utilise ceux du template principal.[...]

Je vois deux objections à cette approche, toutes deux liées au fait que l'on fait mouliner le code de PWG :
1) ça coûte en CPU mutualisée pour recalculer pour chaques pages où sont les fichiers,
2) ça suppose développer du code pour ça.
Je pense que ce n'est pas le rôle principal de PWG, et que l'on peut déjà se baser sur un système plus déclaratif (inclusion des css, déclaration du répertoire d'icônes). Le fait que la découverte des éléments du thème soit automatique n'apporte pas réellement de valeur ajoutée une fois que le thème est bouclé et installé "en production", mais demande des efforts pour la mise au point.

Question pour Z0rglub :
Comment peut-on facilement déclarer au niveau du template un certain nombre de variables qui seraient utilisées dans les *.tpl pour indiquer par exemple le chemin du répertoire d'icônes ?
Est-ce qu'un tpl-inc.php conviendrait ?
Est-ce que ça serait compliqué ?

Vassae a écrit:

En fait cette architecture me parrait plus logique que celle où l'on aurait un répertoire commun plus en amont.

Les deux concepts ne sont pas contradictoires, mais complémentaires : le répertoire commun sert à stocker des informations de présentation/comportement valables pour tous les templates/thèmes (affichage où nom du titre, taille max des vignettes, ...)

z0rglub a écrit:

[...]
Bref, cela ne me semble pas compliqué du tout. Reste à trouver les bonnes variables, etc.

Super !
Merci, je vais essayer d'y réfléchir un peu ce week-end.
Je suppose que ça sera pour la BSF et non la 1.5.1 parce que ça suppose pas mal de ménage dans les fichiers du template.

Salut à tous, compte tenu de l'ampleur des modifs pour mettre en œuvre ce dont nous avons discuté, j'ai fait un petit point avec z0rglub pour voir si je n'étais pas trop à côté de la plaque. Voici ce que l'on peut en retenir :

chrisaga a écrit:

Comme dit dans la discussion [Evolution] Remontée des ressources communes aux templates, je me suis collé essayer de voir ce que l'on peut mettre en pratique.
J'ai quelque chose qui fonctionnne et que je voulais soumettre Z0rglub avant de faire un commit dans la BSF parce que ça impacte pas mal de fichiers et de répertoires.
Un snapshot est disponible ici : bsf-snapshot-2005-11-26.tar.bz2.

J'ai remonté les ressources communes dans template-common et séparé le thème du template.
Voici ce que ça donne :

Code:

|
|-> template
|      |-> yoga
|      |      |-> default-layout.css
|      |      |-> (autres fichiers css)
|      |      |-> (fichiers tpl)
|      |
|      |-> yoga-dark
|      |-> (autres templates)
|
|-> template-common
|     |-> default-layout.css
|     |-> icons
|           |-> admin
|                  |-> (fichiers png)
|           |-> mimetypes
|                  |-> (fichiers png)
|           |-> (fichiers png de base)
|
|-> theme
       |-> yoga-clear
       |      |-> default-color.css
       |      |-> tplconf.inc.php
       |
       |-> yoga-dark
              |-> default-color.css
              |-> tplconf.inc.php
              |-> images

                     |->tableh1_bg.png
                     |->tableh2_bg.png

Le principe est que la fonction get_templates() renvoie les sous-répertoires du répertoire themes et non plus template, et que le nom du template est stocké dans le tplconf.inc.php.
J'espère que je n'ai pas trop fait de dégats, mais franchement, le système de template est bien fait, et ça a été beaucoup plus facile que je ne m'y attendais.

Reste à faire :
1) l'appel du template/theme pour install.php
2) page_header.php contient encore une référence à $user['template'] pour construire une variable $css, mais je crois que ce n'est plus utilisé
3) renommer $user['template'] en $user['theme'] et get_templates() en get_themes() (d'autres ?) pour la cohérence

Je ne suis pas mécontent du résultat, surtout lorsque l'on voit que yoga-dark ne "pèse plus que" 4 fichier et un répertoire.

OK pour un commit ?

z0rglub a écrit:

1. la fonction get_tplconf, écrite comme cela :

Code:

function get_tplconf($key)
{
  global $tplconf;

  return isset($tplconf[$key]) ? $tplconf[$key] : $key;
}

n'a pas de sens. A quoi sert de renvoyer la clef ? (à rien)

2. theme/*/tplconf.inc.php devrait s'appeler themeconf.inc.php vu l'arborescence

3. je trouve l'arborescence trop complexe. Je n'arrive pas à comprendre pourquoi par exemple tu mets les icones dans template-common (sémantiquement, j'aurai choisi theme-common). Par ailleurs le fait que theme/yoga-clear ne soit pas dans template/yoga me gène un peu. Imaginons qu'un jour il y ait un nouveau template complètement différent de yoga, que nous nommerons "jumbo" (du nom des couches de mon fils en ce moment), on ne saurait plus quels themes vont avec quels templates.

Je te propose une simplification :

Code:

template
|-- jumbo
|   |-- *.css
|   |-- *.tpl
|   |-- icon
|   `-- theme
|       |-- baby
|       |   `-- theme_conf.inc.php
|       |-- crystal
|       |   |-- default-layout.css
|       |   |-- images
|       |   |   `-- tableh1_bg.png
|       |   `-- theme_conf.inc.php
|       `-- piglet
|           |-- icon
|           `-- theme_conf.inc.php
`-- yoga
    |-- *.css
    |-- *.tpl
    |-- icon
    `-- theme
        |-- clear
        |   `-- theme_conf.inc.php
        |-- dark
        |   |-- default-layout.css
        |   |-- images
        |   |   `-- tableh1_bg.png
        |   `-- theme_conf.inc.php
        `-- pooh
            |-- icon
            `-- theme_conf.inc.php

Ainsi on pourrait avoir les couples template/theme suivants : jumbo/baby, jumbo/crystal, jumbo/piglet, yoga/clear, yoga/dark, yoga/pooh. Cette liste serait proposée dans profile.php.

Cela ne casse pas ton principe de surchargement tout en étant à mon avis plus simple en terme d'arborescence. Qu'en penses-tu ?

edit : j'ai écris ce post avant que tu édites le tien... j'ai l'impression que nos opinions se rejoignent.

A propos de la fonction get_tplconf... écrire une fonction qui renvoie $tplconf[$key] au lieu d'aller chercher directement $tplconf[$key] évite d'avoir à rendre global $tplconf dans toutes les fonctions qui ont besoin de $tplconf. Bref,

function get_themeconf ($key)
{
  $global $themeconf;

  return $themeconf[$key];
}

(j'ai donc remplacé "tpl" par "theme" puisqu'il s'agit de la configuration du theme et pas du template)

chrisaga a écrit:

ce que tu propose comporte un niveau de profondeur de plus. En quoi est-ce moins complexe ?

Ajouter une niveau de profondeur n'apporte pas de complexité à mon sens. C'est surtout moins complexe car on identifie clairement un template qui peut être légèrement modifié par un theme. Si on veut une modification lourde, alors il faut un nouveau template.

Ce que nous -//:---\spam le système actuel, c'est que le niveau "theme" est manquant et que dupliquer un tempalte entier uniquement pour changer la couleur des liens et la largeur de la menubar, c'est stupide. (j'ai le droit de le dire, c'est ma faute) Enfin, c'est dommage surtout. Cela a ralenti la livraison en standard du template yoga-dark alors que s'il avait s'agit d'un thème, nous l'aurions certainement intégré immédiatement en standard en gestion de version.

Pour le moment, dans l'histoire de PhpWebGallery, en 4 ans, je n'ai vu que deux vraies modifications lourdes du template faite par torode (dont le site est malheureusement en travaux au 27 novembre 2005) et par jillij pour son intégration de PhpWebGallery dans Wordpress. Ce type de modification rare nécessite la possibilité de faire des templates aditionnels. Mais dans l'extrêmement grande majorité des cas, c'est du theme dont on a besoin. C'est pour cela que je trouve personnellement inutile template-common. Le jeu d'icône dans le template, ça me semble plutôt normal. Dupliquer un jeu d'icône, c'est vraiment rien du tout, d'autant que ce sera rarement utile. Et même si c'est utile uniquement pour un theme donné, on peut très bien comme dans jumbo/piglet redéfinir un jeu d'icône au niveau du theme.

Maintenant à propos de la séparation template et theme au même niveau d'arborescence, je maintiens ma position, surtout qu'elle semble opposée à une simple difficulté technique (complexification de la fonction get_templates) : un theme dépend d'un template donné, à ce titre, les thèmes d'un template devrait être dans le répertoire du template.

Passons à la petite difficulté technique, la fonction get_templates ou get_themes. Elle doit nous présenter <nom du template>/<nom du theme>. C'est ainsi que nous le stockerions en base de données dans le champ user_infos.template (à renommer éventuellement en quelque chose de plus générique comme user_infos.layout).

function get_themes()
{
  $themes = array();

  foreach (get_dirs(PHPWG_ROOT_PATH.'template') as $template)
  {
    foreach (get_dirs(PHPWG_ROOT_PATH.'template/'.$template.'/theme' as $theme)
    {
      array_push($themes, $template.'/'.$theme);
    }
  }

  return $themes;
}

Il faudra ensuite dans include/common.inc.php découper $user['template'] récupéré dans phpwebgallery_user_infos.template en 2 : $user['template'] et $user['theme']. A améliorer bien sûr car on doit redéfinir une variable et c'est bof... certainement que le changement du nom de la colonne en phpwebgallery_user_infos.layout rendra cela plus clair.

// include template/theme configuration
list($user['template'], $user['theme']) = explode('/', $user['template']); // TODO : replace initial $user['template'] by $user['layout']

include(PHPWG_ROOT_PATH.'theme/'.$user['template'].'/theme/'.$user['theme'].'/theme_conf.inc.php');
$template = new Template(PHPWG_ROOT_PATH.'template/'.$user['template']); // or $themeconf['template'], should be equal