Un blog inutile de plus... - Mot-clé - Pense-bête

Dotclear 2.24 et mises à jour...

ȷulmud — Sat, 24 Dec 2022 13:42:00 +0100

Aujourd'hui, la version 2.24 de Dotclear a été publiée officiellement. Cette version apporte pas mal de changements qui ont des impacts (entre autres) sur les plugins. Je vais donc m'atteler ces prochains jours à publier de nouvelles versions de mes greffons.

Voici l'ordre dans lequel je pense progresser :

imgWidthAndHeightAdder (un grand merci à Franck Paul pour la mise à jour du code de celui-ci) → billet d'annonce de la nouvelle version
BigRedButton → billet d'annonce de la nouvelle version
shortURL → billet d'annonce de la nouvelle version
autodump (pas un greffon en tant que tel) → billet d'annonce de la nouvelle version
randomPost → billet d'annonce de la nouvelle version
dcImageMetaExtender → billet d'annonce de la nouvelle version
contextNavigation → mise à jour privée
jmuExifInserter → ~~bloqué par un comportement étrange de la méthode strftime de Clearbricks~~ → problème de int / double sur un timestamp → mise à jour privée
jmuRedirect → mise à jour privée
jmuTemplate → mise à jour privée (mais je questionne son utilité réelle... il ne fait qu'ajouter une classe "me" sur les commentaires faits par l'auteur·ice du blogue, et je crois me souvenir que c'est une option par défaut maintenant)
jmuTweakUrls → mise à jour privée
photoblog2 → billet d'annonce de la nouvelle version
awstats → mise à jour privée
myLog → mise à jour privée
previewNav → mise à jour privée

Les greffons suivants ne seront PAS mis à jour :

fmyTweakUrls
publicCDN → mise à jour malgré tout effectuée...
vieDeMerde

À noter que, dans ces listes, certains greffons n'ont jamais été rendus public et ne le seront probablement toujours pas. C'est avant tout un pense-bête pour moi.

Si un de mes greffons vous tient particulièrement à cœur et vous bloque dans votre migration à Dotclear 2.24, signalez-le en commentaire, j'augmenterai alors sa priorité.

J'aime le web...

ȷulmud — Sat, 26 Mar 2011 11:09:00 +0100

Il y a des jours où je me dis que c'est quand même bien de vivre à l'ère du web.

D'un côté, nous avons le cycle de conférences TED "Ideas worth spreading"^[1], des conférences de haute qualité sur quantité de sujets différents. Elles sont toutes visibles sur le site web, en anglais, mais sous-titrées dans un grand nombre de langues différentes. Des heures de bonheur et de découvertes à disposition.

Seulement voilà, j'ai beaucoup de peine à me concentrer pour regarder une vidéo sur mon ordinateur : il y a beaucoup trop de sources de distraction (emails, messagerie instantanée, Twitter, ...) pour que j'y arrive. Heureusement, sur le site de TED, ils ont l'excellente idée de proposer le téléchargement des vidéos et je peux ainsi les regarder sur mon « media center » tranquillement.

Mais (il en faut bien un), les sous-titres, eux, ne sont pas proposés au téléchargement. Or j'aime bien regarder mes vidéos en anglais avec des sous-titres également en anglais (ça permet de rattraper le petit truc qui m'aurait échappé à l'écoute). Et c'est là qu'entre en scène le site TTSD : il permet de télécharger les sous-titres des vidéos TED ! Que du bonheur je vous dis !

J'adore cette émulation qui se produit naturellement dans l'univers du web. Une première personne met à disposition un service, et une autre, sans avoir aucun lien avec la première, peut mettre à disposition un autre service, s'appuyant sur le premier, mais en comblant ce qu'il considère être un manque du premier service.

Notes

[1] « Des idées qui valent la peine d'être répandues »

Trucs mplayer

ȷulmud — Sat, 13 Nov 2010 18:39:00 +0100

Deux opérations que j'ai dû faire récemment et dont je tiens à conserver une trace.

Extraire la bande son d'un DVD

mplayer -dvd-device <point de montage du lecteur> dvd://<titre> -chapter <chapitre début>-<chapitre fin> -vc dummy -vo null -af resample=44100 -ao pcm:waveheader:fast:file=<fichier de sortie>.wav

Notes :

<chapitre fin> est aussi inclus dans ce qui est exporté. Donc, pour exporter seulement le troisième chapitre, il faut utiliser -chapter 3-3.
L'extraction se fait à un taux d'environ 2.3x sur mon poste.

Voir aussi : axllent.org/docs/video/mencoder_dvd_to_mpeg4

Faire un film à partir d'une seule image et une bande son

ffmpeg -loop_input -shortest -i <image.jpg> -i <son.mp3> -acodec copy -b 200k -f mp4 <fichier de sortie>.mp4

Ohlala!

ȷulmud — Wed, 09 Sep 2009 18:17:00 +0200

Une chose est sure : lors de mon prochain passage à Paris, j'irai prendre un repas au restaurant Ohlala! Pourquoi ? Simplement parce que les propriétaires du lieu ont eu l'excellente idée de mandater Invader pour qu'il réalise une fresque sur l'un des murs du restaurant... et puisque je suis toujours autant fan du travail de cet artiste, je me dois d'aller voir cela.

Canaux DVB-T pour VideoLAN 0.9

ȷulmud — Wed, 13 Aug 2008 20:43:00 +0200

Paramétrisation de VideoLAN Client 0.9 pour l'utilisation la TNT avec l'antenne la plus proche de chez moi :

:dvb-frequency -> 754000
:dvb-bandwidth -> 8
:program
- TSR1 -> 257
- TSR2 -> 258
- SF1 -> 1
- TSI1 -> 513
:access-filter -> timeshift (permet de mettre en pause la TNT)

Et pour passer cela en streaming sur UDP, il faut ajouter les paramètres :

:sout=#standard{access=udp,mux=ts,dst=x.x.x.x:1234}

où x.x.x.x représente l'adresse IP de l'ordinateur de destination.

Si on veut quand même visualiser sur le serveur ce qui est envoyé, le paramètre sout devient :

:sout=#duplicate{dst=display,dst=standard{access=udp,mux=ts,dst=x.x.x.x:1234}}

Bien entendu, on peut également « s'amuser » à modifier le flux avant de l'envoyer (ici, je diminue la taille avec scale=0.75 et je réencode le tout en MPEG-2 Video à 4096 kbit/s et en ajoutant une petite touche de désentrelacement) :

:sout=#transcode{vcodec=mp2v,vb=4096,scale=0.75,deinterlace}:standard{access=udp.mux=ts,dst=x.x.x.x:1234}

Note : mes tests semblent indiquer que le flux est moins perturbé si on ne fait pas d'affichage local sur le serveur.

Nikon D300, Nikon View 6 et fichiers RAW 14 bits

ȷulmud — Sun, 27 Jan 2008 17:23:00 +0100

Si, comme moi, vous venez de vous acheter un des petits derniers reflex de chez Nikon et que vous préférez utiliser les anciennes versions des logiciels Nikon, faites très attention.

Je viens de découvrir (pour mon malheur) une certaine incompatibilité :

dès le premier jour, j'ai réglé mon D300 pour faire des photos avec des fichiers RAW codés sur 14 bits ;
j'utilise toujours Nikon Transfer, qui était livré avec Nikon View 6 ;
or, Nikon Transfer ne supporte pas du tout les fichiers NEF du D300... à tel point qu'il a détruit toutes les photos que j'avais prises jusqu'à maintenant lors de la copie sur mon disque dur !

La destruction se présente sous la forme de photos où tous les détails sont perdus et les photos presque entièrement blanches. Voici une illustration de ce problème, avec d'abord la photo après destruction et ensuite la photo telle qu'elle avait été prise :

J'espère que grâce à ces infos vous éviterez de faire la même bêtise que moi.

Bien entendu, juste après le transfert, j'ai comme toujours reformaté la carte mémoire. Je suis donc en train d'utiliser un logiciel de récupération de données pour essayer de retrouver les photos effacées.

Mise à jour d'un greffon de template sur Dotclear2

ȷulmud — Tue, 21 Aug 2007 20:19:00 +0200

Lors de la mise à jour d'un greffon proposant des fonctions de template, voici l'ordre dans lequel effectuer la mise à jour :

mettre à jour le greffon sur le serveur ;
mettre à jour les thèmes sur le serveur.

Si on inverse ces deux étapes, on risque fort de se retrouver avec un thème défectueux présenté aux visiteurs. Cela est dû au fait que le cache du moteur de template n'est mis à jour que lorsque les fichiers du thème ont été modifiés. Si on modifie d'abord le thème, les nouvelles (ou celles dont le nom a changé) fonctions de template n'existeront pas encore lors de l'affichage du thème et ne seront donc pas interprétées dans le cache.

Incompatibilités entre MultiViews et RewriteRule

ȷulmud — Fri, 19 Jan 2007 19:27:00 +0100

Situation : Apache 1.3, un fichier blog.php à la racine, qui prend en charge les URLs de type http://www.example.com/blog/post/... par le biais d'une option MultiViews activée dans le fichier .htaccess.

Problème : tout jeu de RewriteRule traitant des URLs commençant par blog/ ne fonctionne pas... C'est en effet l'option MultiViews qui prend le dessus, et les arguments suivant le "/" sont « transmis » au script blog.php avant même d'être interprétés par les RewriteRule.

Solution : Je n'ai pas réussi à trouver une solution propre permettant de faire cohabiter ces deux types de traitement. Par conséquent, j'ai dû rédiger un plugin pour DotClear2 (très fortement inspiré du plugin dc1redirect de la dcTeam) qui traite les règles de « rewriting » que j'aurais aimé mettre dans le fichier .htaccess...

Récupérer un flux RealAudio

ȷulmud — Sun, 07 Jan 2007 11:00:00 +0000

Trouvé là-bas : grimthing.com/archives/2004/05/20/recording-streaming-audio-with-mplayer/. Et recopié ici juste pour le retrouver facilement le jour où j'en aurai besoin...

The stream I want to record is already in the format I want

This simplifies things a bit. If the stream you want to record is already in the format you want to use, you can use the -dumpstream flag instead. Your streamrecorder script will look like this instead:

 [bash]
#!/bin/sh
mplayer -playlist /home/username/scripts/playlist.txt -dumpstream -dumpfile /home/username/FlockofSeagulls_`date +%b%d` -vc dummy -vo null ;

This will result in a file called FlockofSeagulls_May20, without a file extension, in username’s home directory. This eliminates the intermediate temporary file and the encoding step. You can add the extension after `date +%b%d` just like in the previous script if you want. It doesn’t matter as MPlayer doesn’t require the extensions in order to play the file but your desktop environment may like the extensions in order to associate the file with whichever media player you’d prefer when you click it in your file browser.

What’s the deal with the playlist flag?

If you’ve been to this site before, you may notice the -playlist switch that was talked about in the MPlayer playlist, and Cron-MP3 Alarm Clock articles. In order to understand why you need the playlist switch when playing streaming audio, you need to understand a bit more about how streaming audio works.

Each streaming format has a kind of playlist file that your music player uses to redirect it to the actual music stream. For Windows Media it’s .asf, for Real Audio it’s .ram, MP3 uses .m3u and .pls. Even though each format has it’s own unique file extension, each file is basically the same. They’re just text files with urls pointing to the actual streams. Take your editor and open the playlist.txt file and see for yourself. If you see one of those file extensions, you’ll need to download the playlist and use the -playlist switch to play/record those streams.

Ogg, however, is an exception. Most Ogg streams, such as those from Icecast servers, don’t require the -playlist switch because the server handles all of the redirection without the need for a playlist. Those Ogg streams that do require the switch are usually just a static directory full of oggs. In such an event, the static directory versions usually implement a playlist file and use the same file extensions as MP3.

In theory, the -playlist switch doesn’t require the playlist file to reside on your hard drive. You should be able to just type mplayer -playlist http://full/url/to/playlist.pls and it should work. However, I’ve had mixed results with that method. Downloading the playlist to hard drive has worked for me every time. Feel free to experiment using the URL instead of the downloaded file, as your results may differ from mine.

Text by Philip McClure

Traduction d'un plugin DotClear2

ȷulmud — Sun, 31 Dec 2006 09:09:00 +0000

La méthode choisie dans DotClear2 pour la traduction des plugins est basée sur gettext, et est fondamentalement différente de celle qui était utilisée dans DotClear 1. Puisque j'ai découvert ce monde en tentant de traduire mon premier plugin, voici quelques notes sur la manière de procéder pour générer les fichiers de traduction.

Pour la première traduction d'un nouveau plugin :

  xgettext -L PHP --keyword=__ *.php
  mv messages.po messages.pot
  mkdir -p locales/fr
  msginit --locale=fr -o locales/fr/main.po

Lors de mises à jour du plugin, pour fusionner les nouvelles chaînes dans le plugin avec celles déjà traduites :

  xgettext -L PHP --keyword=__ *.php
  mv -f messages.po messages.pot
  msgmerge -U locales/fr/main.po messages.pot

Mise à jour, 1er janvier 2007, 09h42 : Il semble également exister le plugin langOmatic de Tigroux pour se simplifier la tâche de traduction... Je ne l'ai pas testé toutefois.

Mise à jour, 3 février 2008, 10h06 : Il y avait une coquille qui s'était glissée dans l'appel à msginit. L'article est maintenant corrigé. Merci à Osku de me l'avoir signalé.

Migration vers DC2, les étapes

ȷulmud — Sat, 30 Dec 2006 13:50:00 +0000

Note : ce billet détaillant les étapes qui m'attendent pour migrer mes blogs de DotClear 1.2.x vers DotClear2 est hautement spécifique à ma situation. N'espérez pas pouvoir vous en inspirer pour votre propre migration... Si malgré tout vous essayez de vous inspirer de ces quelques notes, ne comptez pas sur moi pour vous dépatouiller lorsque tout aura foiré (car cela va foirer).

Dans DotClear 1.2.x (pour la migration du multicat en tags) :

Créer et remplir la table DC_PREFIX.post_cat_tmp comme suit :

CREATE TABLE `DC_PREFIX.post_cat_tmp` (`post_id` INT(11) not null,  `cat_id` INT(11) not null, `cat_libelle` VARCHAR(255) not null);
ALTER TABLE `DC_PREFIX.post_cat_tmp` ADD PRIMARY KEY (`post_id`, `cat_id`);
ALTER TABLE `DC_PREFIX.post_cat_tmp` ADD INDEX (`cat_id`, `post_id`);
INSERT INTO `DC_PREFIX.post_cat_tmp` (SELECT DC_PREFIX.post_cat.post_id, DC_PREFIX.post_cat.cat_id, DC_PREFIX.categorie.cat_libelle FROM DC_PREFIX.post_cat INNER JOIN DC_PREFIX.categorie ON DC_PREFIX.post_cat.cat_id = DC_PREFIX.categorie.cat_id);

Adapter le plugin flatExport pour qu'il tienne compte de la table post_cat_tmp (fichier index.php) :

    $dbx->exportTable(DB_PREFIX.'post_cat_tmp');

Exporter le blog avec le plugin flatExport.

Dans DotClear2 :

Installer les plugins officiels dayMode, commentsWikibar et packager
Installer les trois "thèmes inutiles"
Installer mes plugins Photoblog2 et jmuTemplate
Activer l'option MultiView et créer les fichiers PHP d'accès aux blogs
Créer les blogs et les paramétrer :
- Lecture de l'URL : PATH_INFO
- Fuseau horaire
- Format de date : %A %e %B %Y
Adapter le fichier class.dc.import.php du plugin importExport pour importer post_cat_tmp :

(fonction prepareDC12line) :
   case 'post_cat_tmp':
     $line->substitute('cat_libelle', 'meta_id');
     $line->drop('cat_id');
     $line->__name = 'meta';
     $line->blog_id = 'default';
     $line->meta_type = 'tag';
     break;

Importer le contenu des blogs
Déplacer le contenu des dossiers images dans public/blog_id pour chaque blog
Modifier tous les billets pour tenir compte du nouveau chemin pour les images :

 update dc2_post
 set post_content = INSERT(post_content, locate('blog.dir/public/', post_content), length('blog.dir/public/'), 'dotclear2/public/blog/')
 set post_content_xhtml = INSERT(post_content_xhtml, locate('blog.dir/public/', post_content), length('blog.dir/public/'), 'dotclear2/public/blog/')
 where post_content_xhtml like '%/images/%'
   and blog_id = 'blog';

Supprimer les anciennes vignettes des dossiers images

Finalement, après avoir vérifié que tout fonctionne :

Installer un jeu de rewrite pour rediriger les anciennes URLs vers les nouvelles.

Et ne pas oublier de compulser compulsivement les dcTips() de Kozlika pour vérifier que l'on n'a rien oublié lors de la migration...

(PS: Un grand merci à Sieur Pep pour son aide concernant l'export du multicat. Et un autre très grand merci à toute la DC.Team() pour ce bel outil.)

DotClear, l'indexation et les robots(.txt)

ȷulmud — Wed, 11 Jan 2006 22:49:00 +0000

Il y a quelques mois, je m'étais posé la question de savoir quel contenu de mon blog je souhaitais voir être indexé par les moteurs de recherches. Après réflexion, je me suis dit qu'il ne fallait indexer que les articles et les pages connexes afin d'offrir la meilleure qualité de résultats aux utilisateurs des moteurs de recherche. En fait, il faut surtout chercher à exclure toute page contenant plus d'un billet, ceci afin d'éviter que le contenu de la page soit « pollué » par quantité de mots n'ayant aucun rapport avec le sujet qu'essaie de faire passer l'article.

Mon postulat de base pour arriver à cette conclusion était le suivant : l'élément de base d'information de ce blog est un article dans son entierté. Par conséquent, tout le reste de ce monologue n'a aucun sens pour des blogs de type feuilleton ou des blogs ayant l'habitude de parler de beaucoup de choses différentes dans un seul et même article.

Le but est donc d'empêcher aux robots des moteurs de recherche d'indexer le contenu des pages d'archives, tout en les laissant sotcker tout ce qu'ils souhaitent sur les pages contenant un billet seul. Bien entendu, il faut malgré tout laisser l'autorisation à ces robots de parcourir les pages d'archives, afin qu'ils puissent trouver les pages des billets... La solution à cette problématique porte le doux nom de « balise meta robots. » C'est une balise HTML qui vient se mettre dans l'entête de la page web (section <head>) et elle doit contenir une combinaison des mots clefs INDEX, NOINDEX, FOLLOW et NOFOLLOW. Voici la signification de chacun de ces mots clefs :

INDEX: indique que le moteur de recherche peut indexer la page courante ;
NOINDEX: demande au moteur de recherche de ne pas indexer la page courante ;
FOLLOW: indique que le moteur de recherche peut suivre tous les liens de la page courante ;
NOFOLLOW: demande au moteur de recherche de ne suivre aucun lien de la page courante.

Pour atteindre le but que je souhaite, il faut donc mettre la balise suivante sur les pages contenant un seul article :

<meta name="robots" content="index,follow" />

et cette balise-ci sur toutes les autres pages :

<meta name="robots" content="noindex,follow" />

Dans DotClear, cela se fait très facilement en mettant la ligne suivante dans la partie <head> du fichier template.php du thème :

<meta name="robots" content="<?php 
 	if ($mode != 'related' && $mode != 'post') { 
 		echo 'noindex,follow';
 	} else { 
 		echo 'index,follow'; 
 	} ?>" />

Et voilà, c'est tout ce qu'il y a à faire. Et est-ce que ça marche ? Je crois : depuis que j'ai mis cela en place sur mes blogs, je ne tombe plus sur mes pages d'archives lors de recherche et les billets sont, eux, toujours trouvables facilement.

Lorsque j'ai proposé cette solution sur le forum de DotClear (en réponse à cette question), on s'est interrogé sur la faisabilité de ces mêmes restrictions au moyen d'un fichier robots.txt, le standard d'exclusion des robots sur le web. Mon sentiment est que cela n'est pas faisable. Il y a en effet deux limitations dans ce standard qui rendent cela fort difficile :

on ne peut pas autoriser explicitement le parcours de certaines pages ;
les préfixes utilisés sont inclusifs.^[1]

Du coup, il devient impossible d'interdire aux robots de parcourir les pages d'archives mensuelles, mais d'autoriser l'accès aux pages des billets. Il suffit de comparer ces deux URLs pour s'en rendre compte :

http://www.example.com/index.php/2005/04/01/1-premier-billet (adresse d'un billet) ;
http://www.example.com/index.php/2005/04 (page d'archive de tous les billets du mois d'avril 2005).

Si on pouvait explicitement autoriser certaines pages avec des règles Allow (en indiquant que l'on souhaite une priorité plus importante pour ces règles Allow), on pourrait imaginer générer automatiquement le fichier robots.txt lors de la mise en ligne d'un nouveau billet. Le fichier contiendrait alors la liste de tous les billets publiés sur des lignes de type Allow et la liste de toutes les pages d'archives sur des lignes de type Disallow. Il ne semble donc pas y avoir de solution dans ce cas-là...

De plus, il y a encore un effet de bord qui peut se produire : le standard robots.txt ne permet que d'interdire totalement l'accès d'une page aux gentils robots.^[2] Ainsi, en interdisant les pages d'archives, les robots auraient alors certainement beaucoup de peine pour trouver l'intégralité du contenu sur le site... Bin oui, la navigation sur un blog se fait quand même massivement à travers des pages d'archive (en considérant qu'une page d'archive est toute page contenant plus d'un billet, donc y compris la page d'accueil).

Conclusion : la mise en place d'une balise meta robots est très facile et remplit son rôle à merveille... J'ai toutefois un regret : il n'y a pas de moyen d'interdire aux robots d'indexer certains blocs de la page. Chez moi, il est par exemple inutile que les robots indexent la citation aléatoire affichée sur chaque page, puisque cette citation n'apporte aucune information utile.^[3]

Notes

[1] Ce qui signifie qu'une règle Disallow: /bob interdira l'accès au dossier /bob/, mais également à l'image nommée bobetlachoseverte.jpg.

[2] Je précise « gentils, » car les robots n'ont absolument aucune obligation de respecter ce standard. Les robots à spam, qui sont continuellement à la recherche de nouvelles adresses email, n'essaient même pas de récupérer ce fichier par exemple.

[3] Oui, je sais, vouloir trouver de l'information utile ici est un paradoxe...

PHP et les dates au format RFC822

ȷulmud — Sun, 08 Jan 2006 00:58:00 +0000

Attention, si vous travaillez avec des dates respectant la norme RFC822 (utilisée par exemple pour indiquer la date de publication d'un billet dans les flux RSS 2.0) et la fonction strtotime de PHP, vous allez au devant de jolies déconvenues : deux conversions successives de la même date ne donneront pas forcément le même résultat. Avouez que cela peut être franchement embêtant...

Suite à une mise à jour de mon aggrégateur en ligne, il y a quelques-uns des fils auxquels je suis abonné qui sont marqués comme mis à jour lors de chaque rafraîchissement de l'aggrégateur. Et cela même si le flux rss n'a pas été le moins du monde modifié depuis la fois précédente !

Avec l'aide d'un développeur de gregarius, nous avons finalement réussi à trouver l'origine du problème : les fils en question sont des flux au format RSS 2.0. Or, la spécification RSS 2.0 dit que la date d'un billet (champ PubDate) doit être formatée conformément à la norme RFC822. D'après cette norme, il n'est pas obligatoire d'indiquer le nombre de secondes dans la date. Résultat, certains fils écrivent la date comme suit : « Wed, 04 Jan 2006 19:37 +0200 »^[1]. Mais bon, tout le monde le sait, dans le monde informatique il est plus facile de travailler avec des dates numériques qu'écrites en anglais. L'idée de base est donc d'utiliser la fonction strtotime de PHP pour convertir cette date en un timestamp...

Et c'est là que le bât blesse. Si les secondes ne sont pas spécifiées dans la date, PHP4 semble prendre les secondes courantes pour compléter. Résultat : deux appels subséquents à cette fonction avec exactement les mêmes paramètres donnent deux résultats différents. Le petit script ci-dessous met en évidence ce problème :

<?php
 $date = 'Wed, 04 Jan 2006 19:37 +0200' ;
 $time = strtotime($date);
 echo $time . ' - ' . date('Y-m-d H:i:s', $time) . "\n";
 sleep(5);
 $time = strtotime($date);
 echo $time . ' - ' . date('Y-m-d H:i:s', $time) . "\n";
 ?>

Bien entendu, on s'attend à ce que les deux affichages donnent exactement le même résultat... Eh bien non ! Il y a un écart de cinq secondes entre la première et la deuxième ligne comme on le voit ci-dessous :

1136396271 - 2006-01-04 18:37:51
1136396276 - 2006-01-04 18:37:56

Cela fait toujours plaisir de faire de l'informatique non déterministe, n'est-ce pas ? Ce comportement a été confirmé par mes tests sur PHP 4.3.10 et PHP 4.4.0, et semble avoir été corrigé dans les versions 5 de PHP.

Heureusement, j'ai trouvé un « workaround^[2] » relativement simple que l'on peut appliquer. La page de manuel de strtotime nous apprend qu'il y a un deuxième paramètre optionnel qui est utilisé comme point de départ pour calculer des dates relatives (par exemple pour connaître la date dans neuf mois). En fixant ce deuxième paramètre à une valeur connue (et toujours identique), on obtient alors à nouveau un résultat déterministe lors des appels à cette fonction. Par exemple, le script de test précédent modifié comme suit (seule différence : ajout d'un 0 comme deuxième paramètre lors des appels à strtotime) :

<?php
 $date = 'Wed, 04 Jan 2006 19:37 +0200' ;
 $time = strtotime($date, 0);
 echo $time . ' - ' . date('Y-m-d H:i:s', $time) . "\n";
 sleep(5);
 $time = strtotime($date, 0);
 echo $time . ' - ' . date('Y-m-d H:i:s', $time) . "\n";
 ?>

nous donne le résultat suivant :

1136396220 - 2006-01-04 18:37:00
1136396220 - 2006-01-04 18:37:00

qui est celui que l'on attend depuis le début. Ouf !^[3]

Bizarrement, je n'ai réussi à trouver aucune mention de ce bug lors de mes recherches pour essayer de comprendre ce qui se passait...

Notes

[1] Ce qui est tout à fait valide d'après les différentes spécifications.

[2] Quelqu'un a-t-il un bel équivalent français à me proposer pour ce terme ?

[3] Dans le cas de gregarius, ce workaround a été appliqué dans le changeset 1156.