Migrating from PHPNuke
Last modified: January 27, 2008 - 14:00
There are some migration scripts available here: http://www.quillem.com/nuke2drupal
There is some extra code with explanation for migrating web links from phpnuke to drupal in a forum post.

FWIW
there are a few versions of the script at the site referred to above. The latest is at http://bogdan.org.ua/wp-content/uploads/2007/08/phpnuke2drupal-5.x-0.02-...
A common mistake is not creating a forum before running the script, so make sure you do that.
W
Also... (just added reviews migration code too)
I posted info/code on migrating web links and reviews as well (which require CCK). They both require using the phpnuke2drupal script above, CCK, the CCK "link" field, and the code is on this page.
Good luck.
W
Wow...
Looks like some improvements have been made to the .02 script (there is now a .04!)
http://bogdan.org.ua/2006/09/08/php-nuke-60-to-drupal-473-migration-conv...
Enjoy,
W
Thanks Waldo!
First, I want to say THANK you so much Waldo for this awesome script (used version 4). It has saved a ton of time.
The CCK content/link/text/carbon-copy modules need to be enabled for links to import. The cck field schema imported without a hitch. Also good to mention that I didn't append to the main script, I just cut the head down to the first closing tag and added the new code for a second import script and it ran just fine, adopting the settings from the first (migrate.php) script.
For others trying this: I did run into problems, but here's some things I did to resolve them. I'd recommend you check your settings before proceeding with the script :
1) By default, my version of mysql 5 in windows had STRICT_TRANS_TABLE enabled on my development machine. I'd turn that crap off because the behavior of queries differs from previous versions of mysql, to our chagrin. Mostly because inserts that rely on autoincrement fields in the value with empty string '' to fail, so for example "INSERT INTO blah (autoid, uid) values ('', 45)" would mess up should this setting be in your my.ini file. No that's not a real query- I do know that.
2) When the our client's 3rd party developer made a snapshot of the DB (which is all we had), I had to string-replace all the 'latin1' collation and charset to 'utf8'. I also had to save the snapshot as utf8 without BOM. I used notepad++ because it's fast. This kept all the content, complete with markup, exactly the same in both DB's.
3) I was getting an out-of-range issue with regards to the UID field on inserts. This was because in the drupal DB the UID field is an int(11) which was too small to hold the number from nuke. So there were two ways to fix this, a bad way and a better way. The bad way was to do a dump of the drupal DB and change the int to an unsigned bigint with the dumpfile. They say don't hack core though, so the better (but harder) way was to fix the corresponding UID in the nuke snapshot. In order to do that though, I had to look around and subtract (max_users minus 1) from the UID that the script attempted to insert to find that exact number. Then I did a string replace in the nuke snapshot and restored this newly changed DB. This is a reversal of what the script tries to do safely (ie: so as not to overwrite any existing uid). In essence, the uid I had in nuke was too big to fit in an int field, so i turned it into like, uid '3'.
4) Finally, the best thing I did was have a pristine snapshot of the db by using 'backup and migrate' to restore the drupal db, on every fail. That made things much faster.
-- props to Alex S for helping out with this! Some think extreme programming is a waste of time. I say, heck no!
page1solutions.com
Web Programmer
http://www.page1solutions.com/