Après quelques minutes de recherche, j’ai résolu le problème en plaçant ces quelques règles supplémentaires dans mon nginx.conf:

location / {
    set $mobile_ua '0';

    if ($http_user_agent ~* '(iPhone|iPod|mobile|Android|2.0\ MMP|240x320|AvantGo|BlackBerry|Blazer|Cellphone|Danger|DoCoMo|Elaine/3.0|EudoraWeb|hiptop|IEMobile)') {
        set $mobile_ua '1';
    }
    # ...directives proxypass...
    proxy_cache_key imil.net$request_uri$mobile_ua;
    # ...plein d'autres trucs...
}

Explication: on initialise une variable $mobile_ua à 0, si le User Agent match l’une des chaînes de caractères listées dans la condition if, la variable $mobile_ua est placée à 1.
La clé de cache étant maintenant composée également de cette variable, nous disposons de deux espaces de cache distincts, un pour les mobiles, l’autre pour le reste.

mmmmm nginx.

Ce billet servira de README à ce petit bout de code perl qui utilise les modules Config::IniFiles et WordPress::XMLRPC, lequel devrait arriver dans pkgsrc dès que je reçois l’aval de mon sponsor :)

L’utilisation de cet outil est simplissime, créez tout d’abord un fichier ~/.wpostrc répondant au format suivant :

[monbuergl]
user=monuser
passwd=monpass
url=http://monbuergl.com/xmlrpc.php

Créez un fichier contenant votre billet ayant le format suivant :

title: mon titre convivial

categories: ['categorie1', 'categorie2']

Mon texte passionnant racontant mes aventures

Appelez ensuite le script de cette façon pour ajouter votre billet :

./wpost.pl monbuergl add fichier-post

De cette façon pour le modifier (en ayant préalablement modifié son contenu) :

./wpost.pl monbuergl mod fichier-post

Et finalement de cette façon pour l’effacer :

./wpost.pl monbuergl del fichier-post

Si votre WordPress n’est pas configuré pour de l’UTF-8, placez la variable $use_utf8 à 0.

Attention, cette version étant une première mouture, les posts ne sont pas publiés par defaut, si vous êtes satisfaits du fonctionnement de wpost.pl, editez le et placez la variable $publish à 1.

Par ici la bonne soupe !

update: www/p5-WordPress-XMLRPC est désormais disponible dans pkgsrc

Restait le nuage de Tags. La fonction wp_tag_cloud() fonctionne parfaitement, mais il lui manque quelque chose qui me plaisait bien: un système de colorisation rendant les tags de plus en plus foncés fonction du nombre de liens qu’ils comportent. C’est futile, mais j’aimais bien. Du coup, puisque la fonction wp_tag_cloud() permet, lorsqu’on lui passe en argument format=array, de retourner un Array, je me suis fendu d’un minuscule plugin permettant d’associer des couleurs differentes au tags :

<?php
/*
Plugin Name: Colorize Tags
Plugin URI: http://imil.net
Description: Colorize tags
Author: iMil
Version: 0.0
Author URI: http://imil.net/
*/
function color_tags()
{
    if ( function_exists('wp_tag_cloud') ) {
        // WARNING: may be unportable
        $tags = wp_tag_cloud('smallest=8&largest=16&format=array');
        foreach ($tags as $tag) {
            if (preg_match('/title=[\'\"](\d+)/', $tag, $matches)) {
                $fact = $matches[1];

                $fact = $fact % 5;
                if (++$fact > 10) {$fact = 10; }
                ?><li class="< ?php echo "t$fact"; ?>">< ?php
                echo "$tag</li>\n";
            }
        }
    }
}
?>

Ainsi, chaque Tag sera contenu dans un <li> qui aura pour id quelque chose de la forme "t[numero]", ou "numero" croit fonction du nombre de liens associés au Tag. Reste alors à ecrire la CSS, soit quelque chose du genre :

ul#tagcloud li.t1 a { color:#999999; font-size: 100%; }
ul#tagcloud li.t2 a { color:#8d8d8d; font-size: 110%; }
ul#tagcloud li.t3 a { color:#818181; font-size: 120%; }
ul#tagcloud li.t4 a { color:#757575; font-size: 125%; }
ul#tagcloud li.t5 a { color:#686868; font-size: 130%; }
ul#tagcloud li.t6 a { color:#5c5c5c; font-size: 135%; }
ul#tagcloud li.t7 a { color:#505050; font-size: 140%; }
ul#tagcloud li.t8 a { color:#444444; font-size: 145%; }
ul#tagcloud li.t9 a { color:#383838; font-size: 150%; }
ul#tagcloud li.t10 a { color:#313131; font-size: 160%; }

Pour obtenir le résultat ci à droite.

Alors je vais evidemment jeter un œil sur la homepage du plugin simple-tagging ou je lis que ce dernier n’est simplement “pas supporté” sous WP 2.3. toussote. Je lis également un peu partout que plusieurs choix s’offrent à moi :

. passer au plugin “simple-tags”, du même auteur
. passer au système de tagging de WP 2.3

J’avais bien aimé les features de simple-tagging, alors mon choix se porte evidemment sur cette fameuse nouvelle version. J’installe, j’active, et non: “gnagnagna plugin triggered a fatal error gnagnagna”. Bien. N’ayant pas spécialement envie de passer des heures à comprendre ce qui foire, je switche sur le système de tagging de WP 2.3. Seulement voila, y’a un truc que j’aimais bien dans simple-tagging, c’était la possibilité d’embedder les tags dans le contenu du texte, et cette feature là n’existe pas dans le système “natif” de WP. On me fait savoir que ce serait facile à implémenter et qu’il existe des hooks pour se simplifier ce type de modification. Mais je le redis, j’aime pas le PHP, et j’ai fondamentalement pas envie de me lancer dans l’ecriture d’un truc que je vais devoir maintenir de version en version. Donc, non.

Finalement, après une séance de lecture du code de base de WP, je m’aperçois que tags et catégories sont gentiment associés, je me demande alors si en remplaçant simplement les liens associés aux tags /?tag= par /?cat=, je ne pourrais pas, pour l’utilisation que je fais de ce plugin, feinter bêtement. Et finalement, si. Du coup, messieurs mesdames, si vous souhaitez garder votre vieux plugin simple-tagging, remplacez simplement dans l’interface Tags -> Tag search base la valeur tag par cat, et vous vous épargnerez bien des souffrances.
En prime, afin de s’assurer que d’anciens liens sur des categories fonctionneront toujours, voici une petite regle lighttpd :

        url.rewrite-once = (
                "^/wp/.*\?tag=([^/]+)" => "/wp/index.php?cat=$1"
        )

Oh, dans la foulée, vous verrez probablement dans vos error logs des lignes de ce type :

2008-03-16 12:49:09: (mod_fastcgi.c.2502) FastCGI-stderr: WordPress database error Table 'blah.wp_post2cat' doesn't exist for query SELECT p2c.category_id AS cat_id, COUNT(p2c.rel_id) AS numposts,
                                UNIX_TIMESTAMP(max(posts.post_date_gmt)) + '2' AS last_post_date,
                                UNIX_TIMESTAMP(max(posts.post_date_gmt)) AS last_post_date_gmt
                                FROM wp_post2cat p2c
                                INNER JOIN wp_posts posts ON p2c.post_id=posts.id
                                WHERE 1 = 1
                                AND posts.post_type = 'post' AND posts.post_status = 'publish'
                                AND posts.post_date_gmt < = '2008-03-16 11:49:09'

                                GROUP BY p2c.category_id
                                ORDER BY numposts DESC 

Ceci est du à la disparition de la table post2cat, génératrice de bien des incompatibilités de plugins WP < 2.3, perso, j'ai modifié cette requete dans le fichier simpletagging.php par :

                        $query = "SELECT term_taxonomy_id AS cat_id, COUNT(object_id) AS numposts,
                                UNIX_TIMESTAMP(max(posts.post_date_gmt)) + '" .  get_option('gmt_offset') . "' AS last_post_date,
                                UNIX_TIMESTAMP(max(posts.post_date_gmt)) AS last_post_date_gmt
                                FROM {$wpdb->term_relationships}
                                INNER JOIN {$wpdb->posts} posts ON object_id=posts.id
                                WHERE 1 = 1
                                {$posts_pages}
                                AND posts.post_date_gmt < = '" . gmdate("Y-m-d H:i:s", time()) . "'
                                {$restrict}
                                {$timelimit}
                                GROUP BY term_taxonomy_id
                                ORDER BY numposts DESC ";

Pas vraiment certain que ça donne le résultat voulu, mais d'une y'a plus d'erreur, et de deux tout semble fonctionner.

C'était mon tip pourri du jour.
]]> http://imil.net/wp/2008/03/16/simple-tagging-et-wp-23/feed/ 2 http://imil.net/wp/2007/05/28/tes-trop-vip/ http://imil.net/wp/2007/05/28/tes-trop-vip/#comments Mon, 28 May 2007 20:44:54 +0000 iMil http://imil.net/wp/?p=135 waiii alors j’entend d’ici “haooon iMil il a cedé aux sirènes du web deux-zero toussaaaa, vla qu’il fait dla CSS et du PHP”. Bon ok ouais chu un peu tombé dans le hype-fashion, mais avouez, le ptit “Tags cloud” là, c’est pas convivial tout plein ? Pour réaliser cette petite mignonnerie, j’ai été piocher ici, et pour réparer l’import de categories-toutes pas-fashion en Tags, il faut suivre ce que dit le monsieur ici. Le cas échéant, on se mange un joli :

WordPress database error: [Unknown COLUMN ‘p2c.category_id’ in ‘on clause’] SELECT cats.cat_name, p2c.post_id FROM wp_posts posts INNER JOIN wp_categories cats ON (p2c.category_id = cats.cat_id) LEFT JOIN wp_post2cat p2c ON (posts.ID = p2c.post_id) WHERE posts.post_status IN (’publish’) AND posts.post_type <> ‘page’

Ce qui n’est pas du meilleur effet en soirée.
Accessoirement, le plugin en question est fort bien réalisé, souple et très complet.

Presque rien à voir, depuis la migration en WP 2.2, drivel ne semble plus vouloir pusher, pourtant il se connecte bien au xmlrpc et recupère correctement le contenu. Du coup, j’ai switché sur BloGTK, un peu plus intrusif à mon goût, mais il a ceci de pratique qu’il fonctionne. J’fais ma feignasse mais ça me saoule vraiment très fort de debugger une appli GTK là…

Puisque finalement j’embarque tous mes machins sur mon kimloli, je me suis finalement décidé à upgrader mon vieux wordpress poussiereux dans une version et un design un peu plus récents.

Initialement, le plan était de partir sur Pivot, un web log full flat-file. J’ai commencé à pas mal aimer dans les premières heures, et puis rapidement, j’ai senti les limitations du soft (pas du tout liées à l’absence de database par ailleurs). Quand j’ai fini par aller retourcher des trucs dans le code lui même, je me suis dit que ce qui était sensé me faire gagner du temps deviendrait rapidement inmaintenable. Donc drop.

J’ai fini par jeter l’éponge et coller un mysql “low-conf” dont voici le my.cnf :

[mysqld]
skip-innodb
skip-networking
socket = /tmp/mysql.sock
skip-locking
key_buffer = 16K
max_allowed_packet = 1M
table_cache = 4
sort_buffer_size = 64K
read_buffer_size = 256K
read_rnd_buffer_size = 256K
net_buffer_length = 2K
thread_stack = 64K

Pour réaliser ce thème, je suis parti du magnifique template Glossyblue de N.Design, qui en plus d’être splendide, est extremement bien construit. C’est probablement l’une des CSS les plus lisibles et bien architecturées que j’ai lu.

Pour finir, le wordpress en question est servi par Lighttpd dont la souplesse, la rapidité et la conf sont un vrai bonheur. L’ensemble est gentiment jailé sur un FreeBSD 6.2.