Port wordpress import module to D7

I'm willing to help. I've been using Wordpress for 3 years and Drupal for 6 months, and I've got a Wordpress blog I'd like to move over to Drupal 7 I can use as a test case.

Has anyone tested this module in D7 yet? Do you have a list of known issues you'd need resolved for 7?

Can we please get a DRUPAL-7--2 branch against which we can diff patches?

There is now a DRUPAL-7--2 branch, which at the moment has the exact same contents as the DRUPAL-6--2 branch.

I will be taking a look at what is required to upgrade the Drupal 6 version of this module to Drupal 7 over the coming weeks.

One problem with migrating this module to 7.x is that there currently is not a working version of the ctools for Drupal.

http://drupal.org/project/ctools

/me /semivolunteers.

An alpha for ctools was released this week.

Subscribing

I hope to find the time to work on it these days

Bumping to 7.x-2.x-dev.

There is now a 7.x branch of Wordpress Import and a version of ctools module that can be used for testing. We can start investigating the code and filing upgrade tasks against the 7.x branch.

I' m looking to migrate a sizeable WordPress blog to D7 so I just tried this WordPress Import 7.x module with both ctools (7.x-1.x-dev and 7.x-1.0-alpha1). I created the necessary ctools DB tables and got the following error. The same WXR imports fine into D6.

PDOException: SQLSTATE[23000]: Integrity constraint violation: 1048 Column 'name' cannot be null: INSERT INTO {ctools_object_cache} (sid, obj, name, data, updated) VALUES (:db_insert_placeholder_0, :db_insert_placeholder_1, :db_insert_placeholder_2, :db_insert_placeholder_3, :db_insert_placeholder_4); Array ( [:db_insert_placeholder_0] => lv_KlGQBXMJb-e5ZxssKM7NNqSl1fu0NYPHtNcn0cU8 [:db_insert_placeholder_1] => wordpress_import [:db_insert_placeholder_2] => [:db_insert_placeholder_3] => O:8:"stdClass":0:{} [:db_insert_placeholder_4] => 1289572427 ) in ctools_object_cache_set() (line 76 of /home3/nbrights/public_html/drupal/modules/ctools/includes/object-cache.inc).

Would love to see this working but unfortunately I'm no developer so can not offer any patches.

Got a little further by patching to specify a cache name

// *** SETTING THE FORM UP FOR MULTISTEP *** //
$form_state = array(
'cache name' => 'Cache',
);

Now get another error

Fatal error: Call to undefined function file_create_path() in /home3/nbrights/public_html/drupal/modules/wordpress_import/wordpress_import.module on line 209

I've just spent a few hours trying to get the code to work, and have made a small bit of headway, getting the code to pass all the coder.module tests. Coder module however doesn't point out every single change that needed to be made. For instance, it didn't catch the file_create_path() method that no longer exists which was mentioned in the previous comment.

So here's an initial patch that should be applied to 7.x-2.x-dev.

I got to a point where i cant figure out why the code still doesn't work.

It appears that the code is expecting the output from ctools_wizard_multistep_form() to be a rendered form, but its rather a drupal $form Array. I'm not experienced enough with the ctools multi-step wizard to continue to track down these errors. I got the admin page displaying correctly under Drupal 7. But the page itself doesn't show any content. I made a half-hearted attempt at converting some of the database calls to to the d7 db api format, however since i couldn't get anything about the multi-step form to work, i got stuck there and decided to stop.

Perhaps this initial push would help stir other's interest in finishing the code migration to d7.

Cheers.

forgot to update status.

A second version.... got a little bit further. The multi-step form is actually working now. But there are some limitations with the new Form API limiting the file upload type (forbids the XML extension) which i couldn't figure out. (I was able to load a WXR file from the files/wordpress/ folder though).

The final import step breaks during batch processing with some more complex errors occurring that i believe have to do the taxonomy selection. I haven't walked through the code as my computer was completely offline (and hence unable to access d7 api's for much of the time i was working on this).

Its bugging me that these patch files are not registering in the test queue..... maybe the naming scheme ive chosen doesnt work, here is a re-up of the previous file, with a different file name.

reroll.

damnit, im still getting the hang of patching, couldnt figure out if it is cvs diff -dp or cvs diff -up.... i think this one is correct now. sorry for the flubs.

@jrguitar21: the patches don't get flagged for testing because the project doesn't have tests enabled.

subscribe.

When will we see a complete working version of 7.x?

Changing title for better use in the dashboard.

@Andy B: so far, the maintainer hasn't looked at or responded to this, and i assume it means he/she is waiting on a better patch, and that they aren't interested in or don't have time to do the work themselves.

Unfortunately, I myself, no longer have a need to push through with the final steps for the d7 port, as I found a horrible workaround... roughly: Clean install of D6 => wordpress_import => Upgrade core to D7, deleting wordpress_import module in the process. This option wasn't without its own errors and I had to do a significant amount of cleanup work because of issues with taxonomy vocabularies getting mangled in the upgrade to D7.

The patches above should be more than enough to get someone who's interested started on the rewrite of the remaining sections... but it will require significant knowledge of the d7 changes for importing/creating comments/nodes and building taxonomy terms using the new Entity API. This would be an excellent primer for someone to get their hands dirty with D7, I simply dont have the time right now :/

The work left to be done is roughly:

* Fix the issue with file upload not accepting XML files.
* Rewrite the node import section, with special attention to the 'auto-generated' Wordpress input format (not sure if there are any changes in this api between d6/d7).
* Rewrite the taxonomy term and vocabulary creation section.
* Add a section for adding the vocabulary(ies), as field(s) to the pertinent content type.
* Adjust the comment creation section.

I simply had to make my first git-patch:

so here goes:
i added file validation to the upload wordpress_import_form_file_validate() and replaced all instances of file_directory_path() according to http://drupal.org/node/224333#file_directory_path

now when i disable comments, images and tags the posts get imported and mapped, yet are still missing their body. will have to read up on fileAPI some more, hope someone can use this!

attempted to fix some more problems, hope someone will get the comment import working.

got the comment import working! it is unclean though...

I'm confused. I cloned the git repository of the 7.x-2.x branch and then tried to start applying patches and it seemed to be unable to make matches. I was able to apply the patch in #17 but the ones after that my patching tool couldn't match. Am I trying to patch them to the wrong code? I would like to help test/code this and don't want to have to redo the entire thing. Thanks for the help!

second try of a patch. just applies everything i have to the 7.x-2.x branch
(including patches above)
does this work better?

if someone can't wait could give a shot to wordpress-migrate module
http://drupal.org/project/wordpress_migrate

Hi,

can someone explain what's the status of this D7 port ?

Sorry. I guess this module will stand for D6, and we should use http://drupal.org/project/wordpress_migrate for D7.