Ce mercredi 16 mars de l’an de grâces 2011, vers 11h, ma femme et moi avons fini l’implémentation que nous préparions depuis 9 mois :

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17

public class HuitiemeMerveilleDuMonde implements Bebe {
 
    @Override
    public String getNom() { return "Courtine"; }
 
    @Override
    public String getPrenom() { return "Aliénor"; }
 
    @Override
    public Sexe getSexe() { return Sexe.FILLE; }
 
    @Override
    public double getTaille() { return 48.0d; }
 
    @Override
    public double getPoids() { return 3.060d; }
}

Selon la formule consacrée, « la mère et l’enfant se portent bien », et se remettent tranquillement de leurs émotions à la maternité. Pour sa part, le père est aux anges, et a hâte de retrouver tout le monde demain !

Notre petite Aliénor en image :

Aliénor Courtine

Seule petite ombre au tableau : l’implémentation dans sa version 1.0 va sans doute souffrir de bugs à corriger, tels que des appels intempestifs de « réveillerPapaEnPleineNuit()« , « refuserDeDormir()« , etc.

Le temps de pouponner bébé corriger ces quelques bugs, je risque d’être à nouveau un peu distant de ce blog dans les prochaines semaines.

1
2
3
4
5
6
7
8
9
10
11
12

public interface Bebe {
 
  public String getNom();
 
  public String getPrenom();
 
  public Sexe getSexe();
 
  public double getTaille();
 
  public double getPoids();
}

A défaut d’avoir le temps d’écrire un article de fond, voici donc en vrac une revue rapide de ma veille de ce mois de janvier…

LibreOffice vs OpenOffice

C’est finalement LibreOffice qui a sorti le premier sa version 3.3.0, ce à quoi Oracle a répondu quelques jours plus tard avec la même version de sa suite. Après un test rapide de ces deux versions, la différence de fonctionnalités n’est pour l’instant pas flagrante. OpenOffice étant beaucoup plus agréable graphiquement, je vais donc rester sur la suite d’Oracle en attendant la suite des évènements…

Hudson vs Jenkins

Deuxième fork, encore une fois avec un produit d’Oracle, encore une fois pour des différents sur la gouvernance du projet. C’est la solution d’intégration continue Hudson qui a été forkée par sa communauté (et son fondateur, Kohsuke Kawaguchi). Comme pour OpenOffice, Oracle décide de poursuivre de son côté le développement d’Hudson, avec le soutien de Sonatype. Pour ma part, j’ai décidé de « switcher », et de suivre le projet Jenkins.

Play Framework

La version mineure 1.1.1 de Play Framework est parue ! Mais la grande évolution, c’est la version 1.2 prévue pour mars. Jusqu’à maintenant, lorsqu’on voulait ajouter une librairie à un projet Play, il fallait la mettre dans le répertoire « lib », et donc commiter celui-ci avec le reste du projet.

Habitué aux projets Maven, où les dépendances sont gérées dans un unique fichier de configuration (et donc où les binaires de ces dépendances ne sont pas mis en gestion de configuration), je n’appréciait pas ce fonctionnement de Play, malgré ses autres qualités.

Or, avec la version 1.2 qui arrive, on va avoir un fonctionnement similaire à celui de Maven, où on va pouvoir définir des dépôts et lister les dépendances dans un fichier de configuration.

Paris JUG

Lundi 28 février aura lieu à la cité universitaire le 3ème anniversaire du Paris JUG : au programme, « siffler en travaillant » ! Et tant qu’on est dans l’annonce d’évènements Java, les 26 et 27 mai auront lieu au Grand Rex le « What’s Next Paris?« .

Software craftmanship

Le « software craftmanship », c’est le concept à la mode (avec les TDD, Scrum, et autres DevOps). Sur ce sujet, je tenais à signaler le dernier billet de Nicolas Martignole, auquel j’adhère totalement.

Et je profite de ces voeux pour expliquer le titre de ce post : depuis maintenant plus de 15 jours (et certainement pendant au moins tout le mois de Janvier), je vais délaisse ce blog. En effet, nous avons profité de cette fin d’année 2010 pour déménager dans un appartement un peu plus grand mais un peu plus loin de Paris (heureusement encore accessible par les transports en commun). Outre l’attente de notre nouvelle Freebox qui oblige à suivre l’actualité par Galaxy-S interposé, la priorité des soirées est consacrée au déballage des cartons et à l’aménagement…

Afin de bien commencer l’année, voici deux bons « bêtisiers » de fin d’année trouvés récemment :

• 55 citations informatiques classiques
• Les perles de Xebia

Perles complémentaires

Comme j’aime bien le concept du bêtisier, voici un petit complément d’extraits de code que j’ai eu l’occasion de lire cette année.
Un tout nouveau design pattern, le « Don’t miss this exception ! » :

1
2
3
4
5
6
7

try {
    // code...
} catch (SQLException e) {
    e.printStackTrace();
    LOGGER.error("Exception :" + e.getMessage());
    LOGGER.error("SQL Exception", e);
}

Toujours dans la gestion d’exceptions, voici le « quoi qu’il arrive, c’est pas moi mais la base de données » :

1
2
3
4
5

try {
    // code...
} catch (Exception e) {
    throw new SQLException(e.getMessage());
}

Passons maintenant à la suite de la série « réinvention de la roue carrée« , avec l’obtention de la date du jour au format français « jj/mm/aaaa » :

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18

public static String getCurrentDate() {
    Date date = new Date();
    Calendar cal = Calendar.getInstance();
    cal.setTime(date);
    int year = cal.get(Calendar.YEAR);
    int month = cal.get(Calendar.MONTH) + 1;
    int day = cal.get(Calendar.DATE);
    String yearStr = Integer.toString(year);
    String monthStr = Integer.toString(month);
    String dayStr = Integer.toString(day);
    if (monthStr.length() < 2) {
        monthStr = "0" + monthStr;
    }
    if (dayStr.length() < 2) {
        dayStr = "0" + dayStr;
    }
    return dayStr + "/" + monthStr + "/" + yearStr;
}

Je vous épargne la méthode « getCurrentHour() » de ce même projet, basée sur le même concept. De même, je ne copierai pas ici la méthode « validateDate()« , dont le but est de vérifier qu’une chaîne de caractères représente une date valide dans ce même format (elle fait 62 lignes…).

Un des deux problèmes que j\’avais a été résolu, par l’installation du plugin « WP-Syntax Editor Integration Plugin« . Avec celui-ci, plus de problème de disparition des attributs de mes morceaux de code.

Concernant, la ponctuation française, je n’ai toujours pas trouvé mon bonheur… Donc si quelqu’un connaît le nom d’un tel plugin, qu’il n’hésite pas à me le signaler.

Quelques jours après la mise en ligne de ce nouveau blog, j’ai été confronté à un nouveau problème, que je n’avais pas sur Dotclear… les spams pourriels ! Les robots sont visiblement friands de blogs WordPress. J’ai opté pour la méthode la plus simple, avec mes excuses pour le désagrément des (quelques) vrais commentateurs de ce blog : le CAPCHA. J’ai au passage encore une fois été impressionné par le fonctionnement de WordPress. Le CAPCHA s’est automatiquement intégré au site sans que j’aie besoin de modifier à la main le moindre fichier du thème ! Et depuis, je n’ai pas constaté de nouveau problème de ce type.

Mais la plus grosse mise à jour date de ce week-end : il s’agit du changement de mon serveur web !

Ces derniers jours, j’ai constaté que le blog, qui tournait sur Apache, était particulièrement lent à afficher les pages (entre 5 et 10 secondes), ce qui était inacceptable, vu sa charge quasiment nulle. J’ai donc cherché l’origine de ce problème :

• les ressources (processeur et mémoire) de mon serveur, que je peux monitorer, ont immédiatement été mises hors de cause ;
• la base de données MySQL également (via un petit benchmark de requêtes…)
• le réseau également (les transferts de fichier via FTP ne posent aucun problème)
• le troisième candidat, le serveur web, a été le grand gagnant : après une relance du serveur, les performances s’améliorent nettement. Mais après quelques temps, elles se redégradent…

Le coupable étant identifié, il restait à trouver une solution. J’ai envisagé d’aller « tunner » la configuration des performances du serveur (nombre de threads, de connexions, timeout, etc.). Mais finalement, j’ai profité de ce problème pour aller voir du côté des serveurs web alternatifs, et en particulier les « serveurs légers ».

J’ai tout d’abord envisagé Lighttpd. Très facile à mettre en place : la communication avec MySQL et PHP fonctionne sans problème. Et ce test a définitivement prouvé qu’Apache était bien responsable de la lenteur générale. En changeant de serveur, je-’ai récupéré des temps d’affichage tout à fait corrects ! Le seul problème était que Lighttpd ne gère pas les fichiers .htaccess, très utilisés par WordPress (pour les « liens permanents »). Heureusement, le web abonde de littérature et une recherche rapide m’a donné la solution.

Mais quitte à tester les serveurs légers, je me suis ensuite intéressé à  Nginx, qui a plutôt bonne presse. En revanche, sur ce serveur, la communication avec PHP n’est pas inclue, et il faut passer par des services CGI (php-cgi, php5-cgi, une sur-couche spawn-fcgi qui est utilisée par Lighhtpd, ou php-fpm). Pour la mise en place, je me suis documenté ici et là.

J’ai dans un premier temps mis de côté php-fpm, plus difficile à installer (nécessitant une recompilation de PHP). En comparant l’utilisation directe de php-cgi et celle de spawn-fcgi, j’ai constaté que la deuxième solution était plus rapide. J’ai donc finalement décidé de garder le couple Nginx + spawn-fcgi. Il ne restait donc plus qu’à s’assurer du lancement correct des services au démarrage de la machine, comme décrit dans ce troisième tutoriel.

Au début, tout a très bien fonctionné. Mais au bout d’un certain temps (au maximum quelques heures !), je me suis retrouvé avec une erreur 502 de Nginx, « Mauvaise passerelle ». L’origine de cette erreur, c’est le processus php5-cgi (qui assure le traitement des requêtes PHP), qui s’arrête régulièrement pour une raison inconnue. Apparemment, je ne suis pas le seul à rencontrer ce problème. Pour ceux qui ont le même souci, je l’ai résolu de la manière suivante :

• en limitant le nombre de requêtes que traite chaque processus php5-cgi, via la variable d’environnement PHP_FCGI_MAX_REQUESTS
• en lançant un pool de ces processus au lieu d’un seul, grâce au paramètre « -C » de spawn-fcgi

Les instructions de lancement deviennent ainsi :

1
2
3
4
5
6
7
8
9
10

PHP_FCGI_MAX_REQUESTS=1000
PHP_FCGI_CHILDREN=2
COMMAND=/usr/bin/spawn-fcgi
ADDRESS=127.0.0.1
PORT=9898
USER=www-data
GROUP=www-data
PHPCGI=/usr/bin/php5-cgi
PIDFILE=/var/run/spawncgi.pid
$COMMAND -a $ADDRESS -p $PORT -u $USER -g $GROUP -f $PHPCGI -P $PIDFILE -C $PHP_FCGI_CHILDREN

Avec cette modification du script de lancement, le problème d’arrêt intempestif des processus php5-cgi semble avoir été résolu : le pool de processus tourne maintenant depuis plus de 24h sans s’être arrêté. Il ne reste donc plus qu’à reporter ces commandes dans un script de lancement (dans « /etc/init.d/« ), et automatiser le démarrage de celui-ci.

Le couple « Nginx + spawn-fcgi » étant satisfaisant, avec des temps de réponse beaucoup plus corrects, je garde (au moins temporairement) cette solution. Il ne reste maintenant plus qu’à voir si elle est stable sur la durée…

Aujourd’hui, j’ai l’occasion de vous présenter un cas d’utilisation plus personnel, où ces mêmes outils m’ont permis d’éviter un travail bien ennuyeux. Je vous ai présenté récemment la procédure de migration que j’ai utilisée pour passer de Dotclear à WordPress.

Cette procédure n’a pas été au bout des choses et il me restait un certain nombre de petits ajustements à effectuer :

• Migrer les liens
• Migrer les réponses aux commentaires du plugin Comback 2.0
• Supprimer les acronymes de mes anciens billets (ils sont maintenant automatiquement ajoutés par le plugin Acronyms)
• Corriger les liens internes entre les anciens billets : ils ne sont plus valables

Mis bout à bout, ces différentes actions sur 65 billets constituent un travail non négligeable… et d’un intérêt proche de 0. C’est à ce moment que Talend intervient, car il m’a permis d’automatiser ces différentes tâches.

S’agissant d’un cas d’étude simple, je pense qu’il peut constituer un bon tutoriel sur un cas d’utilisation réel de cet outil. Voici donc la première partie de ce tutoriel.

Installer les bases de données de test

Pour effectuer cette migration, je vais avoir besoin de deux bases de données : celle de Dotclear et celle de WordPress. J’installe donc EasyPHP (par commodité), ainsi que les deux applications en question.

Afin de disposer de véritables données, j’importe dans leurs bases respectives :

• les données de mon ancien blog Dotclear.
• les données migrées de mon nouveau blog WordPress.

Je n’entre pas dans les détails de ces manipulations élémentaires, la documentation en ligne que l’on peut trouver étant déjà très abondante (par exemple sur l’import/export des bases de données MySQL).

Installer Talend Open Studio

Les bases de données étant créées et remplies de données de test, nous pouvons passer aux choses sérieuses. Mais avant toute chose, il va falloir installer TOS (ou Talend MDM CE, qui inclut TOS). Cette étape ne devrait poser aucun problème dès lors qu’on a un JDK en version 6 : il suffit de décompresser l’archive.

En cas de problème, un tutoriel récent décrit la procédure pas à pas de l’installation de Talend MDM.

Mise en place des métadonnées

Première bonne pratique : je configure une et une unique fois l’accès à mes bases de données. Dans TOS, cela se fait en utilisant le menu « Métadonnées » de l’arbre de navigation, à gauche :

Création d'une métadonnée avec Talend

Nous renseignons ensuite les informations sur la connexion que nous créons. Ces zones sont purement informatives, mais c’est une « bonne pratique » de les remplir. Elles permettent par la suite à l’outil de générer une documentation automatique des jobs :

Saisie des informations sur la connexion WordPress

Puis nous saisissons les identifiants techniques de cette connexion (adresse, port, login, mot de passe, etc.) :

Saisie des identifiants techniques de connexion à la base de données de WordPress

Avant de terminer cette étape, le bouton « Vérifier » nous assure que tout est bon : la base de données tourne, est accessible, et nous n’avons pas fait d’erreur dans la saisie des différents identifiants.

J’attire maintenant votre attention sur le boutons « Exporter comme contexte ». Cette étape peut être différée mais il n’y a pas de raison particulière de la retarder. Comme son nom l’indique, elle permet de remplacer les paramètres de connexion « en dur » par des variables.

Ainsi, au niveau du code Java généré, on aura les remplacements :

• « localhost » devient context.BlogWP_Server
• « 3306″ devient context.BlogWP_Port
• etc.

Cette opération se fait au détriment de toutes les conventions de nommage Java (de ce point de vue, mieux vaut de toute façon ne pas regarder de trop près le code généré…) mais apporte un certain nombre d’avantages :

• elle permet de travailler avec plusieurs bases de données distinctes utilisant le même schéma de données. Pour cela, il faut rajouter dans le groupe de contextes « BlogWP » un nouveau contexte (qui peut par exemple correspondre aux identifiants de connexion à la base de validation des traitement, voire à la base de données de production)
• lors du déploiement effectif du job, après son « export batch », passer par un contexte permet d’externaliser les paramètres de configuration. Ils ne sont plus embarqués dans l’archive JAR du traitement, mais placés dans des fichiers « properties », à l’extérieur. Cela permet donc de modifier les paramètres du traitement avant son lancement sans avoir à repasser par le studio de développement, une re-compilation, un nouvel export, etc.

Passons maintenant à la partie la plus intéressante : toutes ces opérations que nous venons de faire vont nous permettre d’extraire automatiquement de la base de données les schémas des différentes tables qui la composent, et ensuite de les utiliser directement dans l’éditeur visuel, sans avoir à trop nous en préoccuper. Pour cela, il faut sélectionner la métadonnée nouvellement créée et demander la récupération de son schéma :

Récupération du schéma de la base de données de WordPress

Je passe rapidement sur les 3 écrans qui suivent. Les options par défaut conviennent généralement. Ceux qui veulent rentrer dans le détail (du troisième écran principalement) pourront véritablement affiner le mapping entre les données de la base et les classes Java, mais cela s’adresse plutôt à des utilisateurs expérimentés, et n’est pas l’objet de cet article).

Voici donc directement le résultat :

Schéma de la base de données WordPress

Nous allons vérifier via un job élémentaire qu’on arrive bien à récupérer les données de la base. Dans l’onglet « Jobs » cette fois, nous allons donc créer un nouveau traitement :

Création du job de test

Construisons maintenant notre job :

• on ajoute tout d’abord le groupe de contextes « BlogWP » au job, afin que les paramètres de connexion soient accessibles (mais si on oublie cette étape, TOS la proposera de lui-même) ;
• on place le composant tLogRow, qu’on trouve dans la palette de droite (rubrique « Logs & Erreurs » ;
• pour le tMySQLInput, nous allons voir l’intérêt d’avoir commencé par créer les métadonnées. Nous n’allons donc pas le chercher dans la palette. On prend la table « wp_links » des métadonnées et on la fait glisser jusqu’à la fenêtre du job. Talend donne alors le choix entre une série de composants, dont le tMysqlInput sélectionné par défaut. On valide, et on peut alors se rendre compte que tout a été pré-rempli (paramètres de connexion, nom de la table, requête à exécuter, schéma du composant) ;
• il ne nous reste donc plus qu’à créer un lien « Principal » du tMysqlInput au tLogRow (clic droit sur le tMysqlInput > ligne > Principal, ou clic droit « glissé » du tMysqlInput jusqu’au tLogRow) ;

Le job est techniquement finalisé. A ce stade :

• dans l’onglet code (en bas à gauche du job), on peut regarder à quoi ressemble le code généré, et s’assurer qu’il ne contient pas d’erreur de compilation (syntaxe, etc.)
• on peut ajouter la documentation des différents composants, et ajouter quelques retouches cosmétiques pour permettre une meilleure lisibilité (nom affiché pour les composants, etc.).

Il ne nous reste plus qu’à tester le bon fonctionnement de l’ensemble. Dans l’onglet « Exécuter », on vérifie une dernière fois les paramètres du contexte (à gauche) et on lance l’exécution :

Exécution du job Talend de test

Ce succès clos cette première partie du tutoriel. On procède de même avec la base de données Dotclear et nous sommes prêts à entrer dans le vif du sujet : la mise à jour et la correction des données !

En effet, malgré ces défauts, il m’aura suffit de 2 jours pour être séduit par WordPress 3.0 :

L’interface d’administration

L’interface d’administration de WordPress 3.0 a été complètement revue, avec de l’AJAX dans tous les coins, qui la rendent vraiment agréable à utiliser. Ce n’est pas du tout ce qui a été déterminant dans mon choix, mais c’est un point non négligeable que d’utiliser une interface sympathique.

Les thèmes disponibles

Pour rester dans le domaine du visuel, une des grosses forces de WordPress par rapport à Dotclear, c’est la taille de sa communauté, et le nombre de thèmes qu’elle met à disposition. Il n’y a absolument aucune comparaison possible : là où j’avais du mal à trouver un thème qui me convienne sur Dotclear, j’ai au contraire du mal à me décider sur WordPress.

De plus, les thèmes disponibles sont bien plus aboutis (comme Mystique, que j’utilise, et qui est très dynamiques en JavaScript/AJAX, comme vous pouvez vous en rendre compte (merci jQuery).

Une chose qui n’existe pas sous Dotclear (du moins sans un bon nombre de bidouilles), un thème peut en cacher un autre. En administration, il est possible de très largement personnaliser ses thèmes lorsque ceux-ci le permettent : nombre et position des barres latérales, palette de couleurs, contenu, navigation, CSS, etc. Voici par exemple à quoi ressemble le premier des 7 onglets d’options du thème « Mystique » :

Administration du thème Mystique

Sur ce point, le panel des possibilités de WordPress m’a vraiment épaté. Je ne pensais pas que les possibilités de personnalisation graphique étaient poussées à ce point, et surtout pas avec une telle facilité.

Les fonctionnalités disponibles

Nativement, WordPress dispose de plus de fonctionnalités que Dotclear :

• sauvegarde de plusieurs versions d’un article, de manière automatique (sauvegarde automatique toutes les N secondes), avec la possibilité de comparer différentes versions et d’en restaurer une ancienne
• hiérarchie des commentaires (en donnant la possibilité de « répondre » à une personne). Sous Dotclear, j’avais du utiliser le plugin ComBack2 pour obtenir quelque chose d’approchant
• etc.

Mais ce qui est réellement impressionnant, au delà des fonctionnalités natives, c’est encore une fois la taille de la communauté. Le système de recherche/installation des extensions est très bien fait, et quoi qu’on veuille faire,  »il y a une extension pour ça ».

• gérer l’affichage des codes sources
• ajouter automatiquement les définitions des acronymes présents dans les articles
• etc.

Au passage, je me permets un petit zoom sur une différence de fonctionnement qui à mon avis, est à l’avantage de WordPress.

Dans Dotclear, le contenu des articles est géré par deux champ de la table des articles : post_content et post_content_xhtml. L’article tel qu’on le saisit est enregistré dans la première. Les plugins que l’on installe peuvent enregistrer des « filtres », qui au moment de l’enregistrement, vont enrichir le contenu (formatage d’un code source par exemple), et enregistrer le résultat dans post_content_xhtml. Au moment de l’affichage, c’est le contenu de cette deuxième table qui est utilisé. En revanche, si je ne me trompe pas (mais un spécialiste du développement sous Dotclear me contredira peut-être), un plugin ne peut intervenir entre le contenu de cette table et l’affichage.

Dans WordPress, il y a un unique champ pour gérer le contenu des articles. Les plugins peuvent également enregistrer des filtres, mais ceux-ci sont appliqués dynamiquement à l’affichage de l’article et non lors de son enregistrement. C’est probablement un peu plus gourmand en traitement mais plus efficace. Prenons l’exemple du plugin d’ajout des définitions des acronymes. Le post-traitement de WordPress permet une application rétroactive à tous les billets existants lorsque le plugin est activé. Dans Dotclear, cela ne pourrait se faire qu’en ré-enregistrant chaque article après l’installation du plugin.

Des interfaces avec d’autres systèmes

WordPress étant beaucoup plus utilisé que Dotclear, il dispose d’un beaucoup plus grand nombre d’interfaces avec d’autres systèmes informatiques :

• la plupart des systèmes mobiles (iPhone, Android, etc.) disposent d’une (souvent plus d’ailleurs) application permettant d’écrire ses billets en déplacement
• des réseaux sociaux (LinkedIn, etc.) disposent d’une application dédiée à WordPress

Un éditeur énervant…

Même si WordPress m’a impressionné par bien des aspects, tout n’est pas parfait. Et un des gros reproches que je peux lui faire après ces deux journées de tests, c’est son éditeur. Dès qu’on utilise l’éditeur visuel (pourtant agréable), les morceaux de code que l’on insère directement en HTML disparaissent :

• les balises « line », « escaped », etc. du plugin de coloration syntaxique du code
• les espaces insécables avant les doubles ponctuations, auxquels je tiens pourtant beaucoup

Conclusion

Malgré ces quelques défauts, j’ai tout de même trouvé suffisamment d’avantages à WordPress pour effectuer la migration. Il détrône donc Dotclear à l’adresse http://blog.courtine.org/ et comme page par défaut de mon domaine.

Le blog historique sous Dotclear devient accessible à l’adresse http://dcblog.courtine.org/

Il me reste maintenant à finaliser la migration (liens, etc.), qui devrait être faite d’ici deux petites semaines… et à essayer de résoudre les quelques problèmes listés ci-dessus. Si un spécialiste de WordPress passe par ici et connait la solution, je lui saurai gré de partager cette information en commentaires.

Cependant, si je dois migrer, j’aimerais ne pas perdre tout l’historique des billets de ce blog. J’ai donc décidé en premier lieu de vérifier qu’il était possible d’importer le contenu d’un blog Dotclear.

Je ne détaille pas l’installation en local des deux moteurs sous EasyPHP en version 5.3, pour vérifier au passage les éventuelles incompatibilité (je suis devenu un peu paranoïaque depuis cet épisode) : elle ne pose aucun problèmes pour ces deux moteurs.

Premier essai

WordPress dispose d’un module d’import, mais par défaut, celui-ci n’offre pas la possibilité de migrer depuis Dotclear. Un lien sur cette page permet de parcourir la liste des plugins additionnels d’import, où on trouve sans difficulté le plugin d’import pour Dotclear.

Le système d’installation de plugins de WordPress est très intuitif, et il faut bien le reconnaître, plus agréable que celle de Dotclear. Ce plugin s’installe donc automatiquement, sans aucune difficulté :

L’extension une fois activée (ne pas oublier cette) devient disponible dans le menu « Outils > Importer » :

Je lance donc le processus d’import, que je pensais être une simple formalité :

1. 0 catégorie importée… Tient, c’est curieux, mais je regarderai plus tard !
2. Blocage à l’import des utilisateurs. Par intuition, je me dis que le problème vient peut-être du nom d’utilisateur de test « admin », identique sur mes deux instances de test. Bingo ! Un changement rapide via phpMyAdmin valide cette hypothèse et me permet de continuer
3. 0 article importé : zut !
4. 25 commentaires importés… sans les articles associés !

Aparté sur les contraintes d’intégrité en MySQL

Bref… cet import semble être un bel échec : après vérification, la base est même devenue incohérente, avec des commentaires totalement orphelins en base. C’est dans ce genre de moments qu’on se redit que les contraintes de clés étrangères sont vraiment une bonne idée pour garantir l’intégrité référentielle de la base.

C’est également à ce moment qu’on se rend compte que Dotclear a des avantages non négligeables sur son concurrent : il ne fonctionne en effet (dans sa version 2) que sous InnoDB et implémente ces contraintes d’intégrité, alors que WordPress (même dans sa dernière version), reste par défaut sous MyISAM qui ne supporte pas les contraintes d’intégrité…

Voici à titre d’illustration une capture d’écran du module « Conception » de phpMyAdmin pour la base de Dotclear. On s’y rend compte que celles-ci permettent de mieux comprendre le fonctionnement de la base et le lien qui existe entre les données :

Bilan

Ce constat étant effectué, je persiste et essaye de comprendre pourquoi ce plugin d’import n’a pas fonctionné… Par chance, il est constitué d’un unique fichier, ce qui va faciliter mon analyse, qui sera rapide : ce plugin n’a été conçu que pour l’import de blogs sous Dotclear 1.X (les anciens noms de tables et de champs sont révélateurs).

La version 2 de Dotclear étant parue depuis 2008, je suis déçu de constater qu’il n’existe pas encore sur le dépôt WordPress officiel de plugin pour la migration « Dotclear 2 > WordPress », d’autant plus qu’une de mes motivations pour tester WordPress est sa communauté et le nombre d’extensions/thèmes disponibles.

Et de WordPress vers Dotclear ?

Pour affiner mon jugement, même si ce n’était pas le but initial, j’ai tenté l’opération inverse : import de données de test de WordPress 3 vers Dotclear. Ce dernier dispose en standard d’un module d’import de données WordPress. Et là, le test s’est révélé concluant :

Troisième mi-temps

Comme je n’aime pas m’avouer vaincu, j’ai sorti mon arme joker… Google ! Il m’a conduit sur cet article détaillant la procédure.

Le plugin d’import utilisé est une mise à jour de celui que je mentionnais ci-dessus. Et afin d’apporter ma pierre à l’édifice, voici quelques remarques pour aider à la migration :

• Le bug de l’import des utilisateurs subsiste : il faut donc veiller à ce que le premier utilisateur créé sous WordPress aie un login différent de celui du blog Dotclear que vous voulez importer
• L’import des liens ne fonctionne toujours pas
• Ce plugin ne fonctionne que si les articles sont saisis en utilisant la syntaxe XHTML (et non la syntaxe wiki).

On peut régler ce dernier problème en convertissant un à un les billets Dotclear via le lien « Convertir en XHTML » du menu de droite (juste sous « Format de texte : wiki »). Je saisis tous mes billets en syntaxe wiki et je n’avais pas envie de les convertir un par un, d’autant plus que le plugin SyntaxeHL nécessite d’utiliser la syntaxe wiki. J’ai donc trouvé un moyen de contourner cette obligation. Dans la table « post » de Dotclear, il y a 4 champs : post_content, post_excerpt, post_content_xhtml et post_excerpt_xhtml. Quand on saisit un article, le texte est enregistré dans les tables post_content et post_excerpt, mais Dotclear en fait une conversion en XHTML dans post_content_xhtml et post_excerpt_xhtml pour l’affichage. La modification du plugin proprement dite consiste donc à récupérer le contenu des articles depuis ces deux dernières tables au lieu des deux premières.

Voici le détail de la manipulation à effectuer. A la ligne 637 (numéro de ligne susceptible de changer en fonction de votre version du plugin), il faut remplacer le code :

637
638
639
640
641

$post_content = dc2_textconv ($post_content);
if ($post_excerpt != "") {
$post_excerpt = dc2_textconv ($post_excerpt);
$post_content = $post_excerpt ."\n<!--more-->\n".$post_content;
}

par

637
638
639
640
641

$post_content = dc2_textconv ($post_content_xhtml);
if ($post_excerpt != "") {
$post_excerpt = dc2_textconv ($post_excerpt_xhtml);
$post_content = $post_excerpt ."\n<!--more-->\n".$post_content;
}

Cette modification a été testée et approuvée par mes soins ! Le test ayant été concluant en local, il est temps de passer à la réalité. Le blog migré sous Dotclear est disponible à l’adresse http://wpblog.courtine.org/. Il ne s’agit pour le moment qu’une version de test, et beaucoup de choses ont été perdues lors de la migration (images apparaissant en javascript, coloration syntaxique du code, liens entre les billets, pages statiques, etc.), que je m’efforcerai de corriger dans les jours avenir pour véritablement tester et comparer les deux systèmes.

D’ici là, n’hésitez pas à donner votre avis…

J’attendais cette version avec impatience, en particulier pour sa compatibilité avec PHP 5.3 dont j’avais parlé il y a peu (afin d’avoir une véritable compatibilité et non un « hack » non officiel).

Je me suis donc empressé de la tester (en local tout d’abord), avec une bonne surprise : la migration se déroule sans aucune difficulté, soit en utilisant l’outil de mise à jour automatique, soit en écrasant la version précédente par la nouvelle (la version distribuée ne contenant pas le fichier de configuration de connexion, cette opération manuelle a le bon goût de garder les paramètres existants).

Deuxième bonne surprise, pas de régression sur les quelques plugins que j’utilise ! Après ces quelques vérifications d’usage et une sauvegarde complète (base de données comprise), j’ai procédé à la migration réelle du blog, sans aucun problème !

Une fois cette formalité effectuée, j’ai voulu tester la nouvelle version.

En administration, aucun changement significatif. C’est « normal », puisque outre PHP 5.3, cette montée de version est surtout technique, avec une amélioration annoncée des performances du moteur du site.

Voici à quoi ressemble celle-ci, pour ceux qui ne connaissent pas le moteur :

On regrette que cette interface n’aie pas été rendue un peu plus « Web 2.0″, comme celle de WordPress 3.0, que je teste actuellement (pour une éventuelle migration si je suis suffisamment séduit) :

Voyons maintenant ce qui se trouve dans le giron de cette version 2.2. Tout d’abord, il y a eu la réouverture de la soumission de plugins sur le site officiel DotAddict. Jusqu’à récemment, il était nécessaire de glaner ses plugins sur les dépôts non officiels, ou en recherchant sur le web…

Avec cette réouverture de la plateforme officielle, nous avons deux nouvelles connexes :

• l’ajout d’un nombre non négligeable de nouveaux plugins depuis cette réouverture !
• le plugin DaInstaller, simplifiant grandement l’installation et la mise à jour des plugins ou de thèmes, directement depuis DotAddict. Il m’a permis de mettre très facilement à jour mes plugins après l’installation de cette nouvelle version :

Maintenant que le moteur a été complètement revu, on attend avec impatience la prochaine version et une nouvelle interface, de nouveaux thèmes et de nouveaux plugins !…

Après avoir reconfiguré l’ensemble des serveurs, je tente d’accéder à la page d’accueil du blog… et c’est le drame ! La page s’affiche bien, mais les billets ont disparus. Ceux qui sont passés sur le blog dans la journée du mercredi 2 juin ont pu se rendre compte de ce phénomène.

Les billets qui n’apparaissent pas, ça m’a fait penser à un problème de connexion avec la base de données. Ce qui est curieux, c’est que lorsque Dotclear ne parvient pas à se connecter à la base, on n’arrive pas jusqu’à la page d’accueil mais sur une page d’erreur spécifique. Une connexion à l’interface d’administration me confirme d’ailleurs que j’ai accès à une partie de la base : j’obtiens le titre des billets mais pas leur contenu.

Première piste : mes données seraient corrompues suite à la restauration de la base. Quelques requêtes SQL en ligne de commande me permettent d’infirmer cette hypothèse : j’accède bien au contenu des billets.

Je me rabat donc vers une piste PHP (ou une librairie comme php-mysql), suite à la lecture des logs web qui contiennent une grande quantité d’avertissements de type “Warning : Parameter n to myfunction expected to be a reference”. Ces messages me mettent la puce à l’oreille, et un “php -version” m’indique “5.3.2”, alors qu’Ubuntu 9.10 fonctionnait avec PHP 5.2.X.

Dans PHP 5.3, une liste d’évolution est incompatible avec les versions précédentes. Heureusement, je ne suis pas le premier à avoir eu ce problème et une solution non officielle est disponible sur le forum de Dotclear. Elle a été soumise par Dsls dans les réponses 11 et 14, et fonctionne sans problèmes. Il faudra ensuite vérifier vos plugins (et leur appliquer une procédure de migration s’ils ne fonctionnent plus après cette montée de version de PHP).

Sortons maintenant notre appeau à trolls (mais j’assume) : cette évolution de PHP qui oblige toutes les applications à changer une partie de leur code avec des contournements obscurs (transformation d’objets en tableaux, entre autres choses…) me paraît vraiment curieuse.

Autre déception : cette version de PHP est officielle depuis maintenant presque un an (sortie le 30 juin 2009) ! Je trouve regrettable qu’il n’y aie pas un patch officiel de Dotclear (la version corrigée est la 2.2 qui n’est encore qu’en version béta).

Malgré cette déception, j’apprécie Dotclear (en particulier parcequ’il s’agit d’un projet francophone). Cependant, je me demande si je ne vais pas dans un futur plus ou moins proche migrer vers WordPress. La communauté de ce dernier est en effet beaucoup plus nombreuse. Conséquence : le nombre de fonctionnalités (modules), de thèmes, et la vitesse des mises à jour sont beaucoup plus importants. S’il a été un concurrent pendant longtemps, j’ai de plus en plus l’impression que Dotclear est à la traine (la page des modules et des thèmes évolue très peu), et les modules Dotclear sont la plupart du temps des adaptations de fonctionnalités qui existent sur WordPress.

Je pense que j’attendrai la sortie de la version 2.2 pour me décider (si elle ne tarde pas trop).

Ensuite, le voyage de noces (au Canada) est malheureusement terminé, et je reprends donc le travail… et le blogging !

Mais avant de reprendre l’écriture de billets techniques, j’adresse ici un grand remerciement (avant les plus traditionnelles cartes de remerciements envoyées par la poste) à toutes les personnes ayant contribué à nous offrir un magnifique mariage. En particulier à la chorale ! Et pour clore ce billet, voici l’enregistrement du Sicut Cervus de Palestrina qui a suivi l’échange de nos consentements (enregistré avec le H4n Handy Recorder dont j’ai déjà eu l’occasion de parler).