J’avais une copie des fichiers du site, ainsi qu’un backup des dépôts svn, par contre, le trac wanewsletter ne sera pas à jour jusqu’à ce que je récupère mes données, même s’il ne manque pas grand chose. Me manque également les 2 ou 3 derniers billets publiés ici (déjà que j’en produis pas beaucoup ^^).

Désolé pour ceux qui souhaitaient télécharger hmupdater pour hordes, wanewsletter, ou wamailer. Désolé aussi pour les quelques utilisateurs du script twinpedia-hordes.

Le tout est désormais hébergé sur une part GANDI, avec l’objectif à court terme de trouver un hébergement ailleurs (14€30, c’est 14€30 de plus que ce que je payais avant vous comprenez ^^).

• Enfin MySQL 4.1 ! Enfin, mes données sont stockées dans des tables proprement déclarées comme contenant de l’utf-8, et je peux profiter de toutes les autres nouveautés qu’apporte cette version par rapport à la 4.0.
• Adieu l’antique Webalizer, bonjour Awstats.
• L’avantage quand on est sur un serveur privé, c’est qu’on peut installer à peu près ce qu’on veut (les limitations ne se trouvant qu’entre la chaise et le clavier). Je me suis donc installé les magnifiques outils que sont Subversion et Trac pour rendre public le développement de Wamailer 3.0. C’est par ici que ça se passe.
• PHP 5.1.2 à la place de PHP 5.0.5. C’est toujours ça de pris, surtout au vu des nouveautés apportées par la branche 5.1.x
• Apache 2.x à la place d’Apache 1.3.x. C’est toujours ça de pris également. La version 2 est de toute évidence plus puissante, plus rapide, toussa.

Ça doit être cassé… Bon, je reessaierai plus tard :¬)

• Via Netwizz que je découvre

Justement, il y a un petit problème avec Dotclear. Lorsqu’un blog dotclear réglé pour utiliser l’UTF-8 pingue l’URL qui va bien, il commence d’abord par envoyer une requète HTTP avec le paramètre __info et s’attend à recevoir une réponse sous forme d’XML et précisant l’encodage acceptable par le blog récepteur.

Le problème est que si le blog récepteur ignore la requète avec le paramètre __info (ou répond qu’il veut du latin1), Dotclear passe les données à envoyer dans la fonction PHP utf8_decode(), or cette fonction est destructrice. Si un caractère présent dans les données n’a pas de code assigné dans le jeu de caractère latin1, il est purement et simplement remplacé par un point d’interrogation. Il y a donc perte de données.

Dotclear n’est pas vraiment en cause, c’est le mécanisme de rétroliens qui n’a pas été pensé à la base pour tenir compte des problèmatiques d’encodage (latin1 ou pire, us-ascii, sinon rien). Néanmoins, il y a ici une perte de données et ce n’est jamais une solution acceptable.

Une solution serait donc de transformer les caractères non présents dans le jeu latin1 en en entités XML avant de passer les données dans la fonction utf8_decode(). Ce n’est pas très propre étant donné que c’est du texte brut urlencodé qui est envoyé et non du XML, c’est néanmoins cette solution qui a été retenue par la plupart des navigateurs pour gérer cette même problèmatique avec les formulaires HTML.

J’ai soumis cette suggestion sur le forum de Dotclear (sans réponse de l’équipe de développement au moment où je rédige ce billet). Au début, j’étais assez réticent quant à l’obligation pour moi d’implémenter le mécanisme du paramètre __info, mais après mùre réflexion, c’est probablement la moins mauvaise solution.

L’autre grief que j’ai à l’encontre de Dotclear est qu’il nécessite la présence du paramètre utf8=1 à la réception d’un ping, sans quoi, les données sont considérées comme du latin1 et, si le blog récepteur utilise l’UTF-8, passées dans la fonction utf8_encode() (donc affichage dégueulasse sur le blog récepteur). Là, l’alternative existe clairement et se trouve dans le protocole HTTP. Elle est d’ailleurs également indiquée dans la spécification sur les rétroliens :

POST http://www.example.com/trackback/5
Content-Type: application/x-www-form-urlencoded; charset=utf-8

title=Foo+Bar&url=http://www.bar.com/&excerpt=My+Excerpt&blog_name=Foo

Les prochaines versions semblent se tourner vers la détection de l’UTF-8 pour le traitement des données reçues, mais toujours pas de prise en compte du paramètre charset.

Pour ma part, je me restreindrai pour l’instant à ne pinguer que les blogs Dotclear en UTF-8. Pour les blogs en latin1, il me faudrait passer mes données en latin1 avant envoi, ce qui signifierait une perte de données (donc là, pareil, affichage dégueulasse sur le blog en face puisque certains caractères seront remplacés par un point d’interrogation).

Nouveau design

Évidemment, c’est le changement le plus flagrant. L’inspiration a mis du temps à me venir et le résultat n’est bien sùr pas du niveau des œuvres de Dave Shea. L’association des couleurs me semble toutefois correcte et l’ensemble agréable à l’œil. Tout commentaire ou critique est bien entendu le bienvenu :¬)

Pour les personnes utilisant Firefox ou un autre navigateur basé sur un Gecko relativement récent, si les choix de couleurs de la sélection de texte ne vous satisfont pas ou vous gènent, vous pouvez annuler ces styles avec le bloc CSS suivant dans votre feuille utilisateur userContent.css (testé avec succés) :

@-moz-document url-prefix(http://blog.webnaute.net/)
{
	*::-moz-selection { background-color: Highlight; color: HighlightText; }
}

Changement d’adresse

Autre changement d’importance, le passage du blog de l’adresse http://webnaute.net/Journal/ à http://blog.webnaute.net/. En effet, le blog suivant désormais son propre chemin au niveau du design vis à vis du reste du site, et constituant un sous-ensemble particulier du site, j’ai jugé que ce changement d’adresse s’imposait pour bien refléter cet aspect.

Bien entendu, toutes les dispositions ont été prises pour que les liens ne soient pas cassés (mise en place de redirections HTTP). J’ai fait le test avec Liferea, la redirection est bien suivie et l’adresse du fil RSS mise à jour automatiquement. N’hésitez pas à vérifier que votre propre aggrégateur, si vous en utilisez un, a fait de même.

L’erreur étant humaine, il est tout à fait possible, malgré les vérifications que j’ai faites, que des liens soient cassés. N’hésitez pas dans ce cas à me faire part de cette erreur.

Système de rétroliens

Webnaute dispose désormais de son système de rétroliens (de son appellation d’origine, Trackback, mais j’aime bien la version francisée). Je vous renvoie vers cette page du petit dotclear illustré pour des explications pratiques.

J’ai d’ailleurs un billet en réserve concernant dotclear et sa gestion des trackback, ayant dù me résoudre à certaines adaptations pour être compatible avec 98 % de la blogosphère francophone.

Pages d’erreur 404 moins obscures

Ceci ne s’applique que lors de l’appel d’une URL de la forme /YYYY/MM/DD/Billet-name/ renvoyant une erreur HTTP 404 Not Found. Le moteur du blog recherche alors les billets ayant un nom proche de celui demandé et les propose en tant que possibilités.

Ça devrait être pratique dans le cas d’une faute de frappe dans l’URL (par l’internaute ou par une personne ayant fait un lien vers un billet depuis une page externe).

Un "bug" de certains agents utilisateurs devrait être également esquivé grâce à ce système. En effet, il arrive qu’un UA, suivant une URL contenant des caractères non-ascii non urlencodés sous la forme %XX, encode la-dite URL sous une forme un peu bizzare (exemple : /Journal/2005/06/19/En_vrac_jeux_de_caract\xc3\xa8res/).

Cependant, je ne suis pas sùr du tout que les URLs contenant des caractères non-ascii soient autorisées dans les pages (X)HTML. La recommandation HTML indique que de tels URLs sont illégales, cependant, la notion d’IRI a depuis fait son apparition (Oups, mais je viens de voir que c’est méchamment récent, janvier 2005; Bobe trop en avance sur son temps ?). Bref, cela fait partie des billets en cours de réflexion.

Autres changements

Un système anti-spam de commentaires/trackback très sommaire et basé sur l’IP a été mis en place. Jusqu’à maintenant, je n’ai pas eu à me plaindre de telles pratiques à l’encontre de webnaute.net mais mieux vaut prévenir que guérir.

Pour les personnes utilisant des navigateurs gérant les liens relationnels (avec <link>), deux nouveau liens relationnels sont maintenant présents dans les pages de billet et menant aux billets précédents et suivants.

Le fil RSS a été légèrement remanié pour utiliser les modules Creative Commons et Content (contenu des billets en entier avec content:encoded). De plus, deux nouvelles URLs sont disponibles :

• http://blog.webnaute.net/RSS-1.0 en tant qu’alias de http://blog.webnaute.net/RSS
• http://blog.webnaute.net/RSS-1.1 pour le fil RSS en version 1.1.

Je constate d’ailleurs à l’instant que les deux nouveaux modules utilisés semblent spécifiques à RSS 1.0. Bon tant pis, je verrai ça plus tard…

Et en vrac : un seul cookie (+ un autre éventuel pour le style css choisi) au lieu d’une rafale (moi qui râle après les sites qui font ça, c’était un comble); favicon.ico vide à la racine pour éviter les erreurs 404 et l’envoi d’octets superflus (page d’erreur 404).

Dans les cartons

Il me reste encore quelques ajouts à faire ultérieurement :

• Mécanisme pour mettre en avant les derniers billets actifs au niveau des commentaires
• Possibilités de mise en forme pour les commentaires (syntaxe wiki, HTML ou autre). Ce n’est toujours pas fait :¬(
• L’utilitaire d’aide à la composition des billets et commentaires (pour insérer des caractères rarement utilisés/difficiles d’accés au clavier) dont je parlais il y a quelques temps
• Mécanisme pour pouvoir suivre l’ajout de commentaires sur un billet sans devoir systématiquement passer sur le site
• Pour mon admin, le module me permettant de dialoguer avec les système de trackback des autres blogs (je l’avais complètement zappé)

Voilà, j’espère que toutes ces nouveautés vous plaisent autant qu’à moi. Je tiens à remercier une nouvelle fois J.J Solari pour son aide précieuse pour les tests du design sur les navigateurs Mac ainsi que pour ses conseils, ainsi que toutes les personnes m’ayant donné leurs avis ou critiques sur ce nouveau design.

• Tapez about:config dans la barre d’adresse du navigateur puis validez
• Cherchez dans la liste l’option browser.chrome.favicons
• Double-cliquez sur la ligne de l’option en question ou clic droit sur la ligne puis sélectionnez Toggle dans le menu contextuel ou sélectionnez la ligne en question avec les touches fléchées du clavier puis tapez sur la touche entrée
• Redémarrez le navigateur

Juste un petit extrait du contenu de mes logs :

83.200.*.* - - [07/Aug/2005:16:48:03 +0200] "GET /favicon.ico HTTP/1.1" 404 6714 "-" "Mozilla/5.0 (Windows; U; Windows NT 5.1; fr-FR; rv:1.7.10) Gecko/20050717 Firefox/1.0.6"
83.200.*.* - - [07/Aug/2005:16:48:03 +0200] "GET /favicon.ico HTTP/1.1" 404 6714 "-" "Mozilla/5.0 (Windows; U; Windows NT 5.1; fr-FR; rv:1.7.10) Gecko/20050717 Firefox/1.0.6"
83.200.*.* - - [07/Aug/2005:16:48:04 +0200] "GET /favicon.ico HTTP/1.1" 404 6319 "-" "Mozilla/5.0 (Windows; U; Windows NT 5.1; fr-FR; rv:1.7.10) Gecko/20050717 Firefox/1.0.6"
83.200.*.* - - [07/Aug/2005:16:48:15 +0200] "GET /favicon.ico HTTP/1.1" 404 6714 "-" "Mozilla/5.0 (Windows; U; Windows NT 5.1; fr-FR; rv:1.7.10) Gecko/20050717 Firefox/1.0.6"

Non, non, y en a pas. Je sais, c’est dur à accepter mais c’est comme ça. Le jour où j’ajouterai une icône personnalisant ce site, je l’indiquerai proprement dans mes pages.

Ne validez pas cette pratique stupide initiée par IE et que Mozilla s’est bêtement senti obligé de suivre en laissant cette option active, mes logs et ma bande passante vous remercieront et ceux de beaucoup d’autres serveurs aussi (bon, en fait, c’est plus une question de principe que du gâchis de ressource).

Si vous avez des suggestions sur certains points, ce ne sera bien entendu pas de refus :)

Il reste encore quelques petites choses à régler, notamment le sous domaine dev.webnaute.net à remettre en place. Je devrais avoir désormais un peu plus de temps à consacrer au site, donc ne lachez pas le fil ;-)

J’utilise la fonction utf8_encode(), associée à quelques str_replace() par derrière pour traiter les caractères qui ne sont pas dans le jeu ISO-8859-1.

Si quelqu’un comprend le pourquoi du comment, qu’il n’hésite pas à se manifester :/

1. Modification des URI d’appel des billets. Le fait d’indiquer l’identifiant du billet dans l’URI ne servait à rien et n’était pas significatif. J’étais récalcitrant au début pour utiliser un sujet simplifié dans l’URI mais je pense que c’est un meilleur choix que d’utiliser l’heure de publication. L’intervention de Ganf sur ce sujet sur le forum de phpapps.org m’a en effet amené à réfléchir sur ce point et à finalement prendre une décision.
   Évidemment, les redirections permanentes nécessaires ont été mises en place ;-)
2. Apparition de fils RSS pour chaque catégorie. Un gadget plus qu’autre chose mais ça pourra toujours servir.
3. Le nombre d’items dans les fils RSS est passé de dix à quinze.
4. Quelques modifications dans le code lui-même, surtout pour alléger la gestion des URI (mon fichier .htaccess commençait à devenir bordélique).

D’autres améliorations et ajouts sont au programme et ne tarderont pas. Et ne vous inquiétez pas, j’ai aussi quelques sujets à traiter dans ma besace :)

Pour finir, je m’y suis pris autrement. Je lance à l’aide de la fonction fsockopen() de PHP une requète à destination du site indiqué dans le formulaire et je récupère la valeur donnée par l’en-tête Content-Language que me renvoie le serveur. Dans le cas où cet en-tête n’est pas fourni par le serveur, je m’attaque au contenu même qui m’est renvoyé en cherchant les attributs xml:lang et/ou lang sur les éléments html ou body puis le meta Content-Language.

Encore une preuve des bienfaits des pages codées proprement et des bons en-têtes envoyés par le serveur :)

PS : Une copie de la fonction que j’ai faite est disponible ici pour les curieux.

Du fait de la grande jeunesse de mon journal, j’avoue avoir été agréablement surpris d’apprendre que Webnaute faisait partie des blogs/journaux syndiqués, les résumés de mes articles se retrouvant au milieu de ceux du Standblog, de Cybercodeur et d’autres bien connus. Je tâcherai donc d’être à la hauteur :) (Heureusement, je crois constater que le système utilisé s’appuie sur la balise <dc:subject> pour trier les articles selon les catégories, ce qui me permettrait de continuer à raconter mes conneries dans la section Bric à brac).

P.S : Je m’interroge sur l’origine du nom de domaine "ceforweb.org", si l’auteur passe dans le coin :¬)

Je parle en l’occurence du système pour commenter les billets. Comment faire pour que le contenu ajouté soit valide et un minimum sémantique ? Quelle syntaxe adopter ?

Les bbcode ?

Peut être un tantinet complexe pour l’utilisateur lambda, mais tout dépend du public auquel on s’adresse, ici, je pars du principe que j’ai à faire à des personnes qui ont quelques connaissances dans la conception de site, fréquentent sùrement quelques forums de type phpbb-like et connaissent donc un peu la syntaxe bbcode ou au moins le balisage HTML. Mais justement, bbcode et HTML sont semblables, mis à part les crochets pour l’un et les chevrons pour l’autre, donc autant utiliser directement des balises HTML.

Le HTML ?

On retrouve là le même problème que pour les bbcode.

Syntaxe à la wiki ?

C’est peut être la solution. Toutefois, du peu que j’en ai vu, je n’ai pas été convaincu. Cette syntaxe me semble peu flexible dans le sens où je veux que les visiteurs aient autant que possible les mêmes possibilités qu’avec le balisage HTML.

Bref, je suis toujours sur la case départ et ne sais pas quelle solution adopter ou quelle solution concevoir. Mais peut être est-ce moi qui en demande trop aussi ?