ZZZ

Réparer le charset d'une base SPIP

Fil — 2012-12-30T09:13:21Z

Quand on part d'une vieille installation de SPIP il arrive qu'on enregistre les données en utf-8 dans des tables déclarées en latin1. Ca ne gêne pas le fonctionnement normal du site, mais ça empêche d'utiliser proprement les outils MySQL, de la ligne de commande (qui affiche des « Ã© » à la place des « é ») au moteur de recherche FULLTEXT, qui ne retrouve pas les mots accentués. Méthode de nettoyage.

0/ Faire toutes les sauvegardes, travailler sur un site de tests, etc. La procédure prend plusieurs minutes. Pour éviter toute connerie dans cet intervalle, tu peux vouloir mettre le site en berne, en mettant dans config/mes_options.php :

 header('Status: 503 Service Unavailable');
 die('Maintenance en cours, revenez plus tard.');

1/ dumper la base spip en latin1, la réimporter en utf8 dans une base spip2

mysqldump --opt --default-character-set=latin1 --no-create-info spip > spip-data.sql

mysqldump --opt --default-character-set=latin1 --no-data spip > spip-struct.sql

on corrige tous les charsets déclarés dans la structure

perl -pi -e's/latin1/utf8/g;' spip-struct.sql

On importe la structure corrigée des tables

mysql spip2 < spip-struct.sql

Si le site comporte des tables ayant une PRIMARY KEY sur un champ accentué, il peut y avoir des doublons, non détectés jusqu'ici, qui empêcheront la réimportation. On fait alors sauter cette primary key :

mysql spip2#
 ALTER TABLE spip_urls DROP PRIMARY KEY;

on corrige dans les toutes premières lignes des données la déclaration de charset :

perl -pi -e's/SET NAMES latin1/SET NAMES utf8/g;' spip-data.sql

On réimporte ensuite les données :

mysql spip2 < spip-data.sql

2/ Modifier les meta de charset :

mysql spip2#
 REPLACE spip_meta (nom,valeur,impt,maj) VALUES
 ('charset_sql_base', 'utf8', 'oui', NOW()),
 ('charset_collation_sql_base', 'utf8_general_ci', 'oui', NOW()),
 ('charset_sql_connexion', 'utf8', 'oui', NOW()),
 ('charset', 'utf-8', 'oui', NOW());

3/ Vérifier le fichier config/connect.php :
il faut qu'il ait la ligne :

define('_MYSQL_SET_SQL_MODE',true);

… et le connecter sur spip2.

4/ purger le cache des meta :

rm tmp/meta_cache.php

5/ éventuellement, vider le cache (mais sans obligation)

DotSPIP

Fil — 2012-01-28T18:50:43Z

DotSPIP est une application pour Mac OS X qui permet de convertir facilement des fichiers texte de tout type vers les raccourcis SPIP.

DotSPIP s'utilise simplement par glisser-déposer : on lâche un fichier, ou une série de fichiers, sur l'icone, et le résultat arrive à la fois à l'écran et dans le presse-papiers. Il ne reste plus qu'à le coller dans SPIP.

Lien de téléchargement :

Après téléchargement de l'image disque, installer l'application dans le dossier Applications et déposer son icone dans le Dock.

Formats acceptés :

rtf, doc, docx, html, odt, epub, txt…

Il est aussi possible de déposer directement un signet depuis un navigateur Web : DotSPIP se chargera d'appeler la page pour la convertir en raccourcis SPIP.

Compatibilité :

Testé avec les systèmes Snow Leopard (10.6) et Lion (10.7). (L'application ne fonctionne pas sur Mac 10.5 et inférieur, car elle exploite une fonction nécessitant PHP 5.3.0 au moins.)

Goodies :

DotSPIP modifie à la volée les guillemets (si l'auteur n'en a pas mis elle-même) en fonction de la langue du document.

Évolutions :

Ce logiciel ne demande qu'à évoluer, son but est d'être le plus utile tout en restant aussi simple que possible.

J'attends vos remarques avec impatience ; si vous avez des fichiers tests pour lesquels ce convertisseur ne fait pas ce qu'on en attendrait, n'hésitez pas à me les envoyer.

Parmi les projets envisagés :
— exporter au format markdown
— compatibilité linux
— traiter les images
— lire d'autres formats, notamment PDF

Remerciements :

— Sveinbjorn Thordarson pour Platypus (€)
— Baroug pour l'icône
— les vieux de la vieille de SPIP pour la fonction sale()
— Vincent pour les guillemets
— ARNO* pour Office2SPIP

Terminer l'installation de Varnish

Fil — 2011-04-10T20:06:06Z

Ce qui suit est peut-être un peu abscons, mais il faut bien en passer par là pour terminer l'installation : tester la communication, passer Apache sur un port secondaire, passer Varnish en frontal, et fignoler.

Maintenant que notre serveur sait communiquer avec Varnish, on va passer ce dernier en « frontal » sur le port http standard (:80). On dira à Apache d'écouter un port secondaire (:8080). Les visiteurs interrogeront donc Varnish, qui ira le cas échéant interroger Apache.

Ultimes vérifications

D'abord, quelques vérifications du bon fonctionnement du système. Un outil indispensable pour vérifier les entêtes est curl, qu'on va lancer dans une fenêtre shell :

curl -D head http://localhost/spip-2.1/ >/dev/null && cat head

Voici le résultat typique :

Concentrons-nous sur l'entête qui nous intéresse :

On voit ici que SPIP a bien envoyé l'entête destiné à Varnish.

Maintenant, si on regarde la même page telle que servie par Varnish, sur le port temporaire (:6081) :

curl -D head http://localhost:6081/spip-2.1/ >/dev/null && cat head

on obtient :

Concentrons-nous sur les entêtes pertinents :

On voit que Varnish a traité cette requête (qui a pour n° 1133668195), et qu'il est allé demander la ressource à Apache.

Maintenant lançons une deuxième fois la commande ; le bloc ci-dessus devient :

Ici on voit que notre réponse (1133668226) a été servie depuis la mémoire cache de Varnish, qui est allé chercher la ressource qu'il avait obtenue lors de la requête 1133668195 ; la ressource date d'il y a 10 secondes.

Continuons à surveiller X-Varnish-Age: en lançant la commande de manière répétitive :

watch "curl -D head http://localhost:6081/spip-2.1/ >/dev/null 2>/dev/null && cat head"

On voit toutes les deux secondes que l'âge de la page demandée augmente de deux secondes… tout va bien. Maintenant via le navigateur allons modifier un contenu, ou recalculer une page, via l'URL d'origine (port :80). On constate que la page n'est pas rafraichie. En effet le système ne se purge que lorsque la modification de contenu passe par Varnish.

Allons maintenant modifier le contenu en nous connectant à travers Varnish (sur la port :6081) : on constate que l'âge de la ressource retombe à zéro à chaque fois qu'on fait une modification.

Installer Varnish en frontal

Désormais il ne reste plus qu'à installer Varnish sur le port :80 ; pour cela il faut :

— configurer Apache pour qu'il écoute le port :8080 à la place du port :80 (probablement en éditant /etc/apache2/ports.conf).

— configurer Varnish pour qu'il aille chercher les ressources sur 127.0.0.1:8080 ; c'est au début du fichier /etc/varnish/default.conf

backend default {
 .host = "127.0.0.1";
 .port = "80";
 ...

}

— relancer Apache puis lancer Varnish sur le port 80 ; sur Debian, on va modifier la variable VARNISH_LISTEN_PORT=6081 dans /etc/default/varnish, puis relancer.

On peut ensuite répéter les tests ci-dessus, en remplaçant les numéros de ports par :80 (pour Varnish) et :8080 (pour Apache).

Fignoler

Fermer l'accès direct à Apache. Si le serveur Apache répond à tout l'Internet sur le port :8080, il est probable que Google le repérera et viendra lui parler directement, indexant ainsi deux fois les sites (sur chacun des ports), et allant à l'encontre du but visé. Il faut donc configurer Apache pour qu'il ne réponde que sur localhost (127.0.0.1).

Obtenir l'IP du client en aval. Désormais le « client » que voit Apache est toujours Varnish, donc une même machine ayant un seul numéro IP. Ce n'est pas génial ni pour les logs, ni pour des logiciels qui peuvent vouloir faire du contrôle d'accès ou de la géolocalisation à partir du numéro IP. Pour résoudre ce problème, le plus simple est d'installer l'extension pour Apache nommée mod_rpaf (http://stderr.net/apache/rpaf/) : celle-ci permet de « faire croire » à Apache que le numéro IP est bien celui du client en aval. Ainsi la manipe est totalement transparente pour les applications, qui du coup n'ont pas besoin d'être modifiées ni configurées.

Interfacer Varnish & SPIP

Fil — 2011-03-29T20:53:21Z

Principe de communication

Les communications entre notre application (ici il s'agira surtout de SPIP, mais le principe vaut pour d'autres applications) et notre proxy inverse Varnish se font par l'entremise des entêtes HTTP émises par l'application.

Nous introduisons les header() suivants :

X-Varnish-TTL: 120
Cet entête indique que la page doit avoir un TTL, dans Varnish, de 120 secondes ; dans SPIP il sera émis dans les conditions suivantes :

implicitement, en prenant la durée de cache de la page : TTL = min(durée du cache, 600)
ou bien explicitement via la balise #HTTP_HEADER{X-Varnish-TTL: 120}

L'appel #HTTP_HEADER{X-Varnish-TTL: 0} permet de dire à Varnish de ne pas conserver la page produite (par exemple parce qu'elle contient du code en PHP qu'on veut faire tourner à chaque hit).

X-Varnish-Purge: *
Cet entête indique à Varnish tout purger ; il est émis par la fonction suivre_invalideur(), à chaque modification des données. Il est également émis lorsqu'un changement de date provoque la publication d'un « article post-daté ».

De plus Varnish pourra aussi, indépendamment des entêtes envoyés par l'application, se baser sur l'URL pour invalider certaines pages.

Ainsi :

l'URL …?var_mode=calcul est détectée par Varnish (indépendamment des entêtes de SPIP décrites ci-dessus), et invalide la page concernée (et celle-ci seulement).
l'URL …?var_mode=(recalcul|images) est détectée par Varnish et invalide tout le cache de Varnish (notamment, parce qu'un recalcul d'une page peut provoquer la modification d'un fichier de CSS ou javascript associé).
l'URL de suppression du cache SPIP depuis l'espace privé (un clic sur le bouton dans ?exec=vider_cache) invalide aussi tout le cache Varnish.

Implémentation

Cette approche me semble au final plus simple que celle donnée par la doc de Varnish, qui passe par la définition d'une méthode HTTP non standard PURGE. Pour l'implémenter, j'ai construit un fichier de configuration pour Varnish, ainsi qu'un plugin pour SPIP.

Remarque : les deux éléments (configuration et plugin) sont conçus pour fonctionner de concert, mais il est tout à fait possible d'utiliser la configuration pour Varnish sans installer le plugin SPIP. Les pages « dynamiques » produites par SPIP ne seront alors pas enregistrées dans le cache de Varnish, qui y stockera néanmoins tous les fichiers statiques (images, javascript, CSS etc.) selon des règles « assez bonnes ».

Autrement dit, sur un serveur hébergeant plusieurs sites, on peut installer Varnish sans installer le plugin sur tous les sites : seuls les sites SPIP ayant installé le plugin en tireront le maximum, mais les autres ne seront pas pénalisés.

Télécharger le plugin

La configuration de Varnish et le plugin SPIP sont téléchargeables depuis SPIP-Zone : http://zone.spip.org/trac/spip-zone/browser/_plugins_/varnish

Le plugin nécessite l'usage du plugin StatsJS, car, dès lors qu'on demande à Varnish de servir directement les pages SPIP, celui-ci ne peut plus comptabiliser les visites des pages de la façon habituelle.

Configuration de Varnish

Voici le fichier de configuration, commentaires inclus :

# # Configuration de varnish (varnish-cache.org) # optimisée pour SPIP # # Varnish est un proxy inverse, installé sur le serveur Web, # qui permet : # # - 1. Rapidité. Absorbe une demande importante sur une même URL # et y répond directement sans solliciter apache # - 2. Tolérance aux pannes. Renvoie des pages depuis sa mémoire cache # même lorsque apache est planté # - 3. Souplesse dans l'affectation de serveur(s) apache à différentes # applications (par ex. load balancing, changement de serveur, etc) # - 4. Moindre consommation de CPU : économique et écologique # # La configuration ci-dessous permet d'optimiser son fonctionnement # avec SPIP ; elle s'applique sans problème à des serveurs # hébergeant aussi d'autres types de scripts, qui peuvent utiliser # les mêmes mécanismes de communication X-Varnish-Message et X-Varnish-Purge # ## -- BACKEND PRINCIPAL -- ## ## Tout d'abord, nous allons définir l'adresse du serveur apache hébergeant ## nos sites Web (ce que varnish appelle le backend). ## ## Dans notre cas, le serveur apache est accessible sur le ## port 8080 de l'interface 127.0.0.1 ; il répond aux mêmes requêtes que ## lorsqu'il est configuré sur le port 80 : ## GET / HTTP/1.0 ## Host: nomdusite.tld ## ## Pour ce backend, nous définissons un temps de latence avant le premier octet ## de 300s ; ainsi, lorsqu'une page demande un temps de calcul très long (par ## exemple un POST d'un long article), on attend jusqu'à 5 minutes avant de ## déclarer forfait et d'envoyer une erreur 500. ## http://vincentfretin.ecreall.com/articles/varnish-guru-meditation-on-timeout ## ## De plus, varnish va lancer chaque seconde une requête de test sur une URL ## type ; si 2 requêtes sur les 3 dernières sont en faute, il déclarera le ## backend "malade" ("sick") et passera en mode "tolérance aux pannes", ## jusqu'à ce que le backend revienne en bonne santé ("healthy"). ## backend default { .host = "127.0.0.1"; .port = "80"; .first_byte_timeout = 300s; .probe = { # Ici mettre un hit vers un petit fichier fixe sur le backend #.url = "/"; .request = "GET /prive/images/searching.gif HTTP/1.0" "Host: zzz.rezo.net" "Connection: close"; .timeout = 34 ms; .interval = 3s; .window = 3; .threshold = 2; } } ## -- BACKEND DE TEST D'ERREUR 503 -- ## ## Ce backend "guru" est toujours en panne ; il est destiné à provoquer ## une erreur 503, ce qui permet d'afficher délibérément le message d'erreur ## qu'on définira en fin de ce fichier de configuration ## => http://nomdusite.tld/I'm-a-guru ## backend guru { .host = "127.0.0.1"; .port = "8082"; # !!il faut choisir un numéro de port inutilisé } ## -- RECV -- ## Cette fonction est appelée à chaque connexion d'un client sur varnish. ## ## Elle normalise la requête : ## - en supprimant les cookies inutiles ## - en unifiant les différents types de Accept-Encoding ## sub vcl_recv { ## -- GRACE -- ## ## La "grace" sert dans deux scénarios : ## ## - a. "Absorber" la connexion *simultanée* de plusieurs clients ## sur une même URL : le temps que le backend calcule et renvoie ## la nouvelle réponse, on s'autorise à servir une réponse en cache ## mais dont la date de péremption est dépassée de moins de 30s. ## - b. "Panne" : si le backend est en panne, on s'autorise à servir ## des contenus mis en cache mais dont la date de péremption est ## dépassée (jusqu'à une heure). ## if (req.backend.healthy) { set req.grace = 30s; } else { set req.grace = 1h; } ## -- COOKIES -- ## ## On nettoie ici les cookies qui n'impactent pas SPIP ; ## essentiellement les cookies de tracking statistique, mais aussi ## les cookies d'options traitées côté client (vs. côté serveur). ## Attention les cookies importants côté serveur (cookie de session admin, ## par exemple) ne doivent *pas* être nettoyés. ## if (req.http.Cookie) { ## __utm[a-z] = cookies google analytics ## xtvrn = cookies xiti set req.http.Cookie = regsuball(req.http.Cookie, "(^|; ) *(__utm[a-z]|xtvrn)=[^;]+;? *", "\1"); ## _pk.* = cookies piwik ## => attention, sur l'URL de piwik, ne pas nettoyer les cookies piwik if (req.url !~ "/piwik\.php") { set req.http.Cookie = regsuball(req.http.Cookie, "(^|; ) *(_pk_[^=]+)=[^;]+;? *", "\1"); } ## dans une application particulière, le cookie "blink" est traité ## côté client ; il ne nous intéresse pas, on le nettoie set req.http.Cookie = regsuball(req.http.Cookie, "(^|; ) *(blink)=[^;]+;? *", "\1"); ## si le cookie résultant est vide, le supprimer if (req.http.Cookie == "") { remove req.http.Cookie; } ## si on est dans un repertoire statique ignorer totalement ## les cookies (ici, les répertoires SPIP & Drupal + les images ## css, scripts, etc.) ## (le ?\d+ final est un éventuel timestamp) if (req.url ~ "^[^?]*\.(css|js|jpg|jpeg|gif|png|ico|txt|mp3)(\?\d+)?$" || req.url ~ "^/(local|IMG|extensions|plugins|static)/") { remove req.http.Cookie; } } ## fin de la section COOKIE ## -- X-FORWARDED-FOR -- ## ## Ajouter un entête X-Forwarded-For: IP ## en le concaténant avec un éventuel entête déjà existant ## if (req.http.x-forwarded-for) { set req.http.X-Forwarded-For = req.http.X-Forwarded-For ", " client.ip; } else { set req.http.X-Forwarded-For = client.ip; } ## -- GZIP -- ## unifier les accept-encoding: accepte gzip ou pas ; on ne gere pas deflate ## (notamment : FF annonce "gzip, deflate" et Safari "gzip,deflate" !) if (req.http.Accept-Encoding) { if (req.http.Accept-Encoding ~ "gzip") { set req.http.Accept-Encoding = "gzip"; #} elsif (req.http.Accept-Encoding ~ "deflate") { #	set req.http.Accept-Encoding = "deflate"; } else { remove req.http.Accept-Encoding; } } ## -- RANGE -- ## Varnish ne doit pas gérer pas les requêtes de contenu partiel ; ## on les passe directement au backend ## cf. http://forum.developers.facebook.net/viewtopic.php?id=68440#p253346 if (req.http.Range) { return(pipe); } ## -- TEST 503 -- ## cf. ci-dessus le backend "guru" qui ne mène nulle part ## se teste via le navigateur sur http://urldusite.tld/_-_-I-m-a-guru ## permet d'afficher l'erreur définie en bas de ce fichier ## le nom zen vient de l'erreur par défaut de Varnish : "guru meditation" if (req.url == "/_-_-I-m-a-guru") { set req.backend = guru; } ## -- DIVERS -- ## certain robot fou demande host:127.0.0.1, on le jette immédiatement if (req.http.host == "127.0.0.1") { error 500 "Unknown virtual host."; } } ## -- FETCH -- ## Cette fonction est appelée à chaque retour du backend vers varnish. ## sub vcl_fetch { ## -- REDIRECTION -- ## supprimer le port (:8080) envoyé par le backend lors d'une redirection ## car on veut rediriger vers le port public :80 if (beresp.http.Location) { set beresp.http.Location = regsub(beresp.http.Location, "^(\w+://[^/]+):\d+", "\1"); } ## -- TTL: DUREE DE CACHE -- ## ## C'est la durée de vie de la page dans le cache ; au-delà de cette durée, ## elle ne pourra être servie au client que dans le scénario de "grace". ## ## Différents cas : ## -1 la ressource signale X-Varnish-TTL: 20s ## (c'est ce que fait le plugin pour SPIP) ## elle annonce à varnish que son script lui signalera plus tard, ## par un entete X-Varnish-Purge, quand le moment sera venu de ## rafraichir la page. Dans ce cas de figure on peut donc la mettre ## en cache pour la durée indiquée (si elle est > 0) ## -2a la ressource est statique, on la cache un certain temps raisonnable ## (sauf si un autre entete indique qu'elle n'est pas cacheable) ## -2b la ressource est dynamique, on ne la cache pas ## L'entête X-VARNISH-TTL permet au backend de définir le ttl du cache ## code inspiré de: http://open.blogs.nytimes.com/2010/09/15/using-varnish-so-news-doesnt-break-your-server/ ## http://www.lovelysystems.com/configuring-varnish-to-use-custom-http-headers/ ## ## (n'utilise pas X-SPIP-Cache car, sur SPIP standard, ça tuerait les stats) ## if (beresp.http.X-VARNISH-TTL) { C{ char *ttl; ttl = VRT_GetHdr(sp, HDR_BERESP, "\016X-VARNISH-TTL:"); VRT_l_beresp_ttl(sp, atoi(ttl)); }C remove beresp.http.X-VARNISH-TTL; } ## sinon se baser sur la logique habituelle de varnish (Expires, etc) ; ## en ajoutant une règle pour les fichiers dont on sait avec certitude ## qu'ils sont statiques : les images etc else { ## ne cacher que les css, js, jpg, gif, png, etc. ## le (?\d+) est un éventuel timestamp ## à noter : si apache est bien configuré, cette ligne est inutile if (req.url ~ "\.(css|js|jpg|jpeg|gif|png|ico|txt|mp3)(\?\d+)?$" || req.url ~ "^/(local|IMG|extensions|plugins|static)/") { set beresp.ttl = 600s; set beresp.http.Cache-Control = "max-age=600"; set beresp.http.Vary = "Accept-Encoding"; } ## ne pas cacher une ressource qui ne precise pas d'entete de cache else { if ( (!beresp.http.Cache-Control && !beresp.http.Expires) || beresp.http.Cache-Control ~ "no-cache" || beresp.http.Cache-Control ~ "private" ) { set beresp.cacheable = false; } #else { #	set beresp.cacheable = false; #	remove beresp.http.Cache-Control; #} } } ## ne pas conserver une ressource servie vieille aux robots if (beresp.http.X-Varnish-Stale) { set beresp.cacheable = false; #remove beresp.http.X-Varnish-Stale; } ## -- INVALIDATIONS -- ## ## On a vu ci-dessus qu'une page pouvait entrer en cache si elle s'annonçait ## via X-Varnish-Message-OK ## ## Si à l'inverse le backend veut invalider le cache, il suffit ## qu'il envoie un entête X-Varnish-Purge ## if (beresp.http.X-Varnish-Purge) { purge("req.http.host == " req.http.host); remove beresp.http.X-Varnish-Purge; set beresp.cacheable = false; } ## -- VAR_MODE -- ## Cette section gère les invalidations via le bouton d'admin ## si on demande un var_mode=recalcul on va par principe tout purger ## pour ne pas subir de cache secondaire, par exemple dans local/ ## lorsqu'on modifie des CSS ou des images calculées ## En revanche un var_mode=calcul est plus léger if (req.url ~ "[?&]var_mode=(recalcul|images)") { purge ("req.http.host == " req.http.host); set beresp.cacheable = false; } ## si on demande un var_mode=calcul on va purger uniquement la page ## demandee, sans son var_mode elsif (req.url ~ "[?&]var_mode=calcul") { purge ("req.http.host == " req.http.host " && req.url == " regsuball(req.url,"[&?]var_mode=.*$", "")); set beresp.cacheable = false; } ## -- GRACE -- ## Si la réponse est cacheable, on peut la conserver pour un maximum d'1h ## au cas où on aurait une panne (maximum des "grace" définies dans RECV) ## http://varnish-cache.org/trac/wiki/VCLExampleGrace set beresp.grace = 1h; ## -- RANGE -- ## seuls les gros fichiers (sons, videos) sont susceptibles de valoir ## un range ; on n'annonce donc le range que pour ceux-la, et on desactive ## l'entete if (beresp.http.Accept-Ranges && beresp.http.content-type !~ "(image|audio|video)/") { remove beresp.http.Accept-Ranges; } ## -- ETAG -- ## corrige un bug d'apache qui donne le même Etag aux représentations ## gzip et non-gzip d'un même fichier... if (beresp.http.content-encoding == "gzip" && beresp.http.etag) { set beresp.http.Etag = regsub(beresp.http.etag, ".$", "-gzip\0"); } ## -- ACTION=CRON -- ## inutile de solliciter la page action=cron de SPIP plus d'1 fois par 5s ## (à noter : avec les stats en js cette action disparaît) if (req.url ~ "\?action=cron$") { set beresp.ttl = 5s; set beresp.cacheable = true; } } ## -- HASH -- ## ## Cette fonction établit le nom du cache en fonction des caractéristiques ## de la requête sub vcl_hash { set req.hash += req.url; if (req.http.host) { set req.hash += req.http.host; } else { set req.hash += server.ip; } return (hash); } ## -- HIT -- ## ## Cette fonction est appelée quand une page est trouvée dans le cache ## de Varnish ; on ajoute une logique pour que "force-reload", sur un ## navigateur correct, n'utilise pas le cache : il conduit jusqu'au backend ## et met à jour le cache sub vcl_hit { # non cacheable, on passe if (!obj.cacheable) { return (pass); } # force-refresh will update the cache # http://www.varnish-cache.org/trac/wiki/VCLExampleEnableForceRefresh if (req.http.Cache-Control ~ "no-cache") { # Ignore requests via proxy caches, IE users and badly behaved crawlers # like msnbot that send no-cache with every request. if (! (req.http.Via || req.http.User-Agent ~ "bot|MSIE")) { set obj.ttl = 0s; return (restart); } } # standard response: use the cached version return (deliver); } ## -- DELIVER -- ## ## Cette fonction est appelée à l'envoi final du fichier, sauf (pass) ## ## On met le champ Age dans X-Varnish-Age sinon ça fait râler redbot.org ## On supprime Accept-Ranges de tous les fichiers sauf les images/sons/vidéos ## sub vcl_deliver { { set resp.http.X-Varnish-Age = resp.http.age; remove resp.http.age; if (resp.http.content-type !~ "(image|audio|video)/") { remove resp.http.accept-ranges; } } } ## -- ERROR -- ## ## Cette fonction est appelée en cas d'erreur, par exemple ## lorsque l'objet n'est pas en cache et que le backend est ## en panne (erreur 503). ## ## On peut la déclencher volontairement, pour la tester, via l'URL "guru" ## sub vcl_error { set obj.http.Content-Type = "text/html; charset=utf-8"; synthetic {" <html><head> <meta http-equiv="content-type" content="text/html; charset=utf-8"> <title>"} obj.status " " obj.response {"</title> <style type="text/css"> body { background: #689ab3; color: #333; margin: 0; font-size:1.3em; font-family: georgia, serif; } div { margin: 30px 0 0 0; background: #ffffff; opacity: 0.6; width: 650px; padding: 20px 20px 23px 23px; } p { margin: 0.5em 0 0.5em 0; } p.en { margin: 0 0 0.5em 0; } p.fin { margin: 0.5em 0 0 0; } p.message { font-size: 1.5em; margin: 0 0 0.5em 0; } h1 { font-size: 2em; margin: 0 0 0.5em 0; font-weight:normal; display:none; } </style> </head><body> <div> <p class="message">Le service est momentanément indisponible.<br /> Veuillez réessayer un peu plus tard. </p> <p class="en">The service is currently unavailable. Please try again later. </p> <p class="fin"><small>Erreur "} obj.status {" | XID: "} req.xid {"</small></p> </div> </body></html> "}; return (deliver); }

Comme on le voit c'est un gros fichier… on pourra en suivre le développement dans le répertoire du plugin.

Dans le prochain article j'indiquerai comment procéder pour terminer l'installation.

Installer Varnish

Fil — 2011-03-13T21:33:39Z

Pour commencer, nous allons installer Varnish sur un port secondaire (6081), et laisser le port 80 à Apache. Une fois que ça tournera correctement, et que la configuration sera satisfaisante, il sera temps d'inverser.

On va d'abord chercher les sources au format tgz : http://www.varnish-cache.org/releases/varnish-cache-2.1.5, et on compile.

# wget http://repo.varnish-cache.org/source/varnish-2.1.5.tar.gz
 # tar -xzf varnish-2.1.5.tar.gz
 # cd varnish-2.1.5
 # ./configure
 # make
 # sudo make install

Cela fait, le démon varnishd est installé dans /usr/local/sbin/ et les scripts d'administration se trouvent dans /usr/local/bin/varnishadm.

On commence à éditer /etc/varnish/default.conf :

 backend default {
 .host = "127.0.0.1";
 .port = "80";
 }

On lance ensuite le démon à la main :

# /usr/local/sbin/varnishd -f /etc/varnish/default.vcl -a127.0.0.1:6081 -S /etc/varnish/secret -Tlocalhost:6082 -s malloc,100M

(Ici, avec -s malloc,100M on affecte 100Mo de RAM à Varnish ; au passage en production, on pourra lui attribuer 1Go ou même plus. Attention, si on n'utilise pas malloc, on se retrouve facilement à remplir son disque dur, dans des fichiers situés dans les répertoires /usr/local/var/varnish/*.)

Désormais varnishd écoute le port 6081, et va chercher les ressources demandées sur le port 80, où se trouve Apache.

Sur Debian, on va créer un fichier de configuration pour le démarrage du démon. Ce fichier se trouve dans /etc/default/varnish

# Should we start varnishd at boot? Set to "yes" to enable. START=yes # Maximum number of open files (for ulimit -n) NFILES=131072 # Maximum locked memory size (for ulimit -l) # Used for locking the shared memory log in memory. If you increase log size, # you need to increase this number as well MEMLOCK=82000 # Default varnish instance name is the local nodename. Can be overridden with # the -n switch, to have more instances on a single server. INSTANCE=$(uname -n) # Main configuration file. You probably want to change it :) VARNISH_VCL_CONF=/etc/varnish/default.vcl # Default address and port to bind to # Blank address means all IPv4 and IPv6 interfaces, otherwise specify # a host name, an IPv4 dotted quad, or an IPv6 address in brackets. VARNISH_LISTEN_ADDRESS= VARNISH_LISTEN_PORT=6081 # Telnet admin interface listen address and port VARNISH_ADMIN_LISTEN_ADDRESS=127.0.0.1 VARNISH_ADMIN_LISTEN_PORT=6082 # The minimum number of worker threads to start VARNISH_MIN_THREADS=200 # The Maximum number of worker threads to start VARNISH_MAX_THREADS=1000 # Idle timeout for worker threads VARNISH_THREAD_TIMEOUT=120 # Cache file size: in bytes, optionally using k / M / G / T suffix, # or in percentage of available disk space using the % suffix. VARNISH_STORAGE_SIZE=512M # File containing administration secret VARNISH_SECRET_FILE=/etc/varnish/secret # Backend storage specification VARNISH_STORAGE="malloc,${VARNISH_STORAGE_SIZE}" # Default TTL used when the backend does not specify one VARNISH_TTL=120 # DAEMON_OPTS is used by the init script. If you add or remove options, make # sure you update this section, too. DAEMON_OPTS="-a ${VARNISH_LISTEN_ADDRESS}:${VARNISH_LISTEN_PORT} \ -f ${VARNISH_VCL_CONF} \ -T ${VARNISH_ADMIN_LISTEN_ADDRESS}:${VARNISH_ADMIN_LISTEN_PORT} \ -t ${VARNISH_TTL} \ -w ${VARNISH_MIN_THREADS},${VARNISH_MAX_THREADS},${VARNISH_THREAD_TIMEOUT} \ -S ${VARNISH_SECRET_FILE} \ -s ${VARNISH_STORAGE} \ -p http_range_support=yes"

Et on l'appelle avec la commande /etc/init.d/varnish start.

Varnish est installé.

On peut voir nos pages à l'adresse http://URLDUSITE:6081/

Dans les entêtes on observe quelque chose du genre :
X-Varnish: 1234
ou
X-Varnish: 4567 1234

Dans le premier cas, Varnish nous informe qu'il s'agit du 1234e hit qu'il a reçu, et qu'il est allé chercher la ressource sur le backend. Dans le second, il s'agit du 4567e hit, et c'est la ressource qu'il a mise en cache lors du 1234e hit qui a été servie directement, sans appel au backend.

Notre configuration ouvre un port d'administration (localhost:6082), protégé par un secret écrit dans le fichier /etc/varnish/secret
On peut dès lors appeler le script d'administration avec la commande
varnishadm -T localhost:6082 -S /etc/varnish/secret

C'est de là qu'on va piloter les fichiers de configuration.

Pour se faciliter la vie, au moins lors de la mise au point de la configuration, on va adapter ce script http://kristianlyng.wordpress.com/2009/02/18/easy-reloading-of-varnish-vcl/ et le sauvegarder dans /usr/local/bin/varnishreload.

Dès lors on recharge la configuration /etc/varnish/default.vcl après chaque modification du fichier via la commande :
# varnishreload

Dans un prochain article nous verrons comment structurer ce fichier de configuration de manière à l'optimiser pour des sites sous SPIP.

À quoi sert Varnish ?

Fil — 2011-03-11T21:55:36Z

Utilisé par des sites parmi les plus importants de la planète, Varnish est un ingrédient essentiel d'une bonne cuisine de serveur Web.

Tout responsable de site Internet connaît le dilemme : quand il n'y a personne pour le visiter, le site marche très bien. Dès qu'il a du succès, il plante ! La difficulté s'appelle l'effet slashdot, du nom d'un webzine qui, lorsqu'il référence un site, y envoie tellement de visiteurs que le site s'effondre sous le poids des visites.

Pour essayer de contrer ce problème, plusieurs parades ont été inventées : des « caches » plus ou moins « statiques » permettent au serveur Apache de ne pas lancer de script PHP pour calculer la même page pour chaque visiteur. Des répartiteurs de charge (load balancers) permettent d'aiguiller les visiteurs vers plusieurs machines physiques, etc.

L'approche de Varnish (un logiciel libre disponible sur www.varnish-cache.org) est celle d'un « proxy inverse » : c'est un serveur qui écoute les requêtes en provenance des clients, et les transmet au serveur Web applicatif proprement dit (Apache). Au passage, s'il voit que plusieurs visiteurs sollicitent la même ressource, il la demande une seule fois et la transmet ensuite à tous les visiteurs en même temps ; et s'il est autorisé à mémoriser une réponse, il ne la demande plus au serveur, pour un temps donné.

Varnish peut être configuré pour, en fonction de certains paramètres (URL de la ressource demandée, présence de tel cookie chez le visiteur, adresse IP du visiteur, etc.), demander la ressource à différents serveurs applicatifs, que dans son jargon il appelle « backends ».

Voici une petite vidéo qu'a publié la société qui s'est construite pour développer Varnish.

En bonus, quand Apache est planté, Varnish peut fournir la ressource demandée si elle est en cache, ou à l'inverse renvoyer une page informative au visiteur. C'est ce qui m'est arrivé tout à l'heure... Visiblement ça a plu à certains utilisateurs, qui exigent maintenant de savoir où est passée la si jolie page d'erreur (photo de baroug) !

Dans de prochains articles, j'indiquerai comment installer et configurer Varnish pour en tirer le maximum avec SPIP.

Utiliser CouchDB avec SPIP

Fil — 2011-01-08T14:10:13Z

CouchDB est un gestionnaire de base de données orienté documents, faisant partie du mouvement NoSQL : au lieu d'être ordonnée en lignes et en colonnes, la base est constituée d'une collection de documents au format JSON. On l'interroge par des requêtes HTTP. Ci-dessous, un exemple d'utilisation avec SPIP.

HTTP et JSON : la boucle (DATA) de SPIP peut nativement parler à CouchDB. Comme exemple d'application, voici un squelette permettant d'afficher les « câbles » diplomatiques américains révélés par Wikileaks.

(Pour en savoir plus sur CouchDB : http://couchdb.apache.org/)

La base de données

Le 6 décembre 2010, Benoît Chesneau annonçait qu'il mettait les cablegate à disposition dans une base CouchDB :

You can now replicate cables in your couchdb via https https://upondata.com/cablesgate , more mirroring soon. #cablesgate #wikileaks

On peut explorer cette base de données en utilisant la superbe interface Futon, associée à CouchDB : https://upondata.com/_utils/


Futon

Sous CouchDB, la liste des documents disponibles se trouve derrière une adresse du type URL_BASE_DONNEES/_all_docs, et les résultats sont renvoyés sous forme d'un tableau au format JSON, dont l'élément rows contient les résultats.

Une simple boucle permet de vérifier rapidement le contenu de cette base :

 {source json, https://upondata.com/cablesgate/_all_docs}
 {datapath rows}
 {pagination 10}
 >
 [(#VALEUR|print)
]

(On a ajouté la pagination car la base contient déjà plus de 1500 documents).

Résultat :

00HARARE5461, 00HARARE5461, 1-ab2f3b839699e38a0ade9a69580d3807
00HARARE6677, 00HARARE6677, 1-ff69b744322ed2ad40684a3049438a76
01PRETORIA1173, 01PRETORIA1173, 1-17ae5eba0e6fa54f756e11c33db3c12c
01VATICAN1261, 01VATICAN1261, 1-5b2bb5179171b8fdb6cf5c49e70f7efc
01VATICAN3507, 01VATICAN3507, 1-cf8f30b56ae3b022a9a13c18e9861fdf
02BRASILIA4227, 02BRASILIA4227, 1-618545c581de8c36034e69125ab91b91
02ROME1196, 02ROME1196, 1-c3886574e19883f1710941c5306f58c8
02VATICAN819, 02VATICAN819, 1-118b2bb09f1aeb02771368f88ec03439
03ABUDHABI2641, 03ABUDHABI2641, 1-9253471e5f4f776c89032acb245cab44
03BRASILIA3122, 03BRASILIA3122, 1-03f664271441db15b2a72730af841c11

Ces valeurs sont la clé, l'identifiant (dans ce cas, égal à la clé), et le numéro de révision de chaque document.

Pour aller chercher un document particulier il suffit de solliciter l'URL correspondant à son identifiant : par exemple https://upondata.com/cablesgate/00H... ; le document s'affiche alors au format JSON.

Une deuxième boucle (DATA) permet d'afficher proprement les champs du document :

 {source json, https://upondata.com/cablesgate/00HARARE5461}
 >
 [#CLE

 (#VALEUR|print)
]

Résultat :

_id

00HARARE5461

_rev

1-ab2f3b839699e38a0ade9a69580d3807

origin

CONFIDENTIAL

date_time

2000-09-27 14:02

body

C O N F I D E N T I A L SECTION 01 OF 02 HARARE 005461 SIPDIS NSC FOR SENIOR AFRICA DIRECTOR GAYLE SMITH LONDON FOR CHARLES GURNEY PARIS FOR BISA WILLIAMS PASS USTR FOR ROSA WHITAKER EO 12958 DECL : 09/21/10 TAGS PGOV, PINS, ZI, MDC, ZANU-PF (...)

classification

2010-12-18 21:09

header

This record is a partial extract of the original cable. The full text of the original cable is not available. (...)

refererence_id

00HARARE5461

Remarque : à l'inverse des boucles standard de SPIP, basées sur SQL, on voit donc qu'il faut ici appeler des services différents pour obtenir soit un document, soit une liste de documents.

Ajoutons maintenant quelques bidouilles décoratives :
— pagination
— passage de l'identifiant du câble par la variable #ID
— utilisation du critère {si #ID} pour ne lancer la qu'en présence d'un identifiant
— gestion des sauts de ligne, marqués dans le champ body par la séquence

Et nous obtenons, en deux boucles, une première version de notre application :


 [(#PAGINATION)
]
 
  {source json, https://upondata.com/cablesgate/_all_docs}
 {datapath rows}
 {pagination 10}
 >
  >#VALEUR{id}

 
 

 
 
 
 #ID

  {source json, https://upondata.com/cablesgate/#ID}
 {si #ID}
 >
 [#CLE

 (#VALEUR|print|replace{
,
})
]

Trier par date, afficher le sujet

Pour aller plus loin, on veut pouvoir afficher notre liste de documents non pas dans l'ordre de stockage dans la base de données, mais selon leur date de publication (donnée dans le champ classification de la base de Benoît... on dirait qu'il s'est un peu emmêlé les pinceaux dans ses nommages...) ; on veut aussi afficher à côté le sujet du câble, qu'il va falloir extraire du champ body de chaque document.

Pour cela, il faut ajouter une vue à la base de données. Comme celle-ci est gérée par Benoît Chesneau, nous n'y avons pas accès en écriture, et ne pouvons donc rien y ajouter. Nous allons donc créer une base CouchDB nous appartenant, dans laquelle on va recopier (« replicate » en langage CouchDB) celle de Benoît, puis ajouter notre vue.

Deux méthodes :
— soit on installe CouchDB sur notre serveur http://wiki.apache.org/couchdb/Inst...
— soit on crée un compte hébergé sur www.couchone.com

Dans les deux cas, l'interface Futon permet de naviguer facilement dans les données. Une fois notre base créée, on utilise le menu Replicator pour lui dire de recopier la base source https://upondata.com/cablesgate dans la nôtre.


Replicator

Nous ajoutons ensuite une vue (view) :


View

Voici le code de notre vue ; c'est un JSON décrivant une fonction map écrite en javascript.

{
 "classification": {
 "map": "function (doc) {
 if (doc.body && (doc.subject = doc.body.match(/SUBJECT:(.*?)

/))) {
 doc.subject = doc.subject[1].substr(0,300);
 }
 else {
 doc.subject = 'Untitled';
 }
 emit(doc.classification, {
 date_time:doc.date_time,
 subject:doc.subject,
 origin:doc.origin||null
 });
 }"
 }
 }

Comme on l'a vu avec la boucle ci-dessus, chaque document contient un champ classification avec la date de mise en ligne du document.

Notre fonction map: va donc émettre, pour chaque document, une clé correspondant à cette valeur doc.classification, ce qui permettra de trier les résultats selon cette valeur. On émet aussi, en valeur, un sujet extrait à coup d'expression rationnelle du doc.body (quand c'est possible), ainsi que les champs date_time et origin du document.

Dès lors, si on appelle l'URL /_design/sort/_view/classification sur notre base CouchDB, on obtient la liste des câbles triés par date de mise en ligne, ainsi que leur sujet et niveau de classification.

{
 "id":"04ANKARA348",
 "key":"2010-11-28 18:06",
 "value":{
 "date_time":"2004-01-20 12:12",
 "subject":"Untitled",
 "origin":"CONFIDENTIAL"
 }
 },
 {
 "id":"04ANKARA7211",
 "key":"2010-11-28 18:06",
 "value":{
 "date_time":"2004-12-30 05:05",
 "subject":"Untitled",
 "origin":"SECRET"
 }
 },
 {
 "id":"05ABUDHABI2178",
 "key":"2010-11-28 18:06",
 "value":{
 "date_time":"2005-05-16 09:09",
 "subject":"Untitled",
 "origin":"SECRET"
 }
 },
 {
 "id":"05ANKARA1730",
 "key":"2010-11-28 18:06",
 "value":{
 "date_time":"2005-03-25 09:09",
 "subject":" TURKEY ADRIFT",
 "origin":"CONFIDENTIAL"
 }
 },
 ...

Pour les obtenir dans l'ordre inverse (les plus récents en premier), on utilise l'URL /_design/sort/_view/classification?descending=true.

Notre application complète

Voici au final le squelette de notre application complète. Ici, on a installé CouchDB en local, l'URL de notre base est http://127.0.0.1:5984/cablegate

#SET{base,http://127.0.0.1:5984/cablegate}
 
 
 [(#PAGINATION)
]
 
  {source json, #GET{base}/_design/sort/_view/classification?descending=true}
 {datapath rows}
 {pagination 5}
 >
  >#VALEUR{id}

 #VALEUR{value/subject}

 [(#VALEUR{value/date_time})] | #VALEUR{value/origin}
 
 

 
 

 
 
 
 #ID

  {source json, #GET{base}/#ID}
 {si #ID}
 >
 [#CLE

 (#VALEUR|print|replace{
,
})
]

Résultat :

0 | 5 | 10 | 15 | 20 | 25 | 30 | 35 | 40 | ...

09BRASILIA1239
HANDLING VISA REQUEST FROM BRAZILIAN INVOLVED IN THE 1969 KIDNAPPING OF THE U.S.
2009-10-15 17:05 | SECRET//NOFORN

04BRASILIA2803
Untitled
2004-11-12 16:04 | UNCLASSIFIED//FOR OFFICIAL USE ONLY

10SANTIAGO25
Meet Chile's President-Elect, Sebastian Pinera
2010-01-22 20:08 | CONFIDENTIAL

09SANTIAGO867
CHILE: Conservatives Beat Back Skeleton in Pinera's Closet
2009-10-09 15:03 | CONFIDENTIAL

08SANTIAGO249
CHILE'S "NEXT PRESIDENT" WILL PROPOSE A "NEW DEAL": A TAD EARLY FOR COMPARISONS TO FDR
2008-03-17 14:02 | CONFIDENTIAL

04BRASILIA2803

_id

04BRASILIA2803

_rev

1-385f6e7e62f2249fb1877e04b9819021

origin

UNCLASSIFIED//FOR OFFICIAL USE ONLY

date_time

2004-11-12 16:04

body

UNCLAS BRASILIA 002803 SIPDIS SENSITIVE PORT-AU-PRINCE FOR AMB. FOLEY E.O. 12958 : N/A TAGS : PREL PGOV BR HA POL MIL ¶ 1. (SBU) On November 9, Brazilian Federal Deputy Maninha paid a courtesy call on Ambassador Danilovich. Maninha is the current president of COPA (Confederation of the Parliaments of the Americas), and this week she...

classification

2010-12-28 00:12

header

This record is a partial extract of the original cable. The full text of the original cable is not available.

refererence_id

04BRASILIA2803

La démo est visible ici : http://zzz.rezo.net/cablegate/.

* * *

J'espère que cet exemple vous aura donné envie de jouer avec SPIP et CouchDB. N'hésitez pas à utiliser le forum ci-dessous pour partager vos expériences.

Plugin Flattr pour SPIP

Fil — 2010-09-01T16:20:46Z

Comme promis dans l'article Flattr-ies et Kurbettes, voici un plugin facilitant l'intégration dans SPIP du système de microdons Flattr.

Téléchargement

Le plugin est développé sur SPIP-Zone, disponible via la commande

svn co svn://zone.spip.org/spip-zone/_plugins_/flattr/

On trouvera aussi le plugin sous forme de ZIP à l'adresse http://files.spip.org/spip-zone/fla...

Version courante : 0.2

Configuration

Ce plugin se configure avec CFG ; on y indique le UserID du compte Flattr qui recevra les microdons. On peut aussi préciser le type de contenus qu'on propose sur le site, dans la nomenclature de Flattr : text, images, video, audio, software...

Intégration

Pour l'intégrer à son site SPIP, on utilise un modèle article_flattr.html ; ce modèle peut s'intégrer :
— au cas par cas, en saisissant dans le corps ou le post-scriptum d'un article un contenu du type ;
— dans un squelette (par exemple extra/article.html en y indiquant #MODELE{article_flattr,id_article}.

Un autre modèle permet de flattr la page d'accueil du site : ou #MODELE{site_flattr}.

Note sur le javascript. Le bouton standard que propose Flattr ne convient pas, car tel un mouchard il envoie chaque visiteur de votre site sur le site Flattr.com ; en termes de privacy c'est assez inacceptable. Nous avons donc dans ce plugin un JS un peu plus élaboré, qui ne contacte Flattr.com que lorsque l'utilisateur appuie sur le bouton. Le JS principal est servi par votre site ; vous pouvez, si vous mettez le bouton partout, l'intégrer dans votre inc-head ; dans le cas contraire, il sera chargé à la demande en fonction du besoin, lors du survol du bouton.

Paramétrage

Les paramètres par défaut du bouton sont :
— title : titre de l'article.
— description : descriptif de l'article, coupé à 1000 car.
— uid : User ID configuré dans le CFG
— hidden : true ou false (CFG)
— button : default
— tags : mots-clés de l'article
— category : text (ou autre, défini dans CFG)

Il est possible de modifier ces paramètres en les passant directement au modèle, ainsi par exemple si l'article 67 représente une vidéo, on indiquera :

Si un article correspond à une flatterie pour un autre auteur que celui défini dans le CFG, on passera son uid au modèle :

Idem pour les autres paramètres.

A noter : si vous ne créez pas vos ‘things' à la main depuis l'interface de Flattr, ils sont créés lors du premier microdon effectué dessus à partir de votre site. Dès lors qu'un article (à une certaine URL) a été créé dans Flattr, ses paramètres sont figés ; vous pouvez encore les éditer, mais uniquement à partir de votre dashboard sur le site Flattr.

Démo

Le bouton est en action ici-même :

Plugin Flattr pour SPIP

Présentation de Textwheel

Cerdic, Fil — 2010-08-15T14:53:04Z

Textwheel — littéralement, « la roue du texte » — est un projet visant à simplifier l'écriture de règles de transformation d'un texte d'un format vers un autre.

Quand on s'intéresse aux systèmes de publication sur Internet, on a la forte impression que chacun réinvente la roue de son côté, refaisant pour chaque composant du logiciel sa propre implémentation.

Textwheel s'attaque à l'un de ces composants : la transformation d'un texte « brut » en texte présentable à l'écran.

Par exemple, sous SPIP, on transforme :
{Hello} {{World}}
en :
Hello World

Sous Textile, on transforme :
_Hello_ *World*
en :
Hello World

En BBCode, on aura :
[i]Hello[/i] [b]World[/b]

L'ennui jusqu'ici c'est que chaque logiciel (gestion de contenu, gestion de forums) est livré avec ses propres raccourcis, dans sa propre implémentation. Il n'y a donc ni standard, ni possibilité d'échanger, ni possibilité de modifier ses raccourcis. Textwheel est une proposition visant à répondre à ces soucis d'interopérabilité.

Le principe : avec Textwheel, plutôt que de coder une fonction qui effectue ces règles de transformation, on les décrit dans un fichier de configuration (ex : spip.yaml), au format très simple (YAML). Textwheel se chargera d'appliquer ces règles.

Ainsi, Textwheel sépare la création des « raccourcis d'édition » de leur implémentation technique.

Avec Textwheel, les raccourcis de SPIP se programment donc ainsi :

strong:
 match: [ "{{", "}}" ]
 replace: [ "", "" ]

italics:
 match: [ "{", "}" ]
 replace: [ "", "" ]

Ceux de Textile :

strong:
 match: "/\*(\w*)\*/U"
 replace: "\1"

italics:
 match: "/_(\w*)_/U"
 replace: "\1"

et le BBCode :

strong:
 match: [ "[b]", "[/b]" ]
 replace: [ "", "" ]

italics:
 match: [ "[i]", "[/i]" ]
 replace: [ "", "" ]

On voit qu'il est dès lors très facile d'ajouter les raccourcis BBCode ou Textile dans SPIP, ou l'inverse, en manipulant des fichiers de configuration. Bien entendu les cas plus complexes (callbacks, expressions rationnelles) sont prévus.

Avantages de Textwheel

L'interopérabilité entre logiciels n'est pas le seul avantage.

Extensibilité. Il est plus aisé pour un utilisateur de manipuler un fichier de configuration au format établi, que de se plonger dans des modifications de code qui peuvent sauter à chaque mise à jour.

Traitements. Dès lors que les raccourcis sont codés de manière descriptive, et non pas fonctionnelle, il est possible de leur faire subir des traitements qui ne se limitent pas à les appliquer à un texte. On peut par exemple les appliquer à la chaîne sur l'ensemble des textes d'une base de données, et voir lesquels sont utilisés, combien de fois, à quels textes... et à quelle vitesse.

Rapidité. Ce qui permet de détecter des règles mal programmées, inutiles, trop lentes ou pas efficaces. En appliquant cette méthodologie aux raccourcis de SPIP, nous avons pu en quelques jours diviser par deux le temps de calcul des textes (sur certaines bases de texte d'usage réel).

Compilation. Une autre sortie possible pour un fichier de raccourcis, c'est une compilation sous forme de code dans un langage arbitraire (par exemple : PHP, python, ruby, javascript, C...). Cette approche devrait permettre à terme de retrouver les mêmes raccourcis sous différents logiciels, quel que soit leur langage de programmation, et aussi bien côté serveur (PHP, python) que client (javascript).

Tests unitaires. Jusqu'ici les raccourcis avaient tendance à « casser » dès lors qu'on mettait les mains dans le code, et il était bien difficile, lorsqu'on constatait un bug, de voir à quel niveau des traitements le résultat devenait non conforme. Maintenant que notre moteur peut comparer, pour chaque règle, le résultat obtenu avec sa valeur attendue, un jeu de tests peut non seulement nous dire si quelque chose a changé, mais nous dire aussi précisément quoi.

Évolutivité. Cette approche devrait permettre de redynamiser le travail sur les raccourcis (introduction de nouveaux raccourcis, suppression de raccourcis obsolètes, amélioration de raccourcis mal foutus...). Car on peut imaginer construire un outil qui permettra de signaler le cas échéant au webmestre qui met à jour son site qu'il aura, par exemple, deux articles à vérifier (et lesquels) suite à une amélioration du code. Outil qui sera basé sur de simples fichiers YAML.

Télécharger

Le projet est développé, en ce moment, via git et sur github.com ; on avance en parallèle sur le moteur (http://github.com/Cerdic/textwheel/...) et sur le plugin SPIP (http://github.com/Cerdic/textwheel/).

Pour télécharger ce dernier par svn, utiliser la commande suivante :

svn checkout http://svn.github.com/Cerdic/textwheel.git/ plugins/textwheel/

Le plugin pour SPIP donne une page ?exec=tw dans l'espace privé qui permet de voir ce qui change entre textwheel et la fonction propre() classique de SPIP : les quelques textes où le rendu n'est pas exactement identique sont signalés, ainsi que le temps passé dans chaque rule, et le temps total des calculs.

Participer

Si cette rapide présentation vous a alléché, sachez que toutes les participations sont les bienvenues.

Le projet est, pour démarrer, codé en anglais et en PHP. Il offre d'ores et déjà des spécifications en version 0.1, une implémentation en PHP, et un plugin pour SPIP qui remplace le moteur historique de SPIP par cette nouvelle approche.

Nous n'en sommes qu'au début. Il y a beaucoup à faire sur ce projet, qu'il s'agisse d'améliorer les specs, de contribuer de la documentation, d'établir des cas tests, de coder des implémentations dans d'autres langages (ruby, javascript), etc.

Une communauté de développeurs se met en place sur la mailing-list textwheel@rezo.net ; URL : http://listes.rezo.net/mailman/listinfo/textwheel

A bientôt !

Bloquer les mouchards avec Ghostery

Fil — 2010-05-20T21:26:12Z

Mon billet pour Bloquer les mouchards de Facebook a eu pas mal de succès, signe que l'internaute commence à en avoir assez d'être pisté dans chaque recoin du Web. Y a-t-il d'autres solutions que mon bricolage ?

Ghostery

Ghostery propose une extension pour Firefox qui détecte, affiche et élimine les mouchards du Web. Merci à cy_altern qui, dans le forum, a signalé cette solution.

Il s'agit d'un plugin à vocation didactique car, quand on l'active, il ne fait qu'afficher, dans une petite fenêtre en haut à droite de la page Web, la liste des mouchards détectés dans la page. Il n'est pas rare d'en voir 1, 2 ou 3 à chaque page, avec les mêmes qui reviennent sans arrêt : Google, Facebook, Xiti, DoubleClick, etc.

L'interface permet de bloquer un à un ces réseaux de traqueurs et de « pub comportementale ». En allant dans les préférences de l'extension, on peut aussi les bloquer tous en un seul clic.

Pour reprendre ensuite une navigation normale, il suffit de désactiver l'affichage de la liste. Seul un petit fantôme bleu en bas de la page permet de temps à autre de savourer le nombre de mouchards qui restent à la porte.

Ghostery est, bizarrement, édité par la société Better Advertising (sic), qui conseille aussi les réseaux de publicitaires dans leur gestion des questions de privacy. Le plugin permet, pour chaque mouchard, d'aller consulter une page décrivant le réseau et de consulter sa politique de confidentialité, de façon à améliorer la « confiance » des internautes dans la pub (re-sic).

À noter : Ghostery ne fonctionne pour l'instant que pour Firefox ; sa version pour Internet Explorer ne bloque qu'une partie des mouchards, et sa version pour Chrome ne fait que les détecter (pas de blocage).