Wordpress 2.2 et les problèmes rencontrés sur quelbazar

Annoncé ici avec grand fracas (et ça m’a d’ailleurs valu des mails de menace…), Quelbazar est passé il y a quelques temps sur wordpress.

En tout et pour tout, trois problèmes subsistent :

1. Comment insérer, en bas d’un billet, des “notes de bas de pages” telles qu’on peut les voir, par exemple, sur ce billet, qui a été importé de Dotclear. Je sais que c’est possible. Faut que je trouve lise la doc.
2. Pourquoi mes billets “planifiés” ne sont-ils pas publiés ?
3. Pourquoi n’arrive-je pas à envoyer des trackbacks, ou rétroliens si il y a par ici des défenseurs susceptibles du français ? (En fait, on verra plus bas que c’est lié au point 2…)

Pour le point 1, on verra plus tard

On va parler ici du point 2, donc du 3 aussi :

Wordpress 2.2 inclut son propre mécanisme de “cron” (en fait depuis la version 2.1). Cette fonctionnalité est utilisée, entres autres, pour planifier des publications de billets dans le futur. Et chez moi, même avec une clean install de WP 2.2, cela ne fonctionne pas : Si je planifie un billet, il apparait bien comme “billet planifié” sur le tableau de bord, mais quand l’échéance arrive, le compte à rebours commence à compter à l’envers, mais rien n’est publié. Moche.

Plusieurs personnes ont le même souci. Mais je n’ai trouvé aucune solution réelle.

On en parlait cependant par ici, où un workaroud est proposé. Il fonctionne chez moi, mais j’ai voulu chercher plus loin.

J’ai donc commencé à éditer le fichier wp-cron.php pour commenter les 2 lignes suivantes :

//if ( $_GET['check'] != wp_hash('187425') )

//    exit;

Ce qui désactive un check de vérification de qui appelle le script. Ca facilite les tests.

Ca m’a permis de vérifier qu’en appelant directement ce script, la publication de mes billets planifiés fonctionne.

Cherchons donc qui appelle wp-cron.php : C’est la fonction spawn-cron qu’on trouve dans wp-includes/cron.php.

Pour tenter de tracer ce qu’il se passe, j’ai ajouté dans spawn-cron, à la fin, le code suivant :

// DEBUG
 $debugfile = fopen ("debugfile.txt", 'w');

fwrite ($debugfile, "cron_url=".$cron_url."rn");
 fwrite ($debugfile, "parts[scheme]=".$parts['scheme']."rn");
 fwrite ($debugfile, "parts[host]=".$parts['host']."rn");
 fwrite ($debugfile, "_SERVER[SERVER_PORT]=".$_SERVER['SERVER_PORT']."rn");
 fwrite ($debugfile, "errno=".$errno."rn");
 fwrite ($debugfile, "errstr=".$errstr."rn");
 fwrite ($debugfile, "parts[path]=".$parts['path']."rn");
 fwrite ($debugfile, "_SERVER[HTTP_HOST]=".$_SERVER['HTTP_HOST']."rnrn");
 fwrite ($debugfile, "argyle=".$argyle."rn");
 fwrite ($debugfile, "HTTP GET="."GET {$parts['path']}?check=" . wp_hash('187425') . " HTTP/1.0rn"
 . "Host: {$_SERVER['HTTP_HOST']}rnrn");

Après rechargement, par exemple, du tableau de bord, on a dans debugfile.txt :

cron_url=http://blog.quelbazar.net/wp-cron.php
 parts[scheme]=http
 parts[host]=blog.quelbazar.net
 _SERVER[SERVER_PORT]=80
 errno=110
 errstr=Connection timed out
 parts[path]=/wp-cron.php
 _SERVER[HTTP_HOST]=blog.quelbazar.net

argyle=
 HTTP GET=GET /wp-cron.php?check=6c85c0a3e6dd3003fa38c446d36548ce HTTP/1.0
 Host: blog.quelbazar.net

On voit vite que $argyle est vide, et que $errno et $errstr nous renvoie “Connection timed out”.

J’ai essayé d’augmenter la valeur de timeout de la fonction fsockopen : Le résultat, c’est que les pages du blog mettent plus de temps à charger, mais j’ai toujours le même message d’erreur.

Donc je me suis mis à douter de mon hébergeur. Avec raison : Il bloque les appels avec fsockopen des URLs hébergées chez lui-même.

Au moins, j’ai trouvé pourquoi… : Pas de la faute à Wordpress. Et j’attends des news de mon hébergeur phpnet.

Pour le moment, j’ai appliqué le workaround trouvé ici.

• 10 raisons pour migrer de Dotclear2 à Wordpress
• Une attaque de spam propre en ordre sur QuelBazar
• Mine de rien… c’est du boulot…
• Les 10 pages les plus fréquentées de Quelbazar
• La beta7 de Dotclear2 est sortie. Un vendredi 13.

Tags: C4, Différé, Dotclear, Dotclear2, phpnet, Planifié, Trackback, Wordpress