I agree with Waldo - went from Php-Nuke to Drupal with this script in just a few hours (most of it was setting up the Drupal site, the actual conversion was just a few minutes). It was one of the big reasons I chose Drupal over some of it's competitors (because this script makes it so damn easy to convert).
First, I want to say THANK you so much Waldo for this awesome script (used version 4). It has saved a ton of time.
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!
Comments
Start with this script...
here's what I used: http://bogdan.org.ua/wp-content/uploads/2007/08/phpnuke2drupal-5.x-0.02-...
Enjoy.
W
Agreed!
I agree with Waldo - went from Php-Nuke to Drupal with this script in just a few hours (most of it was setting up the Drupal site, the actual conversion was just a few minutes). It was one of the big reasons I chose Drupal over some of it's competitors (because this script makes it so damn easy to convert).
Thank VValdo.
Thank VValdo.
Cool!
Glad it worked for you guys!
W
Note that there is a newer
Note that there is a newer version here w/some improvements...
http://bogdan.org.ua/2006/09/08/php-nuke-60-to-drupal-473-migration-conv...
W
i am also interested in
i am also interested in this. will it work with phpnuke 8?
Not sure. Depends how much
Not sure. Depends how much the database has changed in the versions of phpnuke.
In any event, you might be able to get away with trying the script and then making changes if it doesn't work...
W
Problems resolved and Much Thanks to 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.
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
Fantastic!!
Glad to hear the script is still of value!
I also want to credit the others who helped work on it-- I stood on the shoulders of giants :)
What a relief to get off phpnuke, huh?
W
PS- some useful links for anyone reading this who's going to migrate:
http://bogdan.org.ua/2006/09/08/php-nuke-60-to-drupal-473-migration-conv... <-- a page w/the latest script and perhaps useful thread
http://drupal.org/node/202528 <- some extra code I used for migrating phpnuke weblinks and reviews using cck