la chance sourit aux audacieux. J'ai voulu tenter le coup, pour voir et parce que le principe du script me plait bien.
1- installation de wp2pluxml sur localhost
2- export du blog Wordpress (réplique en localhost)
3- migration via wp2pluxml
4- nettoyage à la main de tous les faux articles. 1 par image, heureusement pas trop nombreuses
5- avec mon éditeur de texte, rechercher/remplacer une chaîne de caractères dans tous les fichiers articles avec le bon chemin vers les images
6- appliquer la manip de recherche/remplacement indispensable pour les brouillons, impossibles à supprimer (cf. Github)
Bingo ! Les articles ont tous retrouvé leur image respective.
L'exercice est formateur.
Par contre, je sèche sur le remplacement de l'auteur. Les articles ont été attribués à l'administrateur.
Je ne trouve pas où se loge cette information.
Bravo, mille fois merci. C'est un boulot admirable.
Mise au point d'un futur site sur serveur local MAMP (MacOS)
```Version de PHP : 7.4.2
Apache/2.2.34 (Unix) mod_wsgi/3.5 Python/2.7.13 PHP/7.4.2
mod_ssl/2.2.34 OpenSSL/1.0.2o DAV/2
mod_fastcgi/mod_fastcgi-SNAP-0910052141
mod_perl/2.0.11
Perl/v5.24.0
Nouveau sur PluXml, admiratif devant sa facilité d'utilisation, sa rapidité et tant d'autres choses, j'ai entrepris de migrer mon site SPIP avec wp2pluxml... Bin ça marche pas... Il reconnaît bien l'export, mais impossible de cocher SPIP à la deuxième étape. Et si je pass outre, il me dit qu'il y a une erreur et ne se termine pas
Pas grave grave, mais dommage quand même...
Enfin, ça me donne une raison de tout reprendre à zéro !
Mais bon... Si des fois ça pouvait marcher, j’adorerai :P
j'ai rédigé dans la partie entraide du forum quelques conseils qui récapitulent la plupart des informations glanées par ici pour réussir sa migration depuis Wordpress.
Qu'entends-tu par "pas compatible PluXml 5.4" ? C'est la version que j'ai utilisé pour migrer mon site
Sinon pour tous,
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
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.
Et lorsque deux (ou plusieurs) commentaires [em]d'un même article[/em] 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é).
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 :
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
Réponses
le premier lien dans le post de départ est HS ...
mes sites principaux : fonds d'écran gratuits - longue traîne - référencer votre site - brocante en ligne -
pas grave + rapide, merci !
mes sites principaux : fonds d'écran gratuits - longue traîne - référencer votre site - brocante en ligne -
Bonjour nico est ce que on peut passer directement de blogger au pluxml sans passer par wordpress ou pas ?
Merci
Je ne sais pas si d'autres outils existent.
Auparement pas nico et j'aimerais bcp convertir mon blog qui tourne sur blogger au pluxml.
Merci pour ta reponse
la chance sourit aux audacieux. J'ai voulu tenter le coup, pour voir et parce que le principe du script me plait bien.
1- installation de wp2pluxml sur localhost
2- export du blog Wordpress (réplique en localhost)
3- migration via wp2pluxml
4- nettoyage à la main de tous les faux articles. 1 par image, heureusement pas trop nombreuses
5- avec mon éditeur de texte, rechercher/remplacer une chaîne de caractères dans tous les fichiers articles avec le bon chemin vers les images
6- appliquer la manip de recherche/remplacement indispensable pour les brouillons, impossibles à supprimer (cf. Github)
Bingo ! Les articles ont tous retrouvé leur image respective.
L'exercice est formateur.
Par contre, je sèche sur le remplacement de l'auteur. Les articles ont été attribués à l'administrateur.
Je ne trouve pas où se loge cette information.
Bravo, mille fois merci. C'est un boulot admirable.
Mise au point d'un futur site sur serveur local MAMP (MacOS)
```Version de PHP : 7.4.2
Apache/2.2.34 (Unix) mod_wsgi/3.5 Python/2.7.13 PHP/7.4.2
mod_ssl/2.2.34 OpenSSL/1.0.2o DAV/2
mod_fastcgi/mod_fastcgi-SNAP-0910052141
mod_perl/2.0.11
Perl/v5.24.0
Nouveau sur PluXml, admiratif devant sa facilité d'utilisation, sa rapidité et tant d'autres choses, j'ai entrepris de migrer mon site SPIP avec wp2pluxml... Bin ça marche pas... Il reconnaît bien l'export, mais impossible de cocher SPIP à la deuxième étape. Et si je pass outre, il me dit qu'il y a une erreur et ne se termine pas
Pas grave grave, mais dommage quand même...
Enfin, ça me donne une raison de tout reprendre à zéro !
Mais bon... Si des fois ça pouvait marcher, j’adorerai :P
j'ai rédigé dans la partie entraide du forum quelques conseils qui récapitulent la plupart des informations glanées par ici pour réussir sa migration depuis Wordpress.
Qu'entends-tu par "pas compatible PluXml 5.4" ? C'est la version que j'ai utilisé pour migrer mon site
Sinon pour tous,
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
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
Consultant PluXml
Ancien responsable et développeur de PluXml (2010 à 2018)
J'ai tout viré de WordPress ça a été plus vite
cela m'a permis de retrouver mes 11 commentaires perdus.
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 [em]d'un même article[/em] 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
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
Consultant PluXml
Ancien responsable et développeur de PluXml (2010 à 2018)