phpnuke to drupal

I recommend Waldo's script. It worked well for us, but 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