Import from WP to s9y - how to get rid of the revisions

[ju]

When I tried to import my wordpress (v2.6.2) blog into serendipity (1.3.1) I found that I had not one but several versions of each post, some of which were complete, others not. This seem to be due to a fairly recent wordpress-feature: http://codex.wordpress.org/Revision_Management

One way to get rid of the unnecessary copies would be to delete them from the database before starting the import (they can be recognized from post_type revision). Is there any other or better way to obtain a clean import?

Another problem are Umlaute. The wordpess installation uses UTF-8 but some plugins created their db-tables with ISO-8859-1 (that's one of the reasons I why want to switch from WP to s9y). Whatever I chose for import, the umlaute are a mess afterwords. How should I approach this problem best? (I am a beginner with mysql.)

And yet another import-related question: since which version does serendipity need php5 for an rss-import? It worked perfectly with the fairly old version of the debian etch packet, but the most resent version keeps telling me, that I need php5 (which I can't install easyly because dpkg will then uninstall phpmyadmin and gallery2). So I think of first installing some older version of s9y, import the data und then upgrade step by step to more recent versions.

//ps: Thank you for the great manual! It is the main reason for me to no consider using s9y although it had looked far more complicated than WP when I first tried both scripts.

[garvinhicking]

Hi!

Thanks for noticing this. I sadly believe, yes, the importer is not yet crafted to handle those situations. I believe the best way would be to make sure the SQL query only fetches the most recent revision. Or maybe there is a way to deduce the "published" version of a post and ignore all other revisions.

Another problem are Umlaute. The wordpess installation uses UTF-8 but some plugins created their db-tables with ISO-8859-1 (that's one of the reasons I why want to switch from WP to s9y). Whatever I chose for import, the umlaute are a mess afterwords. How should I approach this problem best? (I am a beginner with mysql.)

Basically, the DB collation should not matter as much. I'd make sure that your s9y runs as UTF-8 (check the s9y charset configuration), and that you enable the option "Use database charsets" (or sth like that) which makes sure that s9y uses a UTF-8 DB connection. Then at last make sure when you import you select "UTF-8" as the WP-charset, and that you do NOT enable the option "transform html entities".

And yet another import-related question: since which version does serendipity need php5 for an rss-import? It worked perfectly with the fairly old version of the debian etch packet, but the most resent version keeps telling me, that I need php5 (which I can't install easyly because dpkg will then uninstall phpmyadmin and gallery2). So I think of first installing some older version of s9y, import the data und then upgrade step by step to more recent versions.

This was an import glitch that happened because the s9y rss imported always assumed it was importing a WPXRSS feed. This requires PHP5. Best is to get the most recent RSS importer PHP file from the s9y 1.4 snapshots and use that one, it does not have this stupid restriction. Sadly I am currently so busy that I don't have the time to put up a new s9y release with this issue fixed.

HTH,
Garvin

[judebert]

Seems to me that the SQL could be revised to check for post_type != 'revision', yes?

[ju]

I deleted the unnecessary revisions with:

mysql> delete from wp_posts where post_type ='revision';
Query OK, 152 rows affected (0.01 sec)

and my wordpress-blog is still alive
unfortunately had no time to try another import into s9y yet. thank you to garvinhicking for all the hints!