A l’ombre des figuiers sauvages

Édit du 01/04/2016 : ces conseils ont été rédigés lors d'une migration de WordPress v4.x vers la version 5.4 de PluXml et peuvent ne plus être d'actualité avec la nouvelle version 5.5 de PluXml ou une version plus récente de WordPress.

Édit du 04/01/2018 : ajout d'un lien vers une copie du script, l'url d'origine n'existant plus

///

Pour les raisons évoquées précédement, j'ai finalement quitté l'univers de WordPress.

L'un des avantages de l'open-source et de l'hébergement personnel étant la maîtrise de ses données, il ne m'a pas été compliqué de changer de CMS.

Une sauvegarde complète de mon ancien site sous WordPress, quelques modifications dans les articles existants, un export puis un import et le tout était fini. Tel que décrit cela parait simple et rapide mais cela m'a quand même pris pas loin de deux années. Je procrastine beaucoup :)

Je vous sens effarés par cette durée. Si, si. Bon pour être honnête, la décision m'a pris deux années. La préparation quelques heures et la migration réelle à peine 5 minutes, le temps d'uploader la nouvelle version du site sur mon hébergement et d'y mettre à jour quelques paramètres.

Deux années pour décider de changer c'est long, non ? Oui et non. Comme je l'ai dis WordPress me convenait encore il y a peu mais cela ne m'a jamais empêché d'aller voir ailleurs ce qu'il s'y passait. Par exemple, j'ai suivi les développements de Dotclear depuis 2004, sans pour autant avoir envie de passer dessus. Et puis quand on a un petit serveur local, on s'amuse à y installer plein de choses. Alors des CMS il en a vu passer, et partir.

PluXml, dont je suivais justement le développement depuis ces deux dernières années ;) est l'un des rares à y être resté pour les raisons qui sont décrites sur la page d'accueil du projet : c'est un CMS à base d'Xml, simple et léger, sans base de données, collaboratif avec une communauté active, facilement modifiable à l'aide de thèmes et qu'il est possible de faire évoluer au moyen de plugins.

Et je dois dire que plus je l'utilisais, plus il me convenait. Certes, ce n'est pas WordPress et il y a plein de fonctionnalités qui me manquent mais j'apprends à m'en passer (ou pas). De plus il existe un script pour réaliser une conversion depuis WordPress : wp2pluxml. 

Quand est sortie en juillet dernier la version 5.4 avec son nouveau thème, basé sur le framework PluCSS,  il n'y avait plus grand chose qui me retenait.

Bref, revenons au sujet.

Préalable

Il faut savoir faire fonctionner un serveur local (à l'aide de WAMP sous Windows, MAMP sous OSX ou en natif sous Unix).

• Y installer une instance de WordPress de version identique à celle de son site web
• Y installer une instance de la dernière version de PluXml
• Récupérer le script wp2pluxml wp2pluxml-master.zip (copie locale du master du 12 juin 2014)pour la conversion et l'installer dans l'instance locale de PluXml

La préparation

1. Charger le thème par défaut de WordPress sur son site web
2. Faire une sauvegarde complète de la base SQL de son site web (j'utilise l'extension WP-DB-Backup pour cela, qui me permettait également de faire facilement mes sauvegardes hebdomadaires) et l'importer sur son instance locale de WordPress.
3. Charger le thème habituel de son site web. (C'est la dernière action que l'on effectuera sur le site web avant la migration finale. Toute la suite se passe désormais sur le serveur local)
4.  Sur le serveur local, rechercher à l'aide de PHPMyadmin dans la table "wp_options" (ou équivalent si vous aviez changé par sécurité le nom de la base de donnée de votre site) les valeurs "siteurl" et "home" pour remplacer l'URL du site web par celle de son instance locale de WordPress (il y a de forte chance que ce soit par http://localhost/wordpress/)
5. Comme indiqué dans le Wiki de wp2pluxml, installer l'extension Advanced Export for WP & WPMU sur son instance locale de WordPress car la fonctionnalité d'export intégrée de WordPress ne permet pas de réussir en l'état un import vers PluXml (vous obtiendrez l'erreur #385 Le tableau $items des catégories est vide).

La partie facile de la préparation est finie, maintenant attaquons nous à la partie chronophage qui demandera quelques concessions.

Depuis le tableau de bord de son instance locale de WordPress :

• éditer toutes les URL des catégories pour les rendre uniques si l'on désire par la suite utiliser le plugin MyBetterUrls (j'ai simplement rajouté le préfixe "cat-")
• éditer tous les articles privés, ou protégés par un mot de passe, et leur assigner une nouvelle catégorie distincte pour les retrouver facilement après la conversion
• assigner une nouvelle catégorie distincte aux articles à l'état de brouillon pour les retrouver facilement après la conversion, et les publier
• éditer les articles multi-catégories et n'en garder qu'une seule par article (la principale selon vous) sinon lors de la conversion ce sera la première catégorie par ordre alphabétique qui sera gardée (partie réellement chronophage si vous êtes adeptes des articles multi-catégories comme moi)
• modifier le répertoire utilisé pour les médias (par défaut ceux-ci se trouvent dans le répertoire wp-content/uploads) et indiquer à la place data/medias, le répertoire par défaut des médias de PluXml. Cela évitera d'avoir à éditer manuellement tous les liens par la suite. :)

La préparation est finie, maintenant attaquons nous à la conversion.

La conversion

Il est temps de préparer l'export de son instance locale de WordPress.

1. Depuis le tableau de bord, allez dans Outils -> Advanced Export
2. Modifier les options suivantes :
   • Pour "Restrict Content", choisir "Posts" ;
   • Pour "Restrict Status", choisir "Published" ;
   • Pour "Include Blog Tag/Category Terms", choisir "Categories".
3. Cliquer sur le bouton d'export et enregistrer le fichier XML dans le répertoire wp2pluxml de son instance locale de PluXml.
4. Ouvrir son navigateur et rentrer l'URL de l'instance locale de PluXml, puis aller sur la page de wp2pluxml (il y a de forte chance que ce soit http://localhost/pluxml/wp2pluxml/)
5. Suivre les instructions pour lancer la conversion et croiser les doigts.

La finalisation

Une fois dans la partie administration de PluXml il est possible qu'un ou plusieurs articles n'aient pas d'identifiants, affichent un "//" pour la date et ne soient pas éditables. Cela est dû à un bug du script wp2pluxml, mais il existe une solution simple pour corriger cela : ouvrir le fichier wp2pluxml.log qui recensera le ou les articles en erreur (#77 Erreur lors de l'ouverture du fichier ../data/articles/0001.draft,001.001.201508170043..xml),  puis les rechercher dans le répertoire /data/articles/.

Deux cas se présentent :

1. lorsque la partie terminale du nom du fichier est du type 12345..xml, il faut mettre du texte entre les 2 points avant l'extension xml : 12345.text.xml.
2. lorsque la partie terminale du nom du fichier contient un ou plusieurs caractères spéciaux 12345.%9°c.xml, il faut supprimer ces caractères : 12345.9c.xml.

Comme indiqué dans la solution, revenir dans l'administration de PluXml puis rafraîchir la liste des articles.

Et c'est pas fini :)

1. Aller dans la liste des catégories et masquer les deux catégories créées lors de la préparation pour les brouillons et les articles privés/protégés.
2. Ouvrir la liste des articles, faire un filtre sur ces deux catégories puis les mettre hors ligne, cela les passe à l'état de brouillon. Pratique pour retrouver ses brouillons, et astuce pour éviter que ne s'affichent ceux qui étaient privés/protégés. (Il existe des plugins pour rendre de nouveau les articles privés/protégés).

Et c'est pas presque fini :) la conversion ne concernant que les articles, il ne faut pas oublier de créer des pages statiques sur PluXml en les nommant à l'identique de celles du site web, puis de les éditer et d'y faire un copier/coller depuis les pages du site web.

L'on peut désormais passer à la dernière étape.

La migration

1. Se connecter à son hébergement
2. Optionnel mais recommandé : faire une copie de tout en local au cas où.
3. Créer à la racine un répertoire backup_WP (par exemple) et un répertoire backup_media (par exemple)
4. Déplacer l'ensemble des fichiers et sous-répertoires utilisé pour les médias (par défaut dans wp-content/uploads) vers le répertoire backup_media
5. Sauf en connaissance de cause, attention à ne pas effacer, déplacer ou remplacer votre fichier .htaccess principal (en faire une copie avant de passer au point suivant ne coûte rien surtout si celui-ci est personnalisé)
6. Déplacer le reste des fichiers et sous-répertoires utilisé par WordPress vers le répertoire backup_WP
7. Uploader tous les fichiers de l'instance locale PluXml vers le site web (à vous de choisir si c'est à la racine ou ailleurs).
8. Déplacer l'ensemble des fichiers et sous-répertoires du répertoire backup_media vers data/medias.
9. Si vous souhaitez utiliser la réécriture d'urls, allez dans Paramètres -> configuration avancée, activez-la, puis désactivez-la et réactivez la de nouveau. Cela mettra à jour le fichier .htaccess et vous évitera de perdre du temps à essayer de comprendre pourquoi la page 2 est en erreur :)
10. Optionnel mais recommandé : faire une sauvegarde complète de la base SQL du site web avant d'y faire un peu de ménage pour en retirer les anciennes tables utilisées par WordPress.

Cette fois c'est fini, le reste n'est plus que cosmétique.

Epilogue

Et c'est ainsi que j'ai migré la totalité des 697 articles et 2426 des 2437 commentaires de mon ancien site sous WordPress vers PluXml.

(oui j'ai prévu de rechercher les 11 commentaires manquants) ;)

///

Édit du 10/09/2015 : les 11 commentaires manquants étaient le résultat d'un bug affectant la conversion de l'horodatage des secondes par wp2pluxml, l'explication détaillée dans cette discussion.

kowalsky

Re : wp2pluxml : passez de Wordpress ou SPIP à Pluxml en un clic !

je suis toujours à la recherche de mes 11 commentaires perdus. Est-ce que l'un d'entre vous peut m'indiquer la règle de conversion des dates pour le nommage des fichiers xml des commentaires ?

Pour les articles c'est assez simple, c'est en clair dans le nom du fichier, un article écrit le 20/10/1996 à 16:00:00 se nomme : 0005.002.001.199610201600.xxxxxxx.xml

Mais pour un commentaire écrit le 24/01/2005 à 19:45:01, le fichier se nomme : 0005.1106592300-1.xml et je n'arrive pas à comprendre comment se construit cette valeur

Stéphane

Bonjour

La date dans le nom des fichiers des commentaires est un timestamp retourné par la fonction php: time()
http://php.net/manual/fr/function.time.php

kowalsky

Merci Stéphane,

cela m'a permis de retrouver mes 11 commentaires perdus. Et la raison de la perte de ces commentaires.

C'est lié au formatage de l'horodatage des commentaires pendant la conversion.

Quand tu m'as renvoyé vers la fonction time() (qui retourne l'heure courante, mesurée en secondes depuis le début de l'époque UNIX, (1er janvier 1970 00:00:00 GMT)) , cela m'a permis par la suite de trouver une macro convertissant le Timestamp (Unix) en DateTime (dd/mm/yyyy hh:mm:ss)

     DateTime = TimeStamp/86400+25569

Dans WP et PluXml bien que les commentaires s'affichent généralement sous la forme "dd/mm/yyyy hh:mm", ils sont enregistrés avec les secondes "dd/mm/yyyy hh:mm:ss".

Sauf qu'en comparant la liste des commentaires de ma base SQL et ceux du répertoire "data/commentaires", j'ai constaté que tous les TimeStamp utilisés pour le nommage des fichiers commentaires sous PluXml sont des multiples de 60 : les secondes n'ont donc pas été prises en compte.

06/12/2006 16:32:49     →    1165422720    06/12/2006 16:32:00
06/12/2006 16:56:04     →    1165424160    06/12/2006 16:56:00
06/12/2006 16:59:55     →    1165424340    06/12/2006 16:59:00
06/12/2006 18:26:42     →    1165429560    06/12/2006 18:26:00
06/12/2006 18:27:09     →    1165429620    06/12/2006 18:27:00
06/12/2006 18:32:22     →    1165429920    06/12/2006 18:32:00

Et lorsque deux (ou plusieurs) commentaires d'un même article sont enregistrés à quelques secondes d’intervalles dans la même minute, nous nous retrouvons alors pendant la conversion avec deux fichiers dont le nom est identique. (Apparemment c'est le plus récent qui est conservé).

07/02/2007 09:54:37     →       
07/02/2007 09:54:42     →    1170842040    07/02/2007 09:54:00

10/03/2009 22:19:00     →       
10/03/2009 22:19:36     →    1236723540    10/03/2009 22:19:00

Et voilà !

A priori, ça provient du plugin wp2pluxm qui "oublie" les secondes pendant la conversion, mais je ne suis pas assez calé pour retrouver où cela se passe dans le code pour plus de certitude.

La bonne nouvelle étant que ce problème n'apparait pas quand on tente de le reproduire depuis PluXml, les secondes étant bien prises en compte dans l'horodatage des commentaires :

0039.1440157489-1.xml     →    21/08/2015 11:44:21
0039.1440157461-1.xml     →    21/08/2015 11:44:49

Ce qui m'amène à te formuler deux demandes d'évolutions

1. Afficher les dates dans la partie administration sous la forme "dd/mm/yyyy hh:mm:ss" au lieu de l'actuel "dd/mm/yyyy"

2. Pouvoir aussi modifier l'horodatage des secondes en mode édition ( -> Date et heure de publication)

Stéphane

Petite précision: si 2ieme fichier commentaire est créé avec un heurodatage déjà existant (pour le même article), ils sont différenciés par le dernier chiffre

0005.1106592300-1.xml

le 2ieme fichier sera

0005.1106592300-2.xml

2ième précision: cette règle va changer avec le nouveau système de commentaire que je suis en train de développer pour prendre en compte la hiérarchisation et l'indentation des commentaires (pour pouvoir répondre à des commentaires). Le dernier chiffre fera partie de l'identifiant unique du fichier et sera systématiquement incrémenté lors de la création d'un nouveau commentaire

@kowalsky: je vais regarder 2 tes demandes

Voilà, c'est fait.

La migration de mon site vers PluXml s'est passée sans trop d'encombres.

Il me reste cependant quelques petites retouches à faire, mais je vous narrerai tout cela plus tard.

Après dix années d'utilisation et de satisfaction, je vais abandonner Wordpress pour faire tourner ce site.

Alors qu'en 2004, Wordpress était ce qu'il se faisait de mieux en matière de CMS, aujourd'hui c'est devenu une usine à gaz qui ne me convient plus suite à l'introduction récente de certaines fonctionnalités non-désirées en "core", le moteur du CMS.

Cela a commencé par l'usage des polices de caractères de Google, avec des requêtes vers le site de Google, et ce même depuis la partie d'administration.

Puis récemment par l'utilisation forcée des émojis, qui rajoute entre autre des scripts dans l'entête du site en plus de faire des requêtes vers le site wp.org

D'une part, il m'apparait particulièrement contre-productif de devoir installer à chaque changement de version des plugins pour désactiver ces fonctionnalités "core" ! Et d'autre part, toutes ces requêtes externes sont autant de façons détournées de traquer les internautes. Ce que je n'apprécie pas plus.

Bref, bye Wordpress.

• le flux RSS est désormais affiché en entier; je sais, ça va me faire chuter mes stats de fréquentation mais comme de toute façon je ne les regarde plus, au final vous m'en remercierez;


• les commentaires sont imbriqués;


• les archives ont changé de format, si vous aviez des liens pointant directement vers mes notes, faudra les refaire; ça c'est pour embêter mes copains hot-linker :)


• le nouveau thème est optimisé pour un affichage sur des écrans de faible résolution,  mais il n'est cependant pas dans une configuration optimale pour les téléphones mobiles de nouvelle génération à interfaces tactiles. J'me garde ça sous le coude pour les longues soirées d'hiver (je ne précise pas de quelle année bien entendu) ;)