These templates are optimized for viewing on an iPad

ZZZ

Télécharger flickrstore

Pour Mac OS X

Grâce à Platypus voici une version drag’n’drop pour Mac OS X. On peut :
— la lancer d’un double-clic pour récupérer les données de Flickr et poser les tags file:md5 sur les photos existantes ;
— déposer-glisser des fichiers image ou des répertoires pour les sauvegarder dans Flickr.

Zip - 191.7 ko
Flickr Store 0.5 pour Mac OS X

flickrstore

flickrstore est développé sous git : on peut le visualiser ici :
https://github.com/Fil/flickrstore (nouvelle version : juillet 2014).

phpFlickr

La librairie phpFlickr de Dan Coulter est téléchargeable depuis le site http://phpflickr.com/

API key

Pour solliciter une clé rendez-vous sur le site Flickr, connectez-vous et allez à la page http://flickr.com/services/. La clé doit ensuite être enregistrée dans le fichier api_key.inc à côté du fichier flickrstore.

Une astuce : rotation automatique

Si comme moi vous sauvegardez le répertoire iPhoto Library/Originals/, les photos y sont conservées dans le sens horizontal. Mais certains appareils signalent qu’on peut les redresser en vertical, le cas échéant. Flickr sait détecter ce signal : il faut activer l’option sur la page http://www.flickr.com/account/prefs....

*

Filesystem cache for Drupal

This is a drop-in replacement for Drupal 6’s cache system. We avoid a lot of problems by using a filesystem-cache in lieu of the classic database-cache.

Our site with Drupal 6.26 (published 2012-05-02) kept crashing because it filled its `cache_menu` table too quickly.

This is a drop-in replacement for includes/cache.inc that makes Drupal use a filesystem-based cache instead of the database.

Installation

  1. Download the file (http://trac.rezo.net/trac/rezo/brow...)
  2. Rename the old includes/cache.inc to includes/cache.classic.inc, in case you want to go back.
  3. Install this file as includes/cache.inc.
  4. By default, we use the sys_get_temp_dir() command to learn where to store the cache files. If you prefer to see what happens, create a tmp/ directory (with proper write permissions for www-data and a security .htaccess file); the code will use this directory if it exists.

Compatibility

This has not been tested yet on any other version than Drupal 6.26. If it works for you, please comment in the forum below.

How it works

When Drupal tries to cache some data it uses

cache_set($cid, $data, $table, $expire, $headers)

… our code computes a 4-hexdigits hash key from (cid, table), and stores the values (data, headers) in the file named tmp/a0/3c.cache.

When Drupal requests this value from the cache, we load the values from the same file, check that the cid and table match the request, that the cache has not expired, and then return the value.

There will be collisions in this small space (16^4= 65,536 files “only”). But that’s a deliberate feature, because it allows us to avoid using a costly garbage collector [1].

 

P.S. Something better probably exists somewhere. I just couldn’t find it; if this is useful for you, or if you have suggestions, please comment below.

*

[1] This approach was initially developed for SPIP, see Memoization.

Réparer le charset d’une base SPIP

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

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.

Ce logiciel est en version bêta : il est loin d’être totalement mûr, mais déjà utilisable (et utilisé !).

Lien de téléchargement :


Après téléchargement de l’image disque, l’ouvrir puis recopier l’application dans le dossier Application ; déposer aussi l’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

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.

*