[spip-dev] $GLOBALS['dossier_squelettes'] mal exploité ...

Bonjour,

si dans mon fichier "mes_fonctions.php3" je mets l'instruction
suivante :

$GLOBALS['dossier_squelettes'] = 'data/skel';

Tout va bien pour les squelettes que j'ai redéfini, mais rien ne va
pour les squelettes par défaut que je n'ai pas personnalisé. SPIP ne
trouve pas les "*-dist.html" dans le répertoire 'data/skel' ...

-Nicolas

si dans mon fichier "mes_fonctions.php3" je mets l'instruction
suivante :

$GLOBALS['dossier_squelettes'] = 'data/skel';

Tout va bien pour les squelettes que j'ai redéfini, mais rien ne va
pour les squelettes par défaut que je n'ai pas personnalisé. SPIP ne
trouve pas les "*-dist.html" dans le répertoire 'data/skel' ...

Envoie le patch ! :wink:

-- Fil

Envoie le patch ! :wink:

Pas du tout le temps de regarder, je ne fais que transmettre le
feedback de quelqu'un d'autre ...

-Nicolas

@ Nicolas Hoizey <nhoizey@php.net> :

> Envoie le patch ! :wink:

Pas du tout le temps de regarder, je ne fais que transmettre le
feedback de quelqu'un d'autre ...

Ah, OK, réponds-lui que c'est normal, alors ; c'est même un choix de
sécurité, qui permet d'éviter qu'un nouveau squelette introduit
subrepticement par l'équipe de spip laisse apparaître des données
confidentielles :wink:

-- Fil

Ah, OK, réponds-lui que c'est normal, alors ; c'est même un choix de
sécurité, qui permet d'éviter qu'un nouveau squelette introduit
subrepticement par l'équipe de spip laisse apparaître des données
confidentielles :wink:

???

-Nicolas

si dans mon fichier "mes_fonctions.php3" je mets l'instruction
suivante :
$GLOBALS['dossier_squelettes'] = 'data/skel';
Tout va bien pour les squelettes que j'ai redéfini, mais rien ne va
pour les squelettes par défaut que je n'ai pas personnalisé. SPIP
ne trouve pas les "*-dist.html" dans le répertoire 'data/skel' ...

Envoie le patch ! :wink:

Voilà un code qui marche :

function chercher_squelette_hierarchie($fond, $id_rubrique) {
        global $dossier_squelettes;
        if (!$id_rubrique) {
                if (file_exists("$dossier_squelettes/$fond.html")) {
                        return "$dossier_squelettes/$fond";
                } else if (file_exists("$fond-dist.html")) {
                        return "$fond-dist";
                } else {
                        // erreur webmaster : $fond ne correspond a rien
                        include_local ("ecrire/inc_presentation.php3");
                        install_debut_html("Erreur sur le site");
                        echo "<P>Aucun squelette <b>$fond</b> n'est disponible...</P>";
                        install_fin_html();
                        exit;
                }
        }
        else {
                if (file_exists("$dossier_squelettes/$fond-$id_rubrique.html")) {
                        return "$dossier_squelettes/$fond-$id_rubrique";
                } else {
                        $query = "SELECT id_parent FROM spip_rubriques WHERE id_rubrique='$id_rubrique'";
                        $result = spip_query($query);
                        while($row = spip_fetch_array($result)) {
                                $id_parent=$row['id_parent'];
                        }
                        return chercher_squelette_hierarchie($fond, $id_parent);
                }
        }
}

function chercher_squelette($fond, $id_rubrique) {
        global $dossier_squelettes;

        // prendre en compte le bon repertoire (pas grave si on a deux / dans l'arborescence)
        if (!isset($dossier_squelettes)) $dossier_squelettes = '.';
        
        // On selectionne, dans l'ordre :
        // fond=10.html, fond-10.html, fond-<rubriques parentes>.html, fond.html puis fond-dist.html
        if (($id_rubrique > 0) AND (file_exists($dossier_squelettes.'/'.$fond."=$id_rubrique.html"))) {
                return "$fond=$id_rubrique";
        }
        else {
                return chercher_squelette_hierarchie($fond, $id_rubrique); // recursif le long de la hierarchie
        }
}

-Nicolas

Parce qu'on est proche de la sortie de la 1.5.

pourquoi cela n'est-il pas dans la dernière version ???
===8<==============Original message text===============
>> si dans mon fichier "mes_fonctions.php3" je mets l'instruction
>> suivante :
>> $GLOBALS['dossier_squelettes'] = 'data/skel';

-- Fil

Parce qu'on est proche de la sortie de la 1.5.

Je l'ai envoyé il y a déjà 5 jours, et il me semble que c'est un bug
plutôt gênant, non ???

-Nicolas

Je l'ai envoyé il y a déjà 5 jours

So what ?

et il me semble que c'est un bug plutôt gênant, non ???

Pour moi ça n'est pas un bug : si le squelette n'est pas là, tant pis. J'ai
pas le temps de tester ton patch avant quelques jours, je ne le commite pas
en pleine phase finale, voilà tout.

En plus, il n'est pas certain que ça soit une "feature" vraiment voulue : ça
se discute... si tu as un jeu de squelettes incomplet dans ton
$dossier_squelettes, c'est peut-être voulu (ie, quelqu'un qui voudrait
subrepticement regarder un contenu qui est "protégé" dans article.html en
passant par backend-dist.html se verrait barrer la route, alors qu'avec ton
patch il passe).

-- Fil

Je l'ai envoyé il y a déjà 5 jours

So what ?

Vous êtes tous occupés, d'accord, je sais ce que c'est, mais tu m'a
demandé un patch, donc j'ai cherché et proposé une solution.

Je n'ai eu ensuite aucune remarque, même pas celle qui suit ...

et il me semble que c'est un bug plutôt gênant, non ???

Pour moi ça n'est pas un bug : si le squelette n'est pas là, tant
pis.

Avant, on pouvait mettre les squelettes personnalisés dans un
répertoire, il suffisait de mettre le répertoire en question dans le
$fond correspondant.

Depuis l'apparition du $GLOBALS['dossier_squelettes'], on peut ne
mettre qu'une fois l'instruction dans le 'mes_fonctions.php3'.

Je pense que plusieurs utilisateurs, dont moi, voient là dedans une
simplification pour isoler les squelettes personnalisés, mais que
personne n'en a déduit qu'il faut du même coup recopier tous les
squelettes non personnalisés dans ce même répertoire.

J'ai pas le temps de tester ton patch avant quelques jours, je ne le
commite pas en pleine phase finale, voilà tout.

OK si ce n'est pas vu comme un bug, mais si c'est vu comme tel, il est
à mon avis inaproprié de sortir la release avec des bugs déjà
identifiés.

En plus, il n'est pas certain que ça soit une "feature" vraiment
voulue : ça se discute... si tu as un jeu de squelettes incomplet
dans ton $dossier_squelettes, c'est peut-être voulu (ie, quelqu'un
qui voudrait subrepticement regarder un contenu qui est "protégé"
dans article.html en passant par backend-dist.html se verrait barrer
la route, alors qu'avec ton patch il passe).

Utiliser ce répertoire pour "protéger" des contenus en interdisant
certains squelettes, ça n'a jamais été envisagé auparavant, ce n'était
pas l'objectif initial. Mais bon, je n'ai pas de contre argument,
forcément.

-Nicolas

Je n'ai eu ensuite aucune remarque, même pas celle qui suit ...

Non, je te l'avais faite avant :wink:

Mais honnêtement, avec plusieurs milliers de mails par semaine, une version
à débugguer, la documentation à mettre à jour (*), et nos boulots normaux en
plus de tout ça, je trouve ta remarque un poil trop agressive. Autrement
dit, que tu aies des clients à contenter, c'est ton problème, pas le nôtre.

(*) Si ce qui t'intéresse c'est que spip fonctionne bien, tu peux aussi
aller dans l'espace privé d'uZine, et mettre des messages de forums sous les
pages de la doc à modifier, par exemple... ce qui n'est pas hors-sujet, voir
ci-dessous.

Je pense que plusieurs utilisateurs, dont moi, voient là dedans une
simplification pour isoler les squelettes personnalisés, mais que
personne n'en a déduit qu'il faut du même coup recopier tous les
squelettes non personnalisés dans ce même répertoire.

Oui, chacun sa logique. Comment faire que la logique qu'on propose soit la
plus facile à comprendre ? Pense à l'utilisateur qui teste
$dossier_squelettes et qui voit que son site continue à fonctionner sans
problèmes : il peut se dire que la fonctionnalité ne marche pas (puisqu'il
n'a pas encore mis de squelette dans le répertoire en question, et que les
pages s'affichent quand même). Ca peut être perturbant. C'est une question
de documentation.

OK si ce n'est pas vu comme un bug, mais si c'est vu comme tel, il est
à mon avis inaproprié de sortir la release avec des bugs déjà
identifiés.

Maintenant que tu me pousses à y réfléchir d'urgence, je crois que ça n'est
pas un bug, et qu'il faut plutôt ne rien toucher, documenter clairement
cette "variable de personnalisation", et permettre aux utilisateurs de
comprendre ce qui se passe plutôt que d'essayer un truc abracadabrantesque
pour retrouver à toute force un squelette-dist : la page "Erreur, le
squelette dossier_squelettes/article.html n'existe pas" est là pour ça.

Utiliser ce répertoire pour "protéger" des contenus en interdisant
certains squelettes, ça n'a jamais été envisagé auparavant, ce n'était
pas l'objectif initial. Mais bon, je n'ai pas de contre argument,

Non, c'était un exemple mal choisi, ce n'est pas un argument valide, je te
l'accorde.

-- Fil (offline pour les trois jours prochains)

Je n'ai eu ensuite aucune remarque, même pas celle qui suit ...

Non, je te l'avais faite avant :wink:

Tu fais référence à ce message :

que je n'avais pas du tout compris :

Soit.

Mais honnêtement, avec plusieurs milliers de mails par semaine, une
version à débugguer, la documentation à mettre à jour (*), et nos
boulots normaux en plus de tout ça, je trouve ta remarque un poil
trop agressive.

Je ne suis pas du tout aggressif ! J'attirais l'attention sur ce que
je considère comme un bug, et je trouvais dommage de faire une release
en version 1.5 avec au moins un bug identifié.

Autrement dit, que tu aies des clients à contenter, c'est ton
problème, pas le nôtre.

C'est pas aggressif, ça ? :frowning:

Ce cas ne s'est pas présenté chez un client ! Quand j'ai un problème
sur un SPIP utilisé chez un client, je cherche moi-même, je ne demande
pas à la liste SPIP de trouver pour moi !

Je ne suis pas sûr de faire partie de ceux qui demandent plus qu'ils
ne donnent, ici, faudrait pas se tromper de bouc émissaire ...

(*) Si ce qui t'intéresse c'est que spip fonctionne bien, tu peux
aussi aller dans l'espace privé d'uZine, et mettre des messages de
forums sous les pages de la doc à modifier, par exemple... ce qui
n'est pas hors-sujet, voir ci-dessous.

Je n'ai jamais vraiment lu la doc, puisque j'utilisais SPIP avant
qu'elle n'existe vraiment, donc je suis vraiment mal placé pour savoir
ce qui ne convient plus dedans ...

Mais c'est surtout le temps qui me manque, comme toujours.

Oui, chacun sa logique. Comment faire que la logique qu'on propose
soit la plus facile à comprendre ? [...] C'est une question de
documentation.

Certes, mais il faut aussi documenter les effets de bord.

Maintenant que tu me pousses à y réfléchir d'urgence, je crois que
ça n'est pas un bug, et qu'il faut plutôt ne rien toucher [...]

OK.

-Nicolas

C'est pas aggressif, ça ? :frowning:

Si, ça l'était, un petit coup de fatigue chez moi, désolé...

> Oui, chacun sa logique. Comment faire que la logique qu'on propose
> soit la plus facile à comprendre ? [...] C'est une question de
> documentation.

Certes, mais il faut aussi documenter les effets de bord.

OK, c'est dans [uZine 3] Les variables de personnalisation
avec un lien depuis [uZine 3] Qu’est-ce que les fichiers « -dist.html » ?

-- Fil

Hello,

C'est pas aggressif, ça ? :frowning:

Si, ça l'était, un petit coup de fatigue chez moi, désolé...

Pas de soucis, on a tous nos moments difficile. Ce n'est pas la
première fois, et sans doute pas la dernière, qu'on s'énerve ici, il
faut savoir en faire abstraction ensuite ... :wink:

J'espère surtout que tes 3 jours off t'on remis d'aplomb !!! :slight_smile:

Certes, mais il faut aussi documenter les effets de bord.

OK, c'est dans [uZine 3] Les variables de personnalisation

Même si le fonctionnement ne me plait toujours pas (je suis lourd,
hein), au moins c'est documenté, donc merci beaucoup !

-Nicolas

Est-ce que les var_xxx sont documentées quelquepart avec exemples d'utilisations pertinents ?
JLuc

Nicolas Hoizey wrote: