SPIP-Contrib

SPIP-Contrib

عربي | Deutsch | English | Español | français | italiano | Nederlands

286 Plugins, 197 contribs sur SPIP-Zone, 300 visiteurs en ce moment

Accueil > Optimisation et performances > Expresso > Expresso

Expresso

9 janvier 2008 – par Cerdic, JLuc, NicolasR – 27 commentaires

8 votes

Attention, cette page de documentation est incomplète... Vous devrez donc découvrir et expérimenter par vous-même. Des liens à la fin permettent d’accéder à d’autres documentations.
Soyez sympa, pensez à revenir compléter cette page ;-)

Ce plugin permet d’accélérer votre site SPIP a l’aide d’un percolateur constitué d’un cache statique de second niveau servi directement par le serveur Apache

Fonctionnement

Pour être percolée, une page doit contenir la directive
#HTTP_HEADER{X-Expresso: true}

Le plugin fabrique un cache statique de toutes les pages percolées, qu’il stocke dans un repertoire « tmp/cache/apache », et maintient une liste de correspondance (url,fichier).

Pour initialiser l’expresso, il faut ajouter la chaine XXXEXPRESSOXXX dans le fichier .htaccess situé à la racine du site. A cet endroit du .htacess, Expresso intègrera les directives de RewriteRules qui dirigeront l’appel de la page soit vers la page ellemême de temps en temps pour recalculer le cache, soit vers le cache statique correspondant à la page.

A priori, c’est plutôt à la fin du .htaccess qu’il faut insérer ce marqueur, mais pas nécessairement tout à la fin...
Si vous avez les url_standard (canal historique), il faut mettre le marqueur #XXXEXPRESSOXXX juste avant la ligne

RewriteRule ^(rubrique|article|breve|mot|auteur|site|agenda|backend|backend-breves|distrib|forum|ical|plan|recherche|resume|sommaire_texte)\.php3?$        spip.php?page=$1 [QSA,L]

En effet, si des régles expresso pour des articles par exemple, étaient positionnées après ce bloc, elles ne serait jamais utilisées puisque ledit bloc transforme les requêtes ?article.php en requêtes ?spip.php

Les rewriterules intègrent une condition temporelle afin de répartir le service entre Apache et SPIP : c’est le percolateur qui appele les fichiers du cache, mais laisse tout de même passer une petite partie des requêtes à SPIP pour assurer la mise à jour des pages expirées.

Cette proportion de requêtes qui va vers le cache peut être spécifiée entre 0 et 60. Il faut pour cela modifier le fichier "expresso_pipeline" à la racine du plugin. Pour une valeur de 0, le cache statique est désactivé, pour 60, tous les appels renvoient la page en cache : il n’y a plus aucun appel à PHP, mais la page n’est plus jamais raffraichie !

La gestion de ce poursoixantage se fait quasi-aléatoirement sur la base de la valeur de la seconde à laquelle la page est appelée (d’où l’intervalle 0-60), et donc la proportion est approximative. Mais pour une page qui est beaucoup appelée (cas le plus intéressant pour un cache statique), statistiquement, ça doit être vite très approchant de la proportion ciblée.

Ce qu’on peut vérifier quand ça marche :

Le cache statique n’est jamais servie à un admin. Pour tester, il faut donc supprimer le cookie de liaison et vous déconnecter de la partie privée, et charger les pages jusqu’à ce que le délais de recalcul soit atteint et provoque l’écriture dans le htaccess... Ou alors attendre que les utilisateurs aient eux même provoqué cela !

On voit, dés les premiers appels des pages, les fichiers caches se fabriquer dans /local/apache

Par ailleurs, le fichier de log /tmp/boost.log mémorise les derniers caches statiques créés.

Après un certain temps dépendant de la valeur de la directive #CACHE spécifié dans vos squelettes, le htaccess est modifié et intègre la rewriterule qui appelle le cache.

Ensuite, on peut consulter les headers http des pages, par exemple avec l’option du plugin webdeveloper de Firefox. Ces headers sont différents sur les pages sans expresso, sur les pages percolées mais servi par le php, et sur les pages percolées servies à partir du cache statique :

-  le header des pages non percolées contient notamment : X-Spip-Cache: 86400 (par exemple). Elle contient également l’indication du php : X-Powered-By: PHP/4.4.7 par exemple, ainsi que, si le service est gzipé : Content-Encoding: gzip.

-  le header des pages percolées mais servies par php (par exemple parceque vous êtes admin, ou parceque c’est un moment de recacul du cache) contient en plus :
X-Expresso: true. (et, autre différence : il n’y a plus de gzip )

-  le header d’une page percolée et servie directement à partir du cache statique est différente : il n’y a plus l’indication que la page est servie par php, et il n’y a plus le header x-expresso.

Ces petites différences permettent de tester et vérifier si ça marche...

Statistiques de fréquentation

Les statistiques SPIP d’une page percolée ne sont pas du tout valables puisque SPIP n’en voit passer qu’une faible part.

Par contre, les statistiques utilisant des marqueurs externes, comme Xiti ou GoogleAnalytics, continuent à marcher.

Exemples d’appel

Il est possible d’appeler Expresso sur toutes les pages d’un site, mais si vous en avez beaucoup, cela va encombrer le .htaccess. Alors il est préférable de ne l’appeler que pour les pages les plus appelées.

Si vous voulez percoler la page sommaire, il suffit de rajouter la balise en début du squelette sommaire.

Si vous voulez percoler certains articles, vous pourrez vous servir d’un mot clé à usage technique qui sera testé dans une boucle :

<BOUCLE_percole(ARTICLES){id_mot=19}{id_article}>
#HTTP_HEADER{X-Expresso: true}
</BOUCLE_percole>

Cela aura cependant l’inconvénient que non seulement l’appel à la page sera percolée, mais aussi tous les appels secondaires qui passent par ce même squelette (par exemple : les paginations suivantes, les appels de forums ou de document, ...). Pour ne pas encombrer le .htaccess par ces pages secondaires peu visitées, il est souhaitable de les éliminer en testant les paramétres de l’url :

<BOUCLE_percole(ARTICLES){id_mot=19}{id_article}>
   [(#EVAL{_request('debut_forums')}|?{'',' '})
       [(#EVAL{_request('id_document')}|?{'',' '}) #HTTP_HEADER{X-Expresso: true} ] ]
</BOUCLE_percole>

Pour le squelette des pages rubriques, il faudra en plus tester la pagination des breves, des articles et des sites ... (debut_breves, debut_articles, debut_sites... )

Si les conditions à tester sont trop nombreuses, il faudra définir un filtre pour les tester, car la grammaire spip ne permet pas les imbrications d’une trop grande complexité.

Un autre mécanisme de test pourrait être défini pour non pas exclure les pages parasites, mais ne retenir que LA page souhaitée. C’est d’autant plus souhaitable que des tas de programmes ou de sites sur internet appellent des pages de votre site, avec des paramétres dont vous avez vraiment pas idée... et que chacun de ces appels encombre inutilement le .htaccess

Pour ne retenir donc que les bonnes pages, vous pourrez utilement utiliser ce filtre qui teste le nombre de variables passées dans l’url :

function isgetokexpresso($texte, $cool=2)
{
//  count ($_GET) vaut basiquement 2 car après les redirections url_propre, on se trouve dans une page appelée par spip.php avec 2 parms : le nom de la page (article ou rubrique) et la valeur id_article ou id_rubrique
 return (count ($_GET)==$cool ? " " : "");
};

et l’appel donne quelquechose comme ça :

<BOUCLE_expresso(ARTICLES){id_mot=19}>
   [(#NOOP|isgetokexpresso) #HTTP_HEADER{X-Expresso: true} ]
</BOUCLE_expresso>

Pour la page d’accueil (squelette : sommaire.html), il n’y a pas d’autres parametre que le nom de la page (=sommaire), donc l’appel se fera différemment :

[(#NOOP|isgetokexpresso{1}) #HTTP_HEADER{X-Expresso: true} ]

Attention

Les statistiques spip des articles percolés sont très très sousévaluées puisque seule une faible partie des pages appelées passent par spip. Les mesures statistiques sont donc fausses, ainsi que signalé précédemment.

On ne pourra donc pas utilement passer par une boucle SPIP testant la popularité des pages pour sélectionner automatiquement les pages percolées...

Test d’usage

-  test en situation de crise :

Expresso a déjà démontré ses capacités sur un pic d’audience, cf. spip-blog.net/SPIP-tient-la-route

PNG - 83.9 ko

Sur le graphe, les vides signalent que le serveur était tellement chargé que le monitoring, non prioritaire, n’a pu avoir lieu. Mais le site a tenu le coup et servi les pages demandées.

-  mesures :

Selon les mesures réalisées par l’hébergeur Lixium pour le site Passerelle Eco , la ressource CPU mobilisée pour le service d’une page percolée est de 100 fois inférieure
à celle requise pour une page non percolée. Sur ce site, les 30 pages les plus consultées, générant 70% du traffic sont percolées au moyen de boucles qui les sélectionnent en utilisant le filtre isgetokexpresso ci dessus. L’économie pour le CPU est significative.

Auteurs

Auteur du plugin : Cédric Morin http://www.yterium.net/
© 2007 - Distribué sous licence GNU/LGPL

Documentation par Jean Luc www.ouhpla.net

Dernière modification de cette page le 26 mars 2008

Retour en haut de la page

Vos commentaires

  • Le 10 octobre 2008 à 10:49, par JLuc En réponse à : Expresso

    il faut bien recopier XXXEXPRESSOXXX tel quel,
    au bon endroit dans le htaccess.

    • Le 11 octobre 2008 à 15:04, par Loiseau2nuit En réponse à : Expresso

      et alors en ce cas, quel est le bon endroit lorsque l’on utilise les URL propres ?

      Parce qu’en le plaçant tout à la fin je suis toujours en erreur sur l’ensemble du site ???

      Merci de vos retours.

      Etienne.

    • Le 12 mars 2010 à 23:41, par roxane En réponse à : Expresso quel seuil de visites/jour pour que ça soit bénéfique ?

      Bonjour
      Tout ça a l’air très chouette... le site que je rénove tourne chez APINC avec spip2.0.10 et php5.
      Je voudrais vous poser des questions à propos du rafraichissement des pages.
      ... suis-je petit joueur dans la cour des grands... ;-)
      pour 40 à 80 visites par jour, le jeu en vaut la chandelle ? si on ajoute un article, combien d’heures, de jours ? de visites ? pour qu’il apparaisse en ligne ?
      J’ai pas bien compris le poursoixantage par rapport aux 60 secondes. La page serait-elle rafraichie à la 10e visite par seconde si on a mis 10 poursoixante ?
      le plug-in est-il compatible avec spip2.0.10 ?
      à part pour les versions de spip, je suis pas sure de faire la distinction entre les trois solutions techniques proposées ici (cache cool, fastcache et expresso)
      merci d’avance, si le temps ne vous est pas trop compté...

      http://www.theatrecroquemitaine.com

    • Le 12 mars 2010 à 23:50, par Cerdic En réponse à : Expresso quel seuil de visites/jour pour que ça soit bénéfique ?

      Cache Cool est la solution la plus simple à déployer et qui suffit largement pour le trafic que vous avez à gérer. Par ailleurs Expresso n’a pas été mis à jour pour SPIP 2.0.

      A noter que les trafics dont on parle ici sont de l’ordre de plusieurs dizaines de millier de visiteurs par jour.

    • Le 12 mars 2010 à 23:56, par roxane En réponse à : Expresso quel seuil de visites/jour pour que ça soit bénéfique ?

      > A noter que les trafics dont on parle ici sont de l’ordre de plusieurs dizaines de millier de visiteurs par jour.

      ooops... mais merci du conseil !

    • Le 13 mars 2010 à 08:52, par JLuc En réponse à : Expresso quel seuil de visites/jour pour que ça soit bénéfique ?

      Pour info, sur un site qui n’avait que 3 à 5 milliers de visiteurs, EXPRESSO ciblé sur les 40 pages les plus fréquentées a été TRES apprécié par l’hébergeur (mutu), en son temps. Maintenant cache-cool fait le boulot tout pareil et sans les soucis occasionnels de corruption du htaccess.

    Répondre à ce message

  • Le 26 septembre 2008 à 12:18, par ? En réponse à : Expresso & Erreur 500

    En plaçant XXXEXPRESSOXXX dans la page .htaccess, arrive aussitôt la page « Erreur 500 » sur mon site. D’où vient le souci ?
    D’ailleurs, quels sont les paramètres pour le .htaccess : 775 ou autre ? et quel .htaccess doit être paramétré si on a placé l’admin spip dans un sous dossier du site ? à la racine ou dans ce sous-dossier.
    -  NB : pour avoir testé les 2, le résultat est le même : Erreur 500…
    -  NB2 : Les #HTTP_HEADERX-Expresso : true sont bien placés sur certaines pages, le plugin installé, la version de Spip 1.9.2.d…
    -  NB3 : L’objet est de diminuer la consommation du CPU après plusieurs suspensions par site5.com et avant de me faire exclure définitivement…

    Christophe / www.seasailsurf.com

    • Le 10 octobre 2008 à 00:16, par Loiseau2nuit En réponse à : Expresso & Erreur 500

      Erreur 500, j’ai la même à la maison et je ne sais pas d’où cela vient.

      Mais la syntaxe du XXXEXPRESSOXXX me laisse perplexe... pour une directive de .htaccess. Faut-il vraiment le copier/coller tel quel ou bien doit-on remplacer quelque chose genre XXX par ... ???

      Quelqu’un peut m’éclairer ?

      Merci.

    Répondre à ce message

  • Le 9 janvier 2008 à 06:35, par valery En réponse à : Expresso

    Quele est la différence avec le Fastcache ?

    • Le 9 janvier 2008 à 09:45, par Cerdic En réponse à : Expresso

      Expresso confie le service des pages html en cache à Apache uniquement (sans php), mais necessite pour cela un droit d’écriture sur le .htaccess et le droit d’utiliser les RewriteRules.

      Il est théoriquement mieux adapté aux hebergements pour lesquels php n’est pas rapide.

    • Le 29 janvier 2008 à 18:17, par ManuDevil, concepteur multimédia... avec SPIP En réponse à : Expresso

      Si je comprends bien, l’utilisation de ce plugin (on le télécharge où, d’ailleurs ?) dépend du serveur sur le quel on pose le site. Cela serait-il possible de savoir avec quels serveurs d’hébergement il peut fonctionner ? OVH ? Céléonet ? 1&1 ?...

      Merci beaucoup !

    • Le 31 juillet 2008 à 23:06, par Loiseau2nuit En réponse à : Expresso

      Cedric ? Qu’entends tu par « php pas rapide » ? Quels sont les critères à observer ? Comment déterminer qu’expresso sera bien la meilleure méthode face à fastcache ?

      Sinon point de vue perso, mais je n’ai rien compris à la doc :)

    • Le 6 août 2008 à 03:24, par Loiseau2nuit En réponse à : Expresso

      Je crois qu’on ne le télécharge pas. Comme la plupart des plugs en dev, ou en test, on le récupère, soit via SVN soit en allant copier/coller les fichiers dispos sur le trac de spip-zone : http://trac.spip.org/trac/spip-zone/wiki/LesPlugins

    • Le 6 août 2008 à 03:28, par Loiseau2nuit En réponse à : Expresso

      Pardon ! erreur sur l’adresse, c’est bien là http://zone.spip.org/trac/spip-zone/ que ca se passe et pas ailleurs ;)

      PS : Crayon déconne sur les forums ou c’est mon FF3/linux qui n’a rien compris à la vie ???

    • Le 21 août 2008 à 15:17, par joz En réponse à : crayon

      je pense qu’il y a un problème avec crayon sous ff3

      à+
      joz

    • Le 21 août 2008 à 20:05, par Loiseau2nuit En réponse à : crayon

      Ben en fait, pas sûr. Je l’utilise quotidiennement sur d’autre sites sans que ca pose problème.

      Mais là on est peut être face à une version du plugin un peu hybride (à cheval entre spip1.9.2 et Spip 2.0) et qui plus est, se trouve implémenté dans un cadre (l’édition de forum) qui est loin de lui être natif pour les dernières versions que j’en connais donc... ;)

    Répondre à ce message

  • Le 21 février 2008 à 17:10, par JLuc En réponse à : Expresso light

    Il me semble qu’on peut optimiser le htaccess généré en rassemblant au début du ###EXPRESSO### les rewriteconds constantes qu’il est alors inutile de répéter pour chaque page.

    Pas testé mais dans ce cas, c’est quelquechose dans le genre qu’il faudrait écrire une seule fois au début :

    RewriteCond %{HTTP_HOST} !^www.monsite.info$
    RewriteRule .* - [L]

    RewriteCond %{REQUEST_METHOD} POST
    RewriteRule .* - [L]

    RewriteCond %{HTTP_COOKIE} ^.*spip_(admin|session)=.*$
    RewriteRule .* - [L]

    Bonne idée à coder ou mauvaise idée à jeter ?

    Répondre à ce message

  • Le 18 février 2008 à 16:59, par JLuc En réponse à : Expresso bouillu ?

    Bonjour,

    J’ai mis le header sur le squelette sommaire, en 2e ligne juste après le cache. (la position dans le squelette ne semble pas avoir d’importance selon l’article).

    Les droits sur .htaccess sont corrects a priori.

    Je me suis connecté avec un autre navigateur sur lequel je ne suis pas admin (car il me semble que expresso ne fait rien pour les admins, non ?), et j’ai visualisé plusieurs fois la page.

    Un répertoire local/apache a bien été créé, et un fichier cache dedans avec un nom à la md5dehors dedans. Cela indiquerait que Expresso fait son boulot, mais le htaccess est inchangé... (sans ###expresso### et donc a priori la page statique n’est pas appelée)

    Y a t il quelquechose que j’ai oublié de faire ?
    Y a t il un moyen d’affiner le diagnostic ?

    • Le 18 février 2008 à 19:39, par JLuc En réponse à : Expresso bouillu ?

      J’ai continué à explorer le plugin et son code ... ce qui m’a donné l’idée qu’il fallait peut être « initialiser » le plugin en ajoutant

      ###EXPRESSO###
      ###/EXPRESSO###

      à l’endroit où devaient être insérées les rewriterules dans le .htaccess.

      Puis je suis passé à autre chose, et quand je suis revenu, le htaccess avait été modifé
      et intégrait cette fois les rewrites rules attendues.

      Donc !

      Il est donc possible, mais pas sur non plus (car sait-on jamais c’est peut être juste qu’il faut du temps pour qu’il se passe quelquechose ?), qu’il faille initialiser ainsi le plugin.

      Si on me dit que c’est bien ça je l’ajouterai volontier à la doc !

      En tout cas, à ce moment, je remarque qu’il n’y a plus x-expresso true dans les headers de la page servie. C’est un bon indice que ça marche !!

      A part ça, rien que pour le sommaire, il y a 9 rewrite rules générées (2 pour index.php ; 2 pour index.php3, 1 seule pour sommaire.php qui regroupe les 2, 2 pour sommaire.php3 et 2 pour le ndd sec sans fichier demandé. Chacune avec ses 5 rewrite conds, (6 pour celle qui regroupe les 2).
      genre ça donne :

      RewriteCond %{HTTP_HOST} ^www.monsite.info$
      RewriteCond %{REQUEST_METHOD} !POST
      RewriteCond %{HTTP_COOKIE} !^.*spip_(admin|session)=.*$
      RewriteCond %{QUERY_STRING} ^$
      RewriteCond %{TIME_SEC} >57
      RewriteRule ^index\.php3$ local/apache/89d3dcb5cc4703d915b6214366bfd71b.html [L]

      Et ça fait 5 fichiers caches générés correspondants aux différents appels possible du sommaire et à chaque groupe de rewriterule.

      Cette surabondance est liée au fait que le site utilise les urls historiques (« url_standard » je crois).

      Je pense qu’il est possible d’optimiser cela et j’envisage 2 pistes :
      -  en ramenant toutes les urls appelées à un seul modèle ou 2 (vérifier dans le source comment c’est appelé)
      -  peut être en déplaçant l’insertion de ###EXPRESSO### plus loin dans le htaccess, pour qu’il ne soit plus sollicité qu’une fois les redirections faites...

      Les conseils du concepteur et autres retours d’expérience sont bienvenus !

    • Le 19 février 2008 à 02:46, par JLuc En réponse à : Conclusion provisoire

      J’ai maintenant réécrit presque complètement le htaccess avec plus de [R=301] pour rediriger vers les adresses canoniques en php (en général), et index.php et sommaire.php vers / tout court (« une seule adresse par page » !).

      Et j’ai mis le ###EXPRESSO### après tout cela (ça suffit, pas la peine d’ajouter ###/EXPRESSO### en fait !).

      Un seul fichier cache se recrée maintenant dans local/apache. Ce fichier, c’est bien la page d’accueil, avec un « expresso » xx-small ajouté tout à la fin avant le </body> mais qui n’apparait pas à l’écran.

      A partir de là, il se passe rien pendant un certain temps. Je comprend pas cette latence. J’appelle la page sous tous ses noms, il se passe rien, et puis à un moment le site se fige, tout ralentis, peut être un hasard ? en tout cas après, le .htaccess est finalement modifié, et il y a un ensemble de 5 fois 2 rewrite rules accompagnées de leurs conds (index.php et php3, sommaire.php et php3, et ^$). Chacun de ces groupes de 2 a son propre fichier cache, mais seul réellement appelé existe : pour ^$. La manip de tout ramener à une seule adresse a bien réussi en ce qui concerne les apparence mais ça ne simplifie pas le htaccess de expresso...

      A part ça ya un fichier de log boost.log

      Et enfin, quand la page affiche le fichier caché, le gzip n’a pas l’air appliqué car ça n’apparait pas dans les entêtes (contrairement à quand ça passe pas par le cache).
      c’est un peu dommage ça non ?

      enfin, c’est mon hébergeur qui va être content ! Il disait en gros que ça divisait par 2 la consommation CPU sur les sites qui l’utilisent !!!

    • Le 19 février 2008 à 14:51, par Cerdic En réponse à : Conclusion provisoire

      La mise en cache expresso ne se fait qu’au calcul de la page, c’est à dire lorsque le cache spip est expiré. La latence doit venir de cela.

      Il faut bien le ###EXPRESSO### dans le htaccess, cela permet de maitriser ou insèrer les rewrite rules.

      Si ton hébergeur connait des sites qui l’utilisent cela serait sympa de les signaler, car à part toi, je n’ai eu aucun retour d’essai du plugin, et des gains en fonction des configs serveurs.

    • Le 19 février 2008 à 19:22, par JLuc En réponse à : Conclusion provisoire

      ok je te tiendrai au courant.

      là, j’ai donné un corps à l’article.

      En ce qui concerne mon site, j’ai mis expresso sur une vingtaine de pages, en ajoutant le header de manière conditionnelle dans le squelette. J’espèrais que cela fasse 200 lignes ajoutées au .htaccess, mais en pratique, il y en a bien plus car il y a toutes les variations de la page (notamment avec la pagination sur les forums).

      Ce serait bien que expresso ne cache que la page principale et pas les variantes avec « &debut_forums » dans la query ce qui fait des groupes de régles avec des lignes comme ça dans le htaccess :RewriteCond %{QUERY_STRING} ^id_article=101&amp;debut_forums=20$
      alors que je veux pas nécessairement que ces variantes des pages soit percolées...

      Comme cela dépend de chaque squelette, il faudrait pouvoir paramétrer les chaines à détecter dans l’url pour décider de ne pas mettre en cache... Je peux aussi le faire en modifiant les conditions d’insertion du header dans le squelette. Je sais pas ce qui serait le mieux.

      Actuellement, sans ce paramétrage plus fin, au lieu des 200 lignes, ce sont 700 lignes qui ont été ajoutées dans le htaccess (pour le sommaire, 12 articles et environ 8 rubriques). Je me demande quel est le surcout serveur d’un htaccess de 700 lignes ?

      Et ça invite à optimiser les rewriteconds ajoutées :

      ordre actuel :

      RewriteCond %{HTTP_HOST} ^www.monsite.info$
      RewriteCond %{REQUEST_METHOD} !POST
      RewriteCond %{HTTP_COOKIE} !^.*spip_(admin|session)=.*$
      RewriteCond %{QUERY_STRING} ^id_article=101&amp;debut_forums=20$
      RewriteCond %{TIME_SEC} >15
      RewriteRule ^article\.php$ local/apache/f35e6a550e7ad92c56d4744b8532f841.html [L]

      Notamment : est-ce l’ordre suivant ne serait pas plus efficace : voici une proposition où je met les conditions les plus restrictives en premier :

      RewriteCond %{QUERY_STRING} ^id_article=101&amp;debut_forums=20$
      RewriteCond %{TIME_SEC} >15
      RewriteCond %{HTTP_HOST} ^www.monsite.info$
      RewriteCond %{REQUEST_METHOD} !POST
      RewriteCond %{HTTP_COOKIE} !^.*spip_(admin|session)=.*$
      RewriteRule ^article\.php$ local/apache/f35e6a550e7ad92c56d4744b8532f841.html [L]

      et puis j’ai l’impression que dans mon cas on peut supprimer la

      RewriteCond %{HTTP_HOST} ^www.monsite.info$

      peut être même assez souvent, non ?

    • Le 21 février 2008 à 17:02, par JLuc En réponse à : bug

      de temps en temps ya un chti bug dans les calculs de création du htaccess
      car il y inscrit :

      RewriteCond %{TIME_SEC} >-1
      RewriteCond %{TIME_SEC} <51

    Répondre à ce message

  • Le 18 février 2008 à 15:54, par JLuc En réponse à : Expresso et les stats

    Les stats de spip sont elles actualisées pour une page expressoée ou bien les pages expresso sont elles invisibles des stats spip ?
    et qu’en est-il des marqueurs xiti ou googleanalytics ?

    Répondre à ce message

  • Le 21 janvier 2008 à 13:17, par Jean-Michel En réponse à : Expresso

    Bonjour,

    Je ne trouve pas de lien pour télécharger « Expresso », où puis-je télécharger ce plugin stp ?

    • Le 3 février 2008 à 02:03, par Gilles Vincent En réponse à : C’est par ici !

      Expresso est dans cette archive des plugins en cours de développement :
      http://miroirspip.ventre.name/build...

      (mise à jour quotidiennement)

    • Le 4 février 2008 à 08:35, par ? En réponse à : C’est par ici !

      Certes, mais sous quel nom Expresso se trouve-t-il dans cette archive ? Car, sur ton lien, une fois décompressée, je trouve plein de plugins dans l’archive, mais pas Expresso...

    Répondre à ce message

Répondre à cet article

Qui êtes-vous ?

Pour afficher votre trombine avec votre message, enregistrez-la d’abord sur gravatar.com (gratuit et indolore) et n’oubliez pas d’indiquer votre adresse e-mail ici.

Ajoutez votre commentaire ici Les choses à faire avant de poser une question (Prolégomènes aux rapports de bugs. )
Ajouter un document

Retour en haut de la page

Ça discute par ici

  • Mode portail Communiquant pour SoyezCréateurs

    29 septembre 2010 – 19 commentaires

    5e mode d’affichage de la page d’accueil, ce mode se distingue des autres par une animation proposant un fondu/enchaîné des logos des articles à la une. Zonage Configuration Zone d’entête Nom du site Slogan si plugin bandeau présent (...)

  • Plugin Logo SVG : pouvoir utiliser des logos SVG

    17 octobre – commentaires

    Le SVG est un format vectoriel donc très léger et redimensionnable sans pertes, mais SPIP ne l’acceptait pas sur les logos. Ce plugin comble ce manque. Comment ça fonctionne ? Vous installez ce plugin, vous l’activez, et c’est tout. Crédits Une (...)

  • Utilisez le framework Foundation dans vos squelettes !

    13 août 2013 – 58 commentaires

    Foundation est un framework CSS et Javascript très complet pour réaliser des sites sur une grille propre et homogène. Mais surtout, il permet de rendre un site responsive très facilement ! Ce plugin ajoute le framework Foundation sur l’espace (...)

  • LinkCheck : vérificateur de liens

    13 février 2015 – 65 commentaires

    Ce plugin permet de chercher et tester l’ensemble des liens présents dans les objets. Vous pourrez donc en quelques clics connaître les liens brisés ou défectueux qui se sont immiscés dans le contenu de votre site SPIP. La vérification s’effectue en (...)

  • GIS 4

    11 août 2012 – 1288 commentaires

    Présentation et nouveautés La version 4 de GIS abandonne la libraire Mapstraction au profit de Leaflet. Cette librairie permet de s’affranchir des librairies propriétaires tout en gardant les mêmes fonctionnalités, elle propose même de nouvelles (...)

Ça spipe par là