[SPIP Zone] expresso met la pression

Bonjour,

J'ai bien du mal avec le plugin expresso et spip.

Je voudrais limiter l'usage dans le squelette article à 13 articles :
- les 10 articles les plus lus de tout le site
- l'article à la une
- les 2 articles les plus récents à la Une dans une certaine rubrique

Pas de probleme c'est fait avec quelques boucles...
mais alors, je découvre que ça percole aussi ces pages
lorsqu'elles ont &debut_forum en url !
et ça je veux pas car ces pages de consultation des forums sont peu appelées
et je n'ai pas envie d'encombrer le cache statique et le htaccess.

Donc je voudrais exclure de ces pages les pages non principales
(exclure celles qui permettent de voir la suite des forums)
et pour cela tester les paramétres de la page
afin de ne pas inclure dans ce cas la balise expresso.

Si je le fais en php, ça marche pas, car spip étant appelé avant le php,
la balise spip expresso est exécutée, or elle n'ajoute pas du texte,
mais modifie le header... donc la modification a lieu
même si la condition n'est pas remplie.
(dîtes moi si je me trompe, mais c'est ce que j'ai conclu)

Les autres méthodes que j'essaie échouent lamentablement !

Déjà, si je met toutes mes boucles expresso dans un squelette à part,
que ce fichier soit <inclu ou #inclu n'y change rien :
les #HEADER_HTTP inclus dedans ne passent jamais la rampe.
(C'est pas conforme à la doc mais c'est ce que j'ai trouvé,
dîtes moi si je dois insister !)

Et sans passer par un fichier inclu, je galère avec le compilo spip
auquel je n'arrive pas pour l'instant à faire avaler le lot de boucles
en paramètre d'une quelconque structure syntaxique.
C'est la première fois que je fais une telle utilisation
des filtres à paramètres enchainés avec des tests et tout,
et j'ai l'impression qu'il y a des limitations imprévues au compilateur.
Me trompai-je et où ça alors ?

Déjà, #EVAL{$_SERVER['REQUEST_URI']} renvoie très bien l'uri de la page
par exemple /article.php?id_article=101&var_mode=calcul
mais ce que je voudrais c'est appeler ensuite un filtre pour faire
[(#EVAL{$_SERVER['REQUEST_URI']}|match{debut_}|?{'',' '})appelexpresso]
et là le compilo comprend pas du tout car ça renvoie [(/article.php?id_article=101&var_mode=recalcul|match{debut_}|?{'',' '})appelexpresso]
Par contre, pas de pb si je remplace $_SERVER['REQUEST_URI'] par time()
J'en ai conclu que c'est une limitation du compilateur,
et en décomposant en passant par un SET préallable,
puis en testant le GET, ça marche.

Mais le probleme se repose ensuite avec les boucles de sélection
des articles pour expresso, qui doivent remplacer appelexpresso dans l'expression ci dessus !
Car si je peux pas les appeler dans un include, il faut bien les passer
in extenso dans une structure syntaxique existante :
[(par exemple en 2eme paramètre de |?{'','ici'})
ou bien ici après le test ]
mais tout cela ne semble pas possible pour le compilo spip.

L'idéal serait de pouvoir tester en critère de boucle
la présence de debut_forum en paramétre de l'url
MAIS {debut_forum, 10} marche même si il n'y a pas debut_forum dans l'url.
(vous confirmez ?)

Mon dernier / ou prochain test / ç'aurait été d'ajouter {#ENV{debut_forums}!=''}
dans les critères de boucles de selection des pages candidates...
Je touche du bois pour qu'on puisse utiliser #ENV en premier élément d'un critère...
Si ça marche, je crois que j'aurais touché le bout de cette exploration !

Mais là mon serveur de test (et prod) est planté
(et je me demande si j'en suis pas la cause avec tous ces tests et erreurs !)
donc j'arrête et vous demande globalement votre avis !

Merci d'avance;
JLuc

JLuc

Hello,

je n'ai pu utiliser un critère {#ENV{debut_forum}=''}
car ça ne semble pas possible dans la grammaire spip.

J'ai donc jeté l'éponge à essayer de tester cela en spip
et l'ai fait en php...

maintenant, mettre <? if (test) header('X-Expresso: true'); ?>
dans le squelette provoque bien l'insertion du header
pour les bonnes pages et pas pour les mauvaises
mais cela n'est pas détecté par le plugin,
qui ni ne génère les fichiers caches, ni ne modifie le htaccess.

Pour détecter le header, expresso teste
isset($GLOBALS['page']['entetes']['X-Expresso'])
Pourquoi cette globale n'est elle pas instanciée
alors que le header a bien été mis par php
tout comme avec #HTTP_HEADER ?
(une histoire de cache ?)

JL

JLuc a écrit :

Bonjour,

J'ai bien du mal avec le plugin expresso et spip.

Je voudrais limiter l'usage dans le squelette article à 13 articles :
- les 10 articles les plus lus de tout le site
- l'article à la une
- les 2 articles les plus récents à la Une dans une certaine rubrique

Pas de probleme c'est fait avec quelques boucles...
mais alors, je découvre que ça percole aussi ces pages
lorsqu'elles ont &debut_forum en url !
et ça je veux pas car ces pages de consultation des forums sont peu appelées
et je n'ai pas envie d'encombrer le cache statique et le htaccess.

Donc je voudrais exclure de ces pages les pages non principales
(exclure celles qui permettent de voir la suite des forums)
et pour cela tester les paramétres de la page
afin de ne pas inclure dans ce cas la balise expresso.

Si je le fais en php, ça marche pas, car spip étant appelé avant le php,
la balise spip expresso est exécutée, or elle n'ajoute pas du texte,
mais modifie le header... donc la modification a lieu
même si la condition n'est pas remplie.
(dîtes moi si je me trompe, mais c'est ce que j'ai conclu)

Les autres méthodes que j'essaie échouent lamentablement !

Déjà, si je met toutes mes boucles expresso dans un squelette à part,
que ce fichier soit <inclu ou #inclu n'y change rien :
les #HEADER_HTTP inclus dedans ne passent jamais la rampe.
(C'est pas conforme à la doc mais c'est ce que j'ai trouvé,
dîtes moi si je dois insister !)

Et sans passer par un fichier inclu, je galère avec le compilo spip
auquel je n'arrive pas pour l'instant à faire avaler le lot de boucles
en paramètre d'une quelconque structure syntaxique.
C'est la première fois que je fais une telle utilisation
des filtres à paramètres enchainés avec des tests et tout,
et j'ai l'impression qu'il y a des limitations imprévues au compilateur.
Me trompai-je et où ça alors ?

Déjà, #EVAL{$_SERVER['REQUEST_URI']} renvoie très bien l'uri de la page
par exemple /article.php?id_article=101&var_mode=calcul
mais ce que je voudrais c'est appeler ensuite un filtre pour faire
[(#EVAL{$_SERVER['REQUEST_URI']}|match{debut_}|?{'',' '})appelexpresso]
et là le compilo comprend pas du tout car ça renvoie [(/article.php?id_article=101&var_mode=recalcul|match{debut_}|?{'',' '})appelexpresso]
Par contre, pas de pb si je remplace $_SERVER['REQUEST_URI'] par time()
J'en ai conclu que c'est une limitation du compilateur,
et en décomposant en passant par un SET préallable,
puis en testant le GET, ça marche.

Mais le probleme se repose ensuite avec les boucles de sélection
des articles pour expresso, qui doivent remplacer appelexpresso dans l'expression ci dessus !
Car si je peux pas les appeler dans un include, il faut bien les passer
in extenso dans une structure syntaxique existante :
[(par exemple en 2eme paramètre de |?{'','ici'})
ou bien ici après le test ]
mais tout cela ne semble pas possible pour le compilo spip.

L'idéal serait de pouvoir tester en critère de boucle
la présence de debut_forum en paramétre de l'url
MAIS {debut_forum, 10} marche même si il n'y a pas debut_forum dans l'url.
(vous confirmez ?)

Mon dernier / ou prochain test / ç'aurait été d'ajouter {#ENV{debut_forums}!=''}
dans les critères de boucles de selection des pages candidates...
Je touche du bois pour qu'on puisse utiliser #ENV en premier élément d'un critère...
Si ça marche, je crois que j'aurais touché le bout de cette exploration !

Mais là mon serveur de test (et prod) est planté
(et je me demande si j'en suis pas la cause avec tous ces tests et erreurs !)
donc j'arrête et vous demande globalement votre avis !

Merci d'avance;
JLuc

JLuc

JLuc a écrit :

Hello,

je n'ai pu utiliser un critère {#ENV{debut_forum}=''}
car ça ne semble pas possible dans la grammaire spip.
  

je ne comprend pas ce que tu attends de ce genre de critère ?
un critère, ca genere une clause dans une boucle, et seul la valeur peut etre dynamique.

tu peux faire :

[(#ENV{debut_forum}|?{' ',''})
  #INLCURE ou <INCLURE>
]

mais je ne connais pas expresso, donc je ne sais pas si ca peut t'aider...

@++

JLuc a écrit :

Hello,

je n'ai pu utiliser un critère {#ENV{debut_forum}=''}
car ça ne semble pas possible dans la grammaire spip.
  

[(#EVAL{_request('debut_forum')}|?{'',' '}) #HTTP_HEAD{...} ]

J'ai donc jeté l'éponge à essayer de tester cela en spip
et l'ai fait en php...

maintenant, mettre <? if (test) header('X-Expresso: true'); ?>
dans le squelette provoque bien l'insertion du header
pour les bonnes pages et pas pour les mauvaises
mais cela n'est pas détecté par le plugin,
qui ni ne génère les fichiers caches, ni ne modifie le htaccess.

Pour détecter le header, expresso teste
isset($GLOBALS['page']['entetes']['X-Expresso'])
Pourquoi cette globale n'est elle pas instanciée
alors que le header a bien été mis par php
tout comme avec #HTTP_HEADER ?
(une histoire de cache ?)
  

simplement parce que, il faut le repeter encore, et encore, et encore :
"le php dans les squelettes n'est pas visible de SPIP, il n'est pas mis en cache, et ses effets ne peuvent etre pris en compte par SPIP. Il n'est évalué que quand la page est envoyée à l'internaute"
CQFD

JL

JLuc a écrit :
  

Bonjour,

J'ai bien du mal avec le plugin expresso et spip.

Je voudrais limiter l'usage dans le squelette article à 13 articles :
- les 10 articles les plus lus de tout le site
- l'article à la une
- les 2 articles les plus récents à la Une dans une certaine rubrique

Pas de probleme c'est fait avec quelques boucles...
mais alors, je découvre que ça percole aussi ces pages
lorsqu'elles ont &debut_forum en url !
et ça je veux pas car ces pages de consultation des forums sont peu appelées
et je n'ai pas envie d'encombrer le cache statique et le htaccess.

Donc je voudrais exclure de ces pages les pages non principales
(exclure celles qui permettent de voir la suite des forums)
et pour cela tester les paramétres de la page
afin de ne pas inclure dans ce cas la balise expresso.

Si je le fais en php, ça marche pas, car spip étant appelé avant le php,
la balise spip expresso est exécutée, or elle n'ajoute pas du texte,
mais modifie le header... donc la modification a lieu
même si la condition n'est pas remplie.
(dîtes moi si je me trompe, mais c'est ce que j'ai conclu)

Les autres méthodes que j'essaie échouent lamentablement !

Déjà, si je met toutes mes boucles expresso dans un squelette à part,
que ce fichier soit <inclu ou #inclu n'y change rien :
les #HEADER_HTTP inclus dedans ne passent jamais la rampe.
(C'est pas conforme à la doc mais c'est ce que j'ai trouvé,
dîtes moi si je dois insister !)

Et sans passer par un fichier inclu, je galère avec le compilo spip
auquel je n'arrive pas pour l'instant à faire avaler le lot de boucles
en paramètre d'une quelconque structure syntaxique.
C'est la première fois que je fais une telle utilisation
des filtres à paramètres enchainés avec des tests et tout,
et j'ai l'impression qu'il y a des limitations imprévues au compilateur.
Me trompai-je et où ça alors ?

Déjà, #EVAL{$_SERVER['REQUEST_URI']} renvoie très bien l'uri de la page
par exemple /article.php?id_article=101&var_mode=calcul
mais ce que je voudrais c'est appeler ensuite un filtre pour faire
[(#EVAL{$_SERVER['REQUEST_URI']}|match{debut_}|?{'',' '})appelexpresso]
et là le compilo comprend pas du tout car ça renvoie [(/article.php?id_article=101&var_mode=recalcul|match{debut_}|?{'',' '})appelexpresso]
Par contre, pas de pb si je remplace $_SERVER['REQUEST_URI'] par time()
J'en ai conclu que c'est une limitation du compilateur,
et en décomposant en passant par un SET préallable,
puis en testant le GET, ça marche.

Mais le probleme se repose ensuite avec les boucles de sélection
des articles pour expresso, qui doivent remplacer appelexpresso dans l'expression ci dessus !
Car si je peux pas les appeler dans un include, il faut bien les passer
in extenso dans une structure syntaxique existante :
[(par exemple en 2eme paramètre de |?{'','ici'})
ou bien ici après le test ]
mais tout cela ne semble pas possible pour le compilo spip.

L'idéal serait de pouvoir tester en critère de boucle
la présence de debut_forum en paramétre de l'url
MAIS {debut_forum, 10} marche même si il n'y a pas debut_forum dans l'url.
(vous confirmez ?)

Mon dernier / ou prochain test / ç'aurait été d'ajouter {#ENV{debut_forums}!=''}
dans les critères de boucles de selection des pages candidates...
Je touche du bois pour qu'on puisse utiliser #ENV en premier élément d'un critère...
Si ça marche, je crois que j'aurais touché le bout de cette exploration !

Mais là mon serveur de test (et prod) est planté
(et je me demande si j'en suis pas la cause avec tous ces tests et erreurs !)
donc j'arrête et vous demande globalement votre avis !

Merci d'avance;
JLuc

JLuc

_______________________________________________
spip-zone@rezo.net - http://listes.rezo.net/mailman/listinfo/spip-zone
  

Stephane a écrit :

JLuc a écrit :

Hello,

je n'ai pu utiliser un critère {#ENV{debut_forum}=''}
car ça ne semble pas possible dans la grammaire spip.
  

je ne comprend pas ce que tu attends de ce genre de critère ?
un critère, ca genere une clause dans une boucle, et seul la valeur peut etre dynamique.

C'est vrai !

tu peux faire :
[(#ENV{debut_forum}|?{' ',''})
  #INLCURE ou <INCLURE>
]

J'ai essayé ça mais le HTTP_HEADER ne marche pas
dans un inclure.
La doc indique que ça ne marche pas avec <inclure
mais m'avait laissé espérer que ça marche avec #,
mais non ...

Et le squelette inclu comporte 3 boucles avec parfois une sousboucle
et donc je ne peux pas l'inclure directement sans inclure,
car le parseur du compilateur spip ne le permet pas.

Merci quand même... :slight_smile:
JL

cedric.morin@yterium.com a écrit :

[(#EVAL{_request('debut_forum')}|?{'',' '}) #HTTP_HEAD{...} ]

J'ai essayé avec $_GET['debut_forums'], ça devrait être pareil
mais ça ne marchait pas. Je vais réessayer.

Pour détecter le header, expresso teste
isset($GLOBALS['page']['entetes']['X-Expresso'])
Pourquoi cette globale n'est elle pas instanciée
alors que le header a bien été mis par php
tout comme avec #HTTP_HEADER ?
(une histoire de cache ?)

simplement parce que, il faut le repeter encore, et encore, et encore :
"le php dans les squelettes n'est pas visible de SPIP, il n'est pas mis en cache, et ses effets ne peuvent etre pris en compte par SPIP. Il n'est évalué que quand la page est envoyée à l'internaute"

Certes :wink: cf "spip et php sont dans un bateau"

> CQFD

$GLOBALS['page']['entetes']['X-Expresso'] est calculé
lors de la fabrication du cache spip ?
ou calculé à sa lecture inclusion exécution ?
(Je n'ai rien trouvé dans le source qui indique où est calculé
cette globale pour des entetes comme X-Expresso, càd non générique )

En tout cas c'est affecté plut tôt que le <?php header ?> n'est exécuté
et a fortiori plus tôt que le pipeline expresso_affichage_final
n'est appelé (c'est dans ce pipeline que c'est testé).
et donc je ne peux m'en sortir avec <?php header ?>.

Mais comment ça se passe pour la balise #HTTP_HEADER ?
Elle arrive à la fois à positionner la globale
et à appeler la fonction header ... dans le bon ordre !

Vu le temps que j'ai passé là dessus, ça devient absolument déraisonnable
de continuer, mais d'autant plus frustrant de rester bloqué là...

JL

JLuc a écrit :
  

Bonjour,

J'ai bien du mal avec le plugin expresso et spip.

Je voudrais limiter l'usage dans le squelette article à 13 articles :
- les 10 articles les plus lus de tout le site
- l'article à la une
- les 2 articles les plus récents à la Une dans une certaine rubrique

Pas de probleme c'est fait avec quelques boucles...
mais alors, je découvre que ça percole aussi ces pages
lorsqu'elles ont &debut_forum en url !
et ça je veux pas car ces pages de consultation des forums sont peu appelées
et je n'ai pas envie d'encombrer le cache statique et le htaccess.

Donc je voudrais exclure de ces pages les pages non principales
(exclure celles qui permettent de voir la suite des forums)
et pour cela tester les paramétres de la page
afin de ne pas inclure dans ce cas la balise expresso.

Si je le fais en php, ça marche pas, car spip étant appelé avant le php,
la balise spip expresso est exécutée, or elle n'ajoute pas du texte,
mais modifie le header... donc la modification a lieu
même si la condition n'est pas remplie.
(dîtes moi si je me trompe, mais c'est ce que j'ai conclu)

Les autres méthodes que j'essaie échouent lamentablement !

Déjà, si je met toutes mes boucles expresso dans un squelette à part,
que ce fichier soit <inclu ou #inclu n'y change rien :
les #HEADER_HTTP inclus dedans ne passent jamais la rampe.
(C'est pas conforme à la doc mais c'est ce que j'ai trouvé,
dîtes moi si je dois insister !)

Et sans passer par un fichier inclu, je galère avec le compilo spip
auquel je n'arrive pas pour l'instant à faire avaler le lot de boucles
en paramètre d'une quelconque structure syntaxique.
C'est la première fois que je fais une telle utilisation
des filtres à paramètres enchainés avec des tests et tout,
et j'ai l'impression qu'il y a des limitations imprévues au compilateur.
Me trompai-je et où ça alors ?

Déjà, #EVAL{$_SERVER['REQUEST_URI']} renvoie très bien l'uri de la page
par exemple /article.php?id_article=101&var_mode=calcul
mais ce que je voudrais c'est appeler ensuite un filtre pour faire
[(#EVAL{$_SERVER['REQUEST_URI']}|match{debut_}|?{'',' '})appelexpresso]
et là le compilo comprend pas du tout car ça renvoie [(/article.php?id_article=101&var_mode=recalcul|match{debut_}|?{'',' '})appelexpresso]
Par contre, pas de pb si je remplace $_SERVER['REQUEST_URI'] par time()
J'en ai conclu que c'est une limitation du compilateur,
et en décomposant en passant par un SET préallable,
puis en testant le GET, ça marche.

Mais le probleme se repose ensuite avec les boucles de sélection
des articles pour expresso, qui doivent remplacer appelexpresso dans l'expression ci dessus !
Car si je peux pas les appeler dans un include, il faut bien les passer
in extenso dans une structure syntaxique existante :
[(par exemple en 2eme paramètre de |?{'','ici'})
ou bien ici après le test ]
mais tout cela ne semble pas possible pour le compilo spip.

L'idéal serait de pouvoir tester en critère de boucle
la présence de debut_forum en paramétre de l'url
MAIS {debut_forum, 10} marche même si il n'y a pas debut_forum dans l'url.
(vous confirmez ?)

Mon dernier / ou prochain test / ç'aurait été d'ajouter {#ENV{debut_forums}!=''}
dans les critères de boucles de selection des pages candidates...
Je touche du bois pour qu'on puisse utiliser #ENV en premier élément d'un critère...
Si ça marche, je crois que j'aurais touché le bout de cette exploration !

Mais là mon serveur de test (et prod) est planté
(et je me demande si j'en suis pas la cause avec tous ces tests et erreurs !)
donc j'arrête et vous demande globalement votre avis !

Merci d'avance;
JLuc

JLuc

_______________________________________________
spip-zone@rezo.net - http://listes.rezo.net/mailman/listinfo/spip-zone
  

JLuc a écrit :

cedric.morin@yterium.com a écrit :

[(#EVAL{_request('debut_forum')}|?{'',' '}) #HTTP_HEAD{...} ]
    
J'ai essayé avec $_GET['debut_forums'], ça devrait être pareil
mais ça ne marchait pas. Je vais réessayer.
  

Et ça va marcher.
Le $_GET ne marchait pas a cause des dans lesquels le compilateur se prend les pieds

  

Pour détecter le header, expresso teste
isset($GLOBALS['page']['entetes']['X-Expresso'])
Pourquoi cette globale n'est elle pas instanciée
alors que le header a bien été mis par php
tout comme avec #HTTP_HEADER ?
(une histoire de cache ?)
      
simplement parce que, il faut le repeter encore, et encore, et encore :
"le php dans les squelettes n'est pas visible de SPIP, il n'est pas mis en cache, et ses effets ne peuvent etre pris en compte par SPIP. Il n'est évalué que quand la page est envoyée à l'internaute"
    
Certes :wink: cf "spip et php sont dans un bateau"

> CQFD

$GLOBALS['page']['entetes']['X-Expresso'] est calculé
lors de la fabrication du cache spip ?
  
$GLOBALS['page']['entetes'] est renseigné par #HTTP_HEADER lors du calcul de la page

ou calculé à sa lecture inclusion exécution ?
(Je n'ai rien trouvé dans le source qui indique où est calculé
cette globale pour des entetes comme X-Expresso, càd non générique )

En tout cas c'est affecté plut tôt que le <?php header ?> n'est exécuté
  

DEFINITIVEMENT, <?php header ?> ne peut pas etre pris en compte par SPIP, d'une maniere ou d'une autre.

et a fortiori plus tôt que le pipeline expresso_affichage_final
n'est appelé (c'est dans ce pipeline que c'est testé).
et donc je ne peux m'en sortir avec <?php header ?>.

Mais comment ça se passe pour la balise #HTTP_HEADER ?
Elle arrive à la fois à positionner la globale
et à appeler la fonction header ... dans le bon ordre !

C'est fait pour, et il n'y a qu'UNE solution, c'est utiliser la balise #HTTP_HEADER. Au risque de me repeter, aucune solution basée sur le <?php header() ?> ne pourra marcher, quel que soit le temps que tu y passes.

Vu le temps que j'ai passé là dessus, ça devient absolument déraisonnable
de continuer, mais d'autant plus frustrant de rester bloqué là...
  

Cf le point 1 avec la solution
Cédric

cedric.morin@yterium.com a écrit :

C'est fait pour, et il n'y a qu'UNE solution, c'est utiliser la balise #HTTP_HEADER. Au risque de me repeter, aucune solution basée sur le <?php header() ?> ne pourra marcher, quel que soit le temps que tu y passes.
  
ben si quand meme, si c'est mis dans spip.php ou un toto.php appelé via <INCLURE>, c'est bien executé à chaque hit

ce qui m'amene à une question : c'est un gros bloquage technique qui empeche de mettre #HEADER dans des inclure ?
je n'ai jamais regardé cette partie du code, mais je me doute qu'il y a une bonne raison.
Peut etre qu'au moins pour #INCLURE ca pourrait etre mis en place ?

@++

Avec Fastcache ça marche bien mieux :-p

-- Fil

cedric.morin@yterium.com a écrit :

JLuc a écrit :

cedric a écrit :

[(#EVAL{_request('debut_forum')}|?{'',' '}) #HTTP_HEAD{...} ]

ça a l'air de marcher... :-))))))

J'ai essayé avec $_GET['debut_forums'], ça devrait être pareil
mais ça ne marchait pas.

Le $_GET ne marchait pas a cause des dans lesquels le compilateur se prend les pieds

Oui j'étais alors passé par un SET / GET sans succés.
Je n'ai plus de trace, mais peut être l'erreur
c'est que je mettais le #HTTP_HEADER en 2eme paramètre du |?{p1,p2}

Puis j'avais testé l'uri avec $_SERVER ce qui permetait de détecter
debut_forums, mais aussi debut_articles et debut_breves,
(utile pour les rubriques), et là j'ai la trace :

#SET{uri, #EVAL{$_SERVER['REQUEST_URI']}}
[(#GET{uri}|match{debut_}|?{'',#HTTP_HEADER{X-Expresso: true})]

mais ça marchait pas, peut être le header etait-il toujours inséré,
et peut on en conclure que
'spip "évalue" tous les arguments des filtres
même si il ne les utilise pas ensuite" ?

si c'est ça j'aurais du faire
[(#GET{uri}|match{debut_}|?{'',' '})#HTTP_HEADER{X-Expresso: true]
mais j'y ai pas pensé à l'époque.
Ce serait plus simple que les [ (test1) [(test2) resultat ]]
que je suis obligé de faire actuellement,
surtout que apparament la grammaire permet pas un 3eme niveau de test.

Mais comment ça se passe pour la balise #HTTP_HEADER ?
Elle arrive à la fois à positionner la globale
et à appeler la fonction header ... dans le bon ordre !
  

C'est fait pour

Je me suis fait tromper par la simplicité apparente de :

function balise_HTTP_HEADER_dist($p) {
  $header = interprete_argument_balise(1,$p);
  $p->code = "'<'.'?php header(\"' . "
    . $header
    . " . '\"); ?'.'>'";
  $p->interdire_scripts = false;
  return $p;
}

c'est magique alors ! ou bien, c'est planqué dans la manche...
JL

Fil a écrit :

Avec Fastcache ça marche bien mieux :-p

:slight_smile:
Tu le dis pour fastcache aussi :
mieux vaut probablement pas mettre en cache tous les pages articles.
Si je voulais éviter de cacher des pages inutiles
j'aurais aussi du tester debut_forums & co
et apparament aussi, au vu des commentaires sur spip-contrib,
ç'aurait été compliqué par des pbs avec inclure.

Après, il m'a semblé que la différence entre l'approche fastcache
et celle d'expresso, c'était que expresso utilise le .htaccess
alors que fastcache passe par spip.php (pour le dérouter).

L'hébergeur souhaitait alléger la charge cpu php,
et apparament un autre site utilisait expresso et avait gagné 50%
donc comme il fallait choisir, j'ai choisi expresso !

Et puis mon espace disque était un peu chargé,
alors comme j'ai compris que fastcache génère 4 versions du cache...

Par contre, expresso n'est pas mur encore au niveau de la configuration.
Je crois qu'on peut grave faciliter la vie du créateur de squelette
en permettant de paramétrer les éléments de querystring
qui ne déclanchent pas la création d'un cache.
(je témoigne : c'est l'origine de mes galères )
A propos : Expresso n'utilise pas CFG.

Expresso je crois n'est pas abouti non plus je pense au niveau
de la génération du htaccess, qui pourrait je pense être optimisé
en changeant l'ordre des rewriteconds et en en regroupant 2 ou 3 au début,
ce qui éviterait de les répéter ensuite.
Mais je me rend pas compte du coût de traitement d'une ligne htaccess
qui est peut être négligeable. (une idée ?)

JL

a part ça, expresso mettant dynamiquement dans le htaccess
les rewriterules des pages cachées
dont le squelette contient le marqueur adhoc,
y compris lorsqu'il y a des paramètres d'url supplémentaires,
j'y ai aussi trouvé des traces bizarres :

Remplacer '(point)' par '.' dans :

RewriteCond %{QUERY_STRING} ^l=http://server1(point)weeu(point)net/cd/aj.txt%253f%253f$

J'ai l'impression que aj.txt est un script de hack.
La tentative d'attaque (si c'en est bien une) n'a rien donné a priori
et ça ne visait pas expresso, c'est juste que expresso l'a logué !

ça militerait en faveur du fait que l'approche d'exclure des pages spécifiques
(sur la base de la présence de debut_forums ou id_document par exemple)
pour un même squelette (article en l'occurence) n'est peut être pas la bonne.
Il vaudrait peut être mieux tester la querystring dans son intégralité
et la comparer aux valeurs souhaitées.
Pour éviter le gonflement de l'espace de cache et du .htaccess.

Dans la mesure où ils sont basés eux aussi sur la query string
et donc les paramétres supplémentaires,
la problématique est la même pour fastcache
ainsi que pour le cache de spip,
si on considère ça comme un probleme que le cache contienne des pages inutiles.

JL