[spip-dev] Un plugin Layout Gala ?

Youp,

Dans le cadre de la mise en plugins de certains éléments du core, je me
disais qu'il serait sensé de passer en extension les squelettes de la
dist, c'est-à-dire une grande partie (pas tous[1]) des fichiers du
répertoire squelettes-dist/ actuel. Ça serait un plugin Layout Gala, en
gros.

Plus j'y pense et plus ça me semble une évidence. En effet, SPIP
regarde (si j'ai bien tout suivi) les répertoires dans cet ordre :
1. squelettes/
2. plugins/*/
3. extensions/*/
4. squelettes-dist/

Les extensions, apparues récemment, fournissent entre autres un
mécanisme générique de "squelettes par défaut présents à
l'installation", du coup le traitement spécifique que représente
squelettes-dist/ n'est plus vraiment nécessaire.

Je préfère poser la question (avec des pincettes) tout d'abord parce
qu'il y a peut-être une évidence technique que j'aurais loupée et qui
ferait que c'est pas possible, et surtout parce que SPIP (comme tout
projet) semble regorger de sensibilités et de questions personnelles ou
inter-personnelles dont j'ignore encore probablement tout. Pis, ben,
psychologiquement, je me dis que squelettes-dist/ ça se touche pas
comme ça, quoi.

Évidemment, j'ai pas comme projet, même secret, de congédier la dist
actuelle. Certes j'aime pas le mauve, mais ça a rien à voir, et puis je
trouve que Layout Gala c'est une chouette invention. C'est juste un truc
de structure du code.

Du coup, dites.

[1] Par exemple, je trouve que des fichiers tels que robots.txt.html
ont vocation à rester dans le core, ou en tout cas n'ont pas leur place
dans un éventuel plugin Layout Gala. Idem pour le sitemap ou les
nouveautes.html.

Yo,

layout gala est super (perso je l'utilise tout le temps), mais ça ne concerne que le layout, comme son nom l'indique.

Je pense que le mouvement serait plus de passer le squelettes-dist en Z,
et tu as raison sur le point que l'on pourra supprimer la spécificité 'squelettes-dist' au profit d'une extension 'squelettes-dist' :stuck_out_tongue:
Avec l'avantage de permettre aux nostalgiquex ou inconditionnels de la dist actuelle (monobloc) de la remettre en lieu et place de celle en Z que l'on proposerait par défaut.

Cédric

Je crois que les extensions sont chargées avant les plugins, il faudra
inverser si on veut que ce soit viable.

-- Fil

layout gala est super (perso je l'utilise tout le temps), mais ça ne concerne que le layout, comme son nom l'indique.

Dans le genre, je pensais plutôt à un plugin (donc pas obligatoire) de configuration de dist, qui regrouperait des contrib telles que Pétronille (des styles par défaut), LayoutGala (un choix parmi 40 modèles) et autres.

Je pense que le mouvement serait plus de passer le squelettes-dist en Z,

C'est une bonne idée. Je suis néanmoins très embêtée par l'approche par type d'objet SPIP (article, rubrique, etc) que cela impose, que l'on pouvait plus facilement contourner en partant de la dist...

Personnellement, ça fait quelques années que je ne fais plus de squelette 'article', 'rubrique' etc., mais un unique à la place squelette, pour telle 'partie' d'un site, lequel affichera une rubrique ou un article ou... selon l'ID environnant. La méthode Z contrarie et complexifie cette approche, et je la ressens comme régressive, avec le retour des fichiers numérotés (rubrique-3.html, article-3.html) qui plus est en grande quantité. Veut-on vraiment pérenniser cela ?

-- Romy

07/06/10, cedric.morin@yterium.com:

Je pense que le mouvement serait plus de passer le squelettes-dist en
Z,

L'un n'empêche pas l'autre : pour l'instant je propose simplement une
simplification du mécanisme, en généralisant squelettes-dist au profit
des extensions. Dans un second temps ça sera simplement une question de
quelle est l'extension à fournir dans telle ou telle distribution de
SPIP : le truc mauve, Z, etc.

Bonjour,

La méthode Z contrarie et complexifie cette approche, et je la ressens comme régressive, avec le retour des fichiers numérotés (rubrique-3.html, article-3.html) qui plus est en grande quantité. Veut-on vraiment pérenniser cela ?

Pourquoi n'apparaît-il pas dans les multiples propositions d'url propres un format :
le-titre-de-l-article-art3.html
le-nom-de-rubrique-rub5.html
...
qui allie un nom en clair pour moteurs de recherche et identifiant unique d'objet par le numéro ?

A quoi bon ?

-Nicolas

07/06/10, Fil:

Je crois que les extensions sont chargées avant les plugins, il faudra
inverser si on veut que ce soit viable.

J'arrive pas à voir où c'est défini pour confirmer que l'ordre est
incorrect, et comment le changer le cas échéant.

Je suppute que c'est dans la fonction _chemin(), puisque c'est là que
certains parcours et listes de répertoires semblent définis, mais nulle
mention des plugins, et encore moins des extensions.

Ce mécanisme de détermination des chemins est pour le moins cryptique.
Sans parler de documentation, reste-t-il des traces même éparses
d'échanges de mails, de logs de commits, ou même, n'ayons pas peur des
mots, de logs IRC qui permettraient aux nouveaux arrivants, aux nuls en
chinois, et autres contributeurs ponctuels potentiels d'en dénouer une
partie ?

07/06/10, Fil:

Je crois que les extensions sont chargées avant les plugins, il faudra
inverser si on veut que ce soit viable.

J'arrive pas à voir où c'est défini pour confirmer que l'ordre est
incorrect, et comment le changer le cas échéant.

Je suppute que c'est dans la fonction _chemin(), puisque c'est là que
certains parcours et listes de répertoires semblent définis, mais nulle
mention des plugins, et encore moins des extensions.

te voila sur le _chemin() de la découverte ...

Ce mécanisme de détermination des chemins est pour le moins cryptique.
Sans parler de documentation, reste-t-il des traces même éparses
d'échanges de mails, de logs de commits, ou même, n'ayons pas peur des
mots, de logs IRC qui permettraient aux nouveaux arrivants, aux nuls en
chinois, et autres contributeurs ponctuels potentiels d'en dénouer une
partie ?

En fait, chaque appel à la fonction _chemin($dir) ajoute le répertoire $dir en tête du PATH (ou presque en tête, car si un $dossier_squelettes est défini, il reste toujours sur le haut de la pile). Si _chemin() est appelé avec un 'dir1:dir2:dir3', ces 3 chemins sont placés en tête du path dans le meme ordre (donc dir1 se retrouve en tête du path).

Ensuite, la construction du path complet est réalisée par les fonctions de compilation de chargement des plugins, dans inc/plugin :
- liste_plugin_valides() liste et ordonne les plugins selon leur arbre de dépendance. le tableau $ordre qui en ressort liste donc les plugins avec en premier ceux qui sont les moins prioritaires, et en dernier ceux celui qui passe en priorité sur les autres :
  - le plus prioritaire doit arriver en dernier dans les pipeline() pour pouvoir effacer/modifier ce qu'ont fait les autres plugins
  - le plus prioritaire doit arriver en premier dans le path pour que ses fichiers soient pris en priorité dans les include_spip()

La fonction ecrire_plugin_actifs() utilise cette liste de plugins ordonnés pour construire les fichiers
tmp/cache/charger_plugins_chemin.php
tmp/cache/charger_pipelines.php
tmp/cache/charger_plugin_fonctions.php
tmp/cache/charger_plugin_options.php

qui sont inclus à chaque hit au moment opportun.
Et là, en revoyant tout cela et en lisant le code généré, je constate que tout est bon :slight_smile:
J'ai dans tmp/cache/charger_plugins_chemin.php :

_chemin(implode(':',array(_DIR_PLUGIN_COMPRESSEUR,_DIR_PLUGIN_DOCUMENTAIRE,_DIR_PLUGIN_GESTDOC,_DIR_PLUGIN_COMMENTS.'feed/',_DIR_PLUGIN_COMMENTS,_DIR_PLUGIN_CACHE_COOL,_DIR_PLUGIN_AGENDA,_DIR_PLUGIN_ZENGARDEN,_DIR_PLUGIN_WEBFONTS,_DIR_PLUGIN_TROMBI,_DIR_PLUGIN_Z,_DIR_PLUGIN_LETTRES.'spip20/',_DIR_PLUGIN_LETTRES,_DIR_PLUGIN_SPIP_BONUX,_DIR_PLUGIN_SKELEDITOR.'spip_210/',_DIR_PLUGIN_MEDIABOX,_DIR_PLUGIN_QUEUE,_DIR_PLUGIN_GRAVATAR,_DIR_PLUGIN_FACTEUR,_DIR_PLUGIN_CFG,_DIR_PLUGIN_BANDO,_DIR_PLUGIN_OPENID.'spip_2_1',_DIR_PLUGIN_OPENID.'./',_DIR_PLUGIN_SAFEHTML,_DIR_PLUGIN_PORTE_PLUME,_DIR_PLUGIN_MSIE_COMPAT,_DIR_PLUGIN_IMAGES)));

Ce qui signifie que les extensions safehtml, porte_plume, msie_compat, images apparaissent bien en dernier dans le path.
Le cas du compresseur qui apparait en premier est lié à une dépendance : il indique qu'il utilise un autre plugin et du coup est ajouté en fin de liste (pas forcèment juste après le plugin qu'il utilise).

Dans les pipelines on a bien quelque chose de cohérent :

// Pipeline autoriser
function execute_pipeline_autoriser(&$val){
if (file_exists($f=_ROOT_EXTENSIONS.'porte_plume/porte_plume_pipelines.php')){include_once($f);}
if (file_exists($f=_ROOT_PLUGINS.'bandeau/bando_autoriser.php')){include_once($f);}
if (file_exists($f=_ROOT_PLUGINS.'facteur/inc/facteur_autorisations.php')){include_once($f);}
if (file_exists($f=_ROOT_PLUGINS.'skeleditor/spip_210/inc/skeleditor_autoriser.php')){include_once($f);}
if (file_exists($f=_ROOT_PLUGINS.'spip-lettres/inc/lettres_autorisations.php')){include_once($f);}
if (file_exists($f=_ROOT_PLUGINS.'agenda/agenda_autoriser.php')){include_once($f);}
if (file_exists($f=_ROOT_PLUGINS.'comments/comments-200/comments_pipelines.php')){include_once($f);}
if (file_exists($f=_ROOT_PLUGINS.'mediatheque/gestdoc_autoriser.php')){include_once($f);}
$val = minipipe('porte_plume_autoriser', $val);
$val = minipipe('bando_autoriser', $val);
$val = minipipe('facteur_autoriser', $val);
$val = minipipe('skeleditor_autoriser', $val);
$val = minipipe('lettres_autoriser', $val);
$val = minipipe('trombi_autoriser', $val);
$val = minipipe('agenda_autoriser', $val);
$val = minipipe('comments_autoriser', $val);
$val = minipipe('gestdoc_autoriser', $val);
$val = minipipe('documentaire_autoriser', $val);
return $val;
}

Donc tout est bon !

Cédric

ne idée. Je suis néanmoins très embêtée par l'approche par type d'objet SPIP (article, rubrique, etc) que cela impose, que l'on pouvait plus facilement contourner en partant de la dist...

Personnellement, ça fait quelques années que je ne fais plus de squelette 'article', 'rubrique' etc., mais un unique à la place squelette, pour telle 'partie' d'un site, lequel affichera une rubrique ou un article ou... selon l'ID environnant. La méthode Z contrarie et complexifie cette approche, et je la ressens comme régressive, avec le retour des fichiers numérotés (rubrique-3.html, article-3.html) qui plus est en grande quantité. Veut-on vraiment pérenniser cela ?

-- Romy

Bonjour Romy,
je souhaiterais comprendre en quoi l'approche Z implique le retour de squelettes numérotés (rubrique-3.html...) par rapport à d'autres squelettes ?

J'utilise des squelettes Z depuis quelques mois et j'ai jamais eu besoin d'avoir recours à des squelettes numérotés. J'utilise Composition au besoin pour différencier différentes rubriques.

Cordialement

Joseph

Ça fait longtemps que j'aimerais documenter ça, sans en avoir le temps...

Faire un site (SPIP ou pas SPIP) commence par la conception d'une maquette fonctionnelle, laquelle liste les « pages » nécessaires au bon fonctionnement du site. À ce stade, une « page » n'est pas strictement équivalente à une page web, ni à un gabarit HTML, ni à un squelette SPIP, ni à un type de contenu SPIP. Elle correspond à une partie du site.

Ce sont plutôt ces « pages » que je mets en squelettes, indépendamment du type de contenu SPIP.
- Je commence toujours par surcharger tous les skel de SPIP de façon à ce qu'ils affichent une page d'erreur 404, sauf article.html et sommaire.html (voir ma « trousse à têtue »)
- S'il y a une galerie photo dans mon site, je crée un skel photo.html etc. et je programme ainsi chaque partie du site, indépendamment des autres. C'est lisible, modulaire, confortable.
Par exemple, toutes les pages de l'agenda du site de cette compagnie de théâtre sont générées par le seul squelette agenda.html ; celui-ci contient UNE boucle événements, qui affiche un événement seul lorsque ce squelette est appelé avec un id_evenement, ou la liste des événements associés à un article lorsqu'il est appelé avec un id_article, ou etc.
Je traite aussi le head au cas par cas : ici, mon agenda doit rester en robots content none, qu'on ait appelé un article ou la rubrique, ou...
La majorité de mes squelettes sont ainsi construits sur une boucle centrale avec des critères conditionnels (typiquement : {id_article ?}{branche ?}{id_mot ?}). Dans cette logique, je n'utilise pas de skel rubrique.html ni mot.html (puisqu'ils font la même chose, pourquoi dupliquer !?), mais un skel liste.html avec {branche ?}{id_mot ?}.
Bref, je fais non pas un squelette par type d'objet SPIP mais un skel par type de page du site.
- Je ventile les contenus vers les pages qui leur convient en programmant quelques skel article.html et rubrique.html à la racine du site, de façon à ce que tous les trucs contenus dans la rubrique 5 et ses enfants, par exemple, affiche bien l'agenda. Ou mieux, en affectant des mots-clefs.
Ce serait mieux de programmer cela en amont pour éviter cette étape d'inclusion et idéalement la rendre

Cette approche par page fonctionnelle est fondamentale car elle à la base de tout site et j'aime pouvoir l'avoir dans SPIP. Mais :
- Le plugin composition ne répond pas car il permet d'affecter une compo à chaque type d'objet SPIP alors que le besoin est d'affecter une compo à toute une partie de site, quelques soient les types d'objet qu'elle contient !
- SPIP ne permet pas simplement de tester la branche (je rêve d'un #ID_BRANCHE !)
- Il faudrait certainement que je me fasse une séance de ZPIP pour confronter cette ma méthode avec Cédric pour voir où ça bloque et où améliorer... Pour créer l'agenda sur mon dernier site, avec ZPIP, il a fallu un skel navigation/article-2.html pour inclure le skel navigation/rubrique-2.html, idem pour le contenu, sans oublier evenement.html, ce qui rend l'arbo incompréhensible (mais on s'en fout puisque ça n'emmerde que le webmestre, moi en l'occurrence) et une telle démultiplication de fichiers me fait douter de l'avantage.

-- Romy

Ce sont plutôt ces « pages » que je mets en squelettes, indépendamment du type de contenu SPIP.
- Je commence toujours par surcharger tous les skel de SPIP de façon à ce qu'ils affichent une page d'erreur 404, sauf article.html et sommaire.html (voir ma « trousse à têtue »)
- S'il y a une galerie photo dans mon site, je crée un skel photo.html etc. et je programme ainsi chaque partie du site, indépendamment des autres.. C'est lisible, modulaire, confortable.
Par exemple, toutes les pages de l'agenda du site de cette compagnie de théâtre sont générées par le seul squelette agenda.html ; celui-ci contient UNE boucle événements, qui affiche un événement seul lorsque ce squelette est appelé avec un id_evenement, ou la liste des événements associés à un article lorsqu'il est appelé avec un id_article, ou etc.
Je traite aussi le head au cas par cas : ici, mon agenda doit rester en robots content none, qu'on ait appelé un article ou la rubrique, ou...
La majorité de mes squelettes sont ainsi construits sur une boucle centrale avec des critères conditionnels (typiquement : {id_article ?}{branche ?}{id_mot ?}). Dans cette logique, je n'utilise pas de skel rubrique.html ni mot.html (puisqu'ils font la même chose, pourquoi dupliquer !?), mais un skel liste.html avec {branche ?}{id_mot ?}.
Bref, je fais non pas un squelette par type d'objet SPIP mais un skel par type de page du site.
- Je ventile les contenus vers les pages qui leur convient en programmant quelques skel article.html et rubrique.html à la racine du site, de façon à ce que tous les trucs contenus dans la rubrique 5 et ses enfants, par exemple, affiche bien l'agenda. Ou mieux, en affectant des mots-clefs.
Ce serait mieux de programmer cela en amont pour éviter cette étape d'inclusion et idéalement la rendre

Cette approche par page fonctionnelle est fondamentale car elle à la base de tout site et j'aime pouvoir l'avoir dans SPIP. Mais :
- Le plugin composition ne répond pas car il permet d'affecter une compo à chaque type d'objet SPIP alors que le besoin est d'affecter une compo à toute une partie de site, quelques soient les types d'objet qu'elle contient !
- SPIP ne permet pas simplement de tester la branche (je rêve d'un #ID_BRANCHE !)
- Il faudrait certainement que je me fasse une séance de ZPIP pour confronter cette ma méthode avec Cédric pour voir où ça bloque et où améliorer... Pour créer l'agenda sur mon dernier site, avec ZPIP, il a fallu un skel navigation/article-2.html pour inclure le skel navigation/rubrique-2.html, idem pour le contenu, sans oublier evenement.html, ce qui rend l'arbo incompréhensible (mais on s'en fout puisque ça n'emmerde que le webmestre, moi en l'occurrence) et une telle démultiplication de fichiers me fait douter de l'avantage.

-- Romy

Merci Romy pour ce long mail même s'il n'est pas simple de tout se représenter sans exemple concret.

Aurais-tu un exemple de page article ?

Avec Zpip, me semble-t-il, rien ne t'interdit de créer contenu/photo.html, navigation/photo.html, contenu/agenda.html, navigation/agenda.html... puis, dans article.html (à la racine), d'inclure le squelette structure.html en modifiant la variable type par photo ou agenda selon que tu sois dans la branche 5 ou la branche 8.

Dès lors, tu retrouves ton fonctionnement avec une page photo, une page agenda etc. et non une page par objet SPIP.

Cordialement

Joseph

08/06/10, cedric.morin@yterium.com:

En fait, chaque appel à la fonction _chemin($dir) [...]

Merci pour ces explications. Je les ai transformées en documentation
des fonctions en question :
http://trac.rezo.net/trac/spip/changeset/15738

Je n'ai fait qu'une documentation fonction par fonction ; il manque
peut-être toujours une vue d'ensemble sur toute la chaîne, mais je sais
pas trop où et sous quelle forme ça serait bien (pis j'ai pas une vue
sur toute la chaîne).

Donc tout est bon !

Génial.

Merci d'avoir regardé tout ça, et partagé tes informations.

Bonsoir Romy,

La majorité de mes squelettes sont ainsi construits sur une boucle centrale avec des critères conditionnels (typiquement : {id_article ?}{branche ?}{id_mot ?}).

...

Cette approche par page fonctionnelle est fondamentale car elle à la base de tout site et j'aime pouvoir l'avoir dans SPIP. Mais :

...

- SPIP ne permet pas simplement de tester la branche (je rêve d'un #ID_BRANCHE !)

tu devrais décrire précisément dans un ticket ce qui te manque, qu'on puisse y revenir en profondeur quand j'en aurais le temps.

Committo,Ergo:Sum