PHP-Nuke 6.0/6.5 to Drupal 4.7.x/5.x migration (conversion)
8th September 2006
Post last updated: April 18, 2010.
Now there is a Drupal 6.x module available. It is in no way related to the migrate script(s) below.
The newest script version migrates from PHP-Nuke 6.5 to Drupal 5.x.
Download the latest version of the migration script.
In 2002 I set up a PHPNuke-6.0 – based portal. Eventually it died due to the lack of time investments and support from collaborators. Now, when time came to revive the project, I made a search and decided to use Drupal as a base CMS for the portal.
In order to migrate userbase from an old portal to the new Drupal-powered one, and following the topic at drupal.org, I found a script and its modification.
I used it to migrate only users, and made some cosmetic changes:
- added options for custom phpnuke table prefixes
- default user name is now = uname (login), not ‘temp_name’, as before
- I replaced hard-coded links to ‘migrate.php’ with links to $_SERVER['PHP_SELF'], so that if you rename the script you don’t have any problems with that
- now forum topics should not be promoted to the main page (changed 1 to 0 as hinted by Alexis)
Finally, I would like to thank both Karthik Kumar for the original script and Alexis Bellido for the 6.0_to_4.7 modification.
Update: Waldo updated the migration script.
Here are the changes:
- imports from (a security-patched) Nuke 6.5 -> Drupal 5.1
- imports story categories into Drupal taxonomy
- incorporates phpnuke “Contributor writes…” into story
- incorporates phpnuke admin story “note”
- imports polls (does not import record of who already voted. You can easily “close” old phpnuke polls via Admin page. I left them open.)
- imports poll comments
- imports *anonymous* comments for stories, fora, & polls
- imports anonymous forum posts
- filters BBCode to make semi-compatible with Drupal BBCode module
- uses Drupal 5.0 API, and must be run from drupal root directory (/drupal-5/, for example)
Thanks to Waldo for his work!
Latest update: Waldo sent the newest, improved version of the PHP-Nuke-2-Drupal conversion script. Here is Waldo’s description:
New Fixes:
- retain original user registration date & last visit 4/22/07
- fixed user migration bug which could result in screwed max_uid in session table 4/22/07
- store anonymous forum posts names in the log for future compatibility w/Drupal 6 7/16/07
- uses the “tidy” extension (if installed) in php 5.x to clean up the HTML of postings & stories 7/30/07
- bug fixes (possibly) related to drupal 5.2 where the fora had the wrong “changed” date resulting in misordered node lists. 7/30/07
- polls properly remember date of last comment 7/30/07
If you have the “tidy” PHP extension, it should close all open HTML tags and stuff in stories.
update: I added to the script some more debug messages in case something goes wrong (as recommended by me) – that pushed the version up to 0.03.
Also, now MySQL connection collation is set to utf8 before doing anything – this should fix the problems with non-English characters in the imported texts (especially accented/umlauted/etc characters). Thus I upped the version to 0.04. For reference and in case 0.04 doesn’t work for you, I keep the older versions as well.
Download the latest phpnuke2drupal-5.x-0.04-W.zip or the latest tar-gzipped version of the phpnuke2drupal migration script.
update: to import Reviews and WebLinks from PHPNuke to Drupal, have a look at this and this comments; you will need CCK, and might need CCK Link Field to import reviews/weblinks.
Previous (older) versions:
phpnuke2drupal-5.x-0.03-W.zip
phpnuke2drupal-5.x-0.03-W.tar.gz
phpnuke2drupal-5.x-0.02-w.zip
phpnuke2drupal-5.x-0.02-w.tar.gz
phpnuke2drupal-5.x-0.01 (VValdo’s huge improvements first appear here)
first version with my minor modifications
IMPORTANT: for migration to work you will need MySQL version to be >= 4.1.1. Earlier versions do not support the STR_TO_DATE() function, used in the migration script.
IMPORTANT: if you want to migrate forum entries from PHPNuke to Drupal, be sure to setup forum in your Drupal installation first – otherwise migration of forum entries will fail. See comments 13-17 below for user experiences.
If you do not get any help here, there is also a drupal.org migration thread. I will keep this page updated for as long as I get new information about the migration script.
If you encounter any problems during migration – just search/scan the comments, your problem might have been already solved by someone else.
June 18th, 2007 at 23:01
hi!
i’d like to use your script, but it says mysql connection error…
tried another script and i got the following:
on the main page the script counts well the number of stories and users, but clicking next (migrating users) drops error..
i got the sql server on other ip, i set up everything correctly when edited the script, dunno what’s wrong..
thanks for your help!
June 19th, 2007 at 22:55
Fulldump,
“tried another script” – what would that mean?
and you even didn’t specify the exact error you got… doing guesswork isn’t my hobby, so please be more specific. And do check your DB settings once more :). For the version I used for conversion, there were absolutely no problems.
Also please be advised, that though I might provide some help, there are no promises/guarantees that there will be help and that it’ll be in a timely manner. Actually, the conversion/migration scripts were not written by me – I’m merely providing a place for the versions I’m aware of.
If you know of another phpnuke-2-drupal conversion scripts – please let me know. It’s just convenient to have all the relevant links in one place.
Update: as I learned from personal correspondence, the situation mentioned in the comment above was successfully resolved.
July 18th, 2007 at 13:54
I am trying to use this script too. But I am getting the same error as Fulldump said. Can you let me know how did he fix his script?
Thanks.
August 2nd, 2007 at 10:40
Hi Nemo,
I was away from internet for over 20 days, so couldn’t have answered earlier.
And, unfortunately, it appears that I didn’t save Fulldump’s email; I do remember that he was writing about the removal of “several lines of code”, but that is all I remember.
Fulldump, if you are still following – could you please post the fix to your problem here?
Meanwhile, I’ll search my email archives once again…
August 19th, 2007 at 13:38
I sent an updated version of my migration script this morning FWIW.. hopefully it’ll appear here soon.
NOTE: The mysql error referred to above may have resulted from not entering your mysql information correctly including the name of the user, database, and password in the script before you run it.
W
September 11th, 2007 at 15:43
Hi Waldo,
I asked this question at quillem.com and then realized that it doesn’t appear to be your site. then I found this site, so I hope it is OK to post the same query again.
I am running phpNuke 7.9 and trying to migrate to Drupal 5.2. When I run migrate.php, I get a message saying how many users and stories are in Nuke and that 1 user is in Drupal. That seems to be good news because it is connecting to the database.
When I click migrate users, I get a message like this:
Giving blank user names a default value (their login)UPDATE missionj_nuke.nuke_users set name=username where name=''
Default values set..(0 rows affected)
Transferring User Details to Drupal..
INSERT into missionj_drupal.users(uid, name, pass, mail, created, access, status, init, data) SELECT @a:= 1 + 1 + user_id, username, user_password, user_email, UNIX_TIMESTAMP(STR_TO_DATE(user_regdate, '%b %d, %Y')), user_lastvisit, 1, user_email, 'a:1:{s:5:"roles";a:1:{i:0;s:1:"2";}}' FROM missionj_nuke.nuke_users WHERE 1=1 AND username != 'anonymous' AND username != 'gfletcher'
Users could not be added.
It seems to be completing the first command, but doesn’t add the users. Any suggestions?
Thanks,
greg
September 11th, 2007 at 18:13
Greg,
can you run the last query
INSERT into missionj_drupal.users(uid, name, pass, mail, created, access, status, init, data) SELECT @a:= 1 + 1 + user_id, username, user_password, user_email, UNIX_TIMESTAMP(STR_TO_DATE(user_regdate, '%b %d, %Y')), user_lastvisit, 1, user_email, 'a:1:{s:5:"roles";a:1:{i:0;s:1:"2";}}' FROM missionj_nuke.nuke_users WHERE 1=1 AND username != 'anonymous' AND username != 'gfletcher'
in e.g. phpMyAdmin (or any other DB manager) and post here the error message MySQL will display?
September 12th, 2007 at 1:18
Thanks for the response Bogdan. I feel like I am so close to this migration (which I have wanted to do for a long time!) and feel stuck here!
So…here is the response from MySQL:
MySQL said:
#1064 – You have an error in your SQL syntax. Check the manual that corresponds to your MySQL server version for the right syntax to use near ‘(user_regdate, ‘%b %d, %Y’)), user_lastvisit, 1, user_email, ‘a
Hope it means something to you. My php skill is pretty slim!
Greg
September 12th, 2007 at 6:31
I just had a long Skype chat session with my server admin. He discovered that the issue was related to his version of phpMyAdmin. The server reported having 4.1 and actually had 4.0 installed. When he upgraded, all was well. Apparently, the (STR_TO_DATE string is not supported until 4.1.1 or something. Anyway, I have fully migrated now. Thanks for your help!
Greg
September 12th, 2007 at 7:19
Greg,
yes, MySQL version 4.1.1 is required. I updated the description to include this information.
I’m glad you migrated, and thanks for reporting your experience!
November 26th, 2007 at 16:48
I’m getting some problems with 0.02 version. In a local server, I cannot run the script (I get MySQL connection failure). In a remote server, I’m getting problems converting fora and stories:
Stories: MySQL Error: Max ID for vocabulary_vid could not be retrieved
Fora: MySQL Error: Max ID for term_data_tid could not be retrieved
Any suggestion, please?
November 26th, 2007 at 19:53
Marc,
if you get MySQL connection failure on local server – then please double-check host, username and password you need to use.
as for the second problem – to diagnose the exact cause, try this:
1. in migrate.php, find “function get_max_id($field)”
2. in that function you found, just after this line:
failure(“MySQL Error: Max ID for $field could not be retrieved”);
insert these two lines:
echo ” Query used to get the Max ID: $query; \n”;
echo ” Error returned by MySQL: (” . mysql_errno() . “) ” . mysql_error() . ” \n”;
3. run the migrate.php script again – either for stories or fora. This time, you will get the exact MySQL query which causes the error. You should also get the “Error returned by MySQL” followed by the error message, which you should post back here for further assistance.
4. if you got the MySQL query displayed, but nothing meaningful shown after “Error returned by MySQL”, then copy-paste the query into your phpMyAdmin (or mysql command line), run it, and post here the error message you get.
After you get the exact error message from MySQL and post it here, it might be possible to identify what is the exact problem in your case.
December 6th, 2007 at 5:02
I am seeing a similar error and did as you said with putting the debug lines…here’s the query I have that when I run returns no rows:
SELECT id FROM drupal_site.sequences WHERE name=’vocabulary_vid’;
December 6th, 2007 at 5:15
Okay, never mind that last post. I found this post http://baheyeldin.com/drupal/moving-a-drupal-install-from-a-prefixed-database-to-a-non-prefixed-one.html
That had the scripts I needed to run:
delete from sequences;
insert into sequences values (‘users_uid’, 7);
insert into sequences values (‘node_nid’, 403);
insert into sequences values (‘vocabulary_vid’, 1);
insert into sequences values (‘term_data_tid’, 57);
insert into sequences values (‘filter_formats_format’, 3);
insert into sequences values (‘menu_mid’, 136);
insert into sequences values (‘banner’, 2);
insert into sequences values (‘files_fid’, 1);
insert into sequences values (‘comments_cid’, 1);
Now onto my Fora error:
Migrating Fora:
MySQL Error: vid for Forums could not be retrieved
December 6th, 2007 at 5:25
Okay, just in case someone else reads this forum and has the same issues I do, be sure you set up a forum in your new drupal installation.
Once I created a forum, I re-ran my migrate.php for the FORA and it worked.
thx
December 6th, 2007 at 11:09
MrT,
glad you figured out the reason. I’ll add a notice to the post text, which hints at installing forum in Drupal before migrating forum entries from phpnuke.
January 13th, 2008 at 0:23
I posted a bit of extra code w/explanation here for migrating web links from phpnuke to drupal, but as it requires CCK, CCK link field, and (optionally) taxonomy to migrate the link categories, I never included it in the script itself.
Still maybe someone will find it useful.
W
January 27th, 2008 at 20:03
Hello,
I’m stuck at first step: I get this error: “Connection to MySQL could not be made. Edit this file and make sure that the database settings are correct.”
I have edited migration.php file and filled
$host $username $password $nuke $drupal
with correct values (tried several times and copy-pasted original info into it.
But it doesn’t seem to work. I’m doing something wrong, but I’m not sure about it.
Both databases are under the same sql host…
Any help will be much appreciated
Thanks
January 27th, 2008 at 20:07
I forgot to mention that I donwloaded this file: http://bogdan.org.ua/wp-content/uploads/2007/08/phpnuke2drupal-5.x-0.02-w.zip despite it displays on screen:
Version: 5.x-0.01-W
January 28th, 2008 at 8:18
Carlos,
if the script can’t connect to DB, then most likely it’s either wrong configuration or MySQL malfunction or inability to reach MySQL server from the script’s location.
You can try to download the just-made 0.03 version, which has some extra debug messages, including the MySQL connection code – so it might point out the exact reason. Also, check if there are no extra surrounding spaces in hostname/username/password. Finally, you can contact me and send the chunk of code from the script with connection configuration (i.e. host/user/pass), I’ll try to check if those really work.
January 28th, 2008 at 22:51
Dear Bogdan,
Thanks for your replies and speed.
I have uploaded the 003 version at the database connection is made correctly, but unfortunately I’m stuck at second step and I get this error:
Migrating users:
Giving blank user names a default value (their login)
UPDATE plusarquitectura.nuke_users set name=username where name=”
Default values set..(3621 rows affected)
Notice: Undefined property: stdClass::$theme in /home/…whatever…/includes/theme.inc on line 45
MySQL Error: Max ID for users_uid could not be retrieved
Back To Main?
Query used to get the Max ID: SELECT id FROM test_drupal.sequences WHERE name=’users_uid’ ; Error returned by MySQL: (1142) SELECT command denied to user ‘whateverusername’@'zelda.dreamhost.com’ for table ‘sequences’
What does that mean? I have a dabase with 3755 users.
Thanks again
January 28th, 2008 at 23:44
Carlos,
I’ll remove version 0.02 soon – debug messages in 0.03 do help a lot, also in your case.
“Error returned by MySQL: (1142) SELECT command denied to user ‘whateverusername’@'zelda.dreamhost.com’ for table ‘sequences’” says, what is the problem: that exact user has no privileges to SELECT data from table ‘sequences’.
I can see several reasons:
1. that user really has insufficient access rights. if you have several users for that database – try using other user, with higher privileges, or add more privileges to the user which is “denied”. if you do not manage user access rights – try asking hosting support (IF this error is repeatable)
2. that “sequences” table might have been locked by another process, or is corrupt. if corrupt – try using “repair table” command from you DBMS (I assume it’s phpmyadmin on dreamhost). if locked – try to find out which process is locking that very table, and stop it for the script to run.
3. transient database error. just retry running the script, if that’s the reason.
I think that first of all you should
- check if the “sequences” table isn’t corrupt or locked (this info is shown by phpmyadmin)
- try running this query
SELECT id FROM test_drupal.sequences WHERE name=’users_uid’
in phpmyadmin to see if it runs fine. if yes, and database user is the same in both cases – just re-run the script; if re-running doesn’t help – check access rights and also allowed hosts for access to the database. if yes, but users are different – try to write username you had success with in phpmyadmin into the script.
somewhat fuzzy-written, but I hope this’ll help.
January 29th, 2008 at 0:15
Bogdan,
No way…
I have repaired “sequence” table (which in addition seems to be empty) and have checked permissions for that user (it has all privileges, including “select”). I have also tried yo do your query and got a #1142 – SELECT command denied to user
Any idea?
January 29th, 2008 at 0:17
PS: I forgot to say that I can’t go any further with the script
January 29th, 2008 at 5:24
Where can I find an instruction set on how to properly do the migration? Package only has the
script.
Also, I am running, RaveNuke 2.10.01 which is Nuke 7.6 with tons of security patches. Most of
the database is same as core 7.6. Do I have to downgrade nuke to an earlier version to make
this script work?
January 30th, 2008 at 8:33
Carlos,
did you fully install that drupal? “sequence” table shouldn’t be empty after drupal installation is complete. Check if you can login into your new drupal installation.
If installation is complete, you can login into drupal, but sequence table is empty – I’d suggest consulting drupal forums on how to restore the “sequence” table manually (or just re-install drupal, I think you have it fresh and empty, so nothing to lose).
one more tedious way (unlike fast drupal reinstall) – if “sequence” isn’t empty, but you get the same error when trying to run that query in phpmyadmin – then I suspect something’s might be wrong with that table anyway. can you export that table (structure + data, and set “DROP TABLE IF EXIST”), and then re-import (destroying the previous table)? (BUT FIRST, be sure to have complete database backup, if there’s valuable info in there.) That might help, if I’m right and something’s really wrong with that table.
Ssace:
to the best of my knowledge, there is no such a thing yet as instructions/manual for the script. there are however several posts here and there, describing how it is supposed to work. check the links to drupal and quillem.com from the post text.
As for the RaveNuke: I have no idea, sorry. Try asking RaveNuke people. If DB structure (and use pattern) is the same, then script should work for RaveNuke.
January 30th, 2008 at 17:43
Bogdan,
I realized that I was looking into a different database and the script was pointing to the wrong database. I have corrected it now and I get this error:
Giving blank user names a default value (their login)
UPDATE nukedatabase.nuke_users set name=username where name=”
Default values set..(8 rows affected)
Transferring User Details to Drupal..
INSERT into plus_drupal.users(uid, name, pass, mail, created, access, status, init, data) SELECT @a:= 1 + 1 + user_id, username, user_password, user_email, UNIX_TIMESTAMP(STR_TO_DATE(user_regdate, ‘%b %d, %Y’)), user_lastvisit, 1, user_email, ‘a:1:{s:5:”roles”;a:1:{i:0;s:1:”2″;}}’ FROM nukedatabase.nuke_users WHERE 1=1 AND username != ‘anonymous’ AND username != ‘admin’ AND username != ‘carlos’
Users could not be added.
What’s the problem?
January 30th, 2008 at 18:37
what’s you mysql version? should be >= 4.1.1 for script to work.
if that is true – try running the query shown (“INSERT…”) in phpmyadmin, then post back error message you get.
January 30th, 2008 at 18:48
Bogdan,
Thanks for being in touch. That’s what I got:
ERROR: C1 C2 LEN: 198 199 1355
STR: �
SVN: $Id: sqlparser.lib.php 10432 2007-06-11 17:00:56Z lem9 $
MySQL: 5.0.24a-standard-log
USR OS, AGENT, VER: Win MOZILLA 5.0
PMA: 2.11.2.1
PHP VER,OS: 4.4.7 Linux
LANG: ca-utf-8
SQL: INSERT into plus_drupal.users(uid, name, pass, mail, created, access, status, init, data) SELECT @a:= 1 + 1 + user_id, username, user_password, user_email, UNIX_TIMESTAMP(STR_TO_DATE(user_regdate, ‘%b %d, %Y’)), user_lastvisit, 1, user_email, ‘a:1:{s:5:â€rolesâ€;INSERT into plus_drupal.users(uid, name, pass, mail, created, access, status, init, data) SELECT @a:= 1 + 1 + user_id, username, user_password, user_email, UNIX_TIMESTAMP(STR_TO_DATE(user_regdate, ‘%b %d, %Y’)), user_lastvisit, 1, user_email, ‘a:1:{s:5:â€rolesâ€;INSERT into plus_drupal.users(uid, name, pass, mail, created, access, status, init, data) SELECT @a:= 1 + 1 + user_id, username, user_password, user_email, UNIX_TIMESTAMP(STR_TO_DATE(user_regdate, ‘%b %d, %Y’)), user_lastvisit, 1, user_email, ‘a:1:{s:5:â€rolesâ€;INSERT into plus_drupal.users(uid, name, pass, mail, created, access, status, init, data) SELECT @a:= 1 + 1 + user_id, username, user_password, user_email, UNIX_TIMESTAMP(STR_TO_DATE(user_regdate, ‘%b %d, %Y’)), user_lastvisit, 1, user_email, ‘a:1:{s:5:â€rolesâ€;INSERT into plus_drupal.users(uid, name, pass, mail, created, access, status, init, data) SELECT @a:= 1 + 1 + user_id, username, user_password, user_email, UNIX_TIMESTAMP(STR_TO_DATE(user_regdate, ‘%b %d, %Y’)), user_lastvisit, 1, user_email, ‘a:1:{s:5:â€rolesâ€;
—-FI DEL BOLCAT—-
crida SQL: Documentaci�
INSERT into plus_drupal.users(uid, name, pass, mail, created, access, status, init, data) SELECT @a:= 1 + 1 + user_id, username, user_password, user_email, UNIX_TIMESTAMP(STR_TO_DATE(user_regdate, ‘%b %d, %Y’)), user_lastvisit, 1, user_email, ‘a:1:{s:5:â€rolesâ€;
MySQL diu: Documentaci�
#1064 – You have an error in your SQL syntax; check the manual that corresponds to your MySQL server version for the right syntax to use near ‘ %Y’)), user_lastvisit, 1, user_email, ‘a:1:{s:5:â€roles‒ at line 1
February 1st, 2008 at 2:03
Carlos,
something weird’s here. The query shown by the script looks OK (except for one weird double-quote):
INSERT into plus_drupal.users(uid, name, pass, mail, created, access, status, init, data) SELECT @a:= 1 + 1 + user_id, username, user_password, user_email, UNIX_TIMESTAMP(STR_TO_DATE(user_regdate, ‘%b %d, %Y’)), user_lastvisit, 1, user_email, ‘a:1:{s:5:”roles”;a:1:{i:0;s:1:”2″;}}’ FROM nukedatabase.nuke_users WHERE 1=1 AND username != ‘anonymous’ AND username != ‘admin’ AND username != ‘carlos’
but queries from your phpmyadmin are truncated.
Script’s code has correct quotes, it’s just the query you pasted into comment somehow has wrong enclosing quote after 2 in {i:0;s:1;”2″;} (I wonder how could that happen?).
Also, you seem to have pasted incomplete query into phpmyadmin, so that output doesn’t really help at all.
I’ll send you via email the new migrate.php which has additional debug message in user-migration part of code – just run that script to see the error and paste the error here.
February 1st, 2008 at 22:58
Bogdan,
Thank you once more for your help, I am really sorry to give you so many “bad news”. That’s the error that I get now:
Migrating users:
Giving blank user names a default value (their login)
UPDATE databasename.nuke_users set name=username where name=”
Default values set..(0 rows affected)
Transferring User Details to Drupal..
Users could not be added…
Back To Main?
Query used to add users: INSERT into drupal_database.users(uid, name, pass, mail, created, access, status, init, data) SELECT @a:= 1 + 1 + user_id, username, user_password, user_email, UNIX_TIMESTAMP(STR_TO_DATE(user_regdate, ‘%b %d, %Y’)), user_lastvisit, 1, user_email, ‘a:1:{s:5:”roles”;a:1:{i:0;s:1:”2″;}}’ FROM plusarquitectura.nuke_users WHERE 1=1 AND username != ‘anonymous’ AND username != ‘admin’ AND username != ‘carlos’ AND username != ‘anonimo’ ; Error returned by MySQL: (1062) Duplicate entry ‘dmainardi’ for key 2
February 7th, 2008 at 0:14
I have solved some of the problems thanks to Bogdan’s Help.
As for the previous question about duplicate keys: It was due to some duplicate users at nuke’s database. There were several of them, and after deleting them all the script worked perfectly and imported all the users. But…
I got a new problem related to registration date. All users are said to be registered on my website 38 years ago (even though my website didn’t exist!) It seems that there’s something to do with de registry date at my nuke’s database which I haven’t been able to solve, even though Bogdan told me to check this website: http://dev.mysql.com/doc/refman/5.0/en/date-and-time-functions.html#function_from-unixtime Unfortunately my programming knowledge is below zero and I am not able to understand what am I supposed to do.
I also got another problem when importing forums. I got this message error:
Migrating Fora:
MySQL Error: vid for Forums could not be retrieved
Back To Main?
Query used to get vid for Forums: SELECT vid FROM plus_drupal.vocabulary where name=’Forums’ ; Error returned by MySQL: (0)
The cause was simple: I am not using an English version and the word for “Forums” is different, so the query didn’t work. The’re several solutions: 1) change language and turn into English (you may change it later), 2) change the vocabulary value for “Forums” 3)edit the script and change the word “Forums” for the word in your language.
And I got more problems with importing forums. Those are related to non-English language: All forums’ posts are split on every accent or non-english character. Let’s say I got a post like: “This façade is green”, the importer would import only This fa. I tried to edit the content but there’s no more text on it, it simply dissappeared.
I have checked my MySQL client version: 5.0.16 and I realized that nuke’s database tables are collated as “latin1_swedish_ci” and drupal’s are collated “utf8_general_ci”. I’d like to keep utf8_general_ci, but I don’t know how to change collation… (Would it work if I simply changed on a per-table basis their collation at phpmyadmin? Is there any other better and/or faster way to do that?)
And one last problem, this time is regarding text format. Even though I edited Input Format to accept Full HTML + BB Code, all stories are displayed in plain text (no format is displayed unless I edit them one by one and turn full html on). The same happens with forum posts.
That’s my experience with this script till now. I am close to get a full migration, but as you see there’re some problems to fix…
I would like to thank publicly Bogdan: he’s been very kind and effective in answering my questions.
February 7th, 2008 at 0:41
I have re-read Bogdan’s instructions and have solved registration date:
I edited line 552 with this values:
$query .= “SELECT @a:= $maxuid + 1 + user_id, username, user_password, user_email, UNIX_TIMESTAMP(FROM_UNIXTIME(user_regdate)), user_lastvisit, 1, user_email, ‘$role_string’ “;
It worked perfectly with that modification.
There’re only two problems to solve in order to make a perfect migration:
1. Importing posts with non-English characters (extremely important)
2. Formatting nodes correctly (moderate)
February 7th, 2008 at 8:44
Carlos, thank you for sharing your experience.
Actually, sorry for giving unclear advice on user_regdate: I didn’t look at the date format which is used in the drupal database, and now that you have that comment I understand that drupal uses the same format as your nuke variation for regdate, thus this query would work perfectly (simply without any MySQL function applied to user_regdate):
$query .= “SELECT @a:= $maxuid + 1 + user_id, username, user_password, user_email, user_regdate, user_lastvisit, 1, user_email, ‘$role_string’ “;About BBCode/HTML: I found this fragment in the script (yes, I know it’s in the “do not edit below this line” section):
//Story HTML format -
//1 = Filtered HTML 2 = PHP Allowed 3 = All HTML (3 - recommended)
// note: Be sure you turn on the BBCode module for $forum_format, whichever type you choose.
$format = 1;
$forum_format=1;
$poll_format=0;
I think that changing $format and $forum_format to be 3 (All HTML) might make all posts HTMLed on import. Also, I found this line in the script:
which may help, if BBCode module isn’t yet installed.
There are even more details on BBCode:
As I found out
, the script actually contains even some info on the collations used in MySQL:
It’s strange that you have that symbols problem with MySQL5, but even so, it’s good you have MySQL5 and not MySQL4.
I suspect that the following might work:
- go to your original nuke database (using phpmyadmin)
- export the whole database to file (there’s an option at the bottom of the page – like “Save to file”); if export page provides a choice of file encoding – then check if encoding is set to utf-8 (it should be by default)
- open that file in something like Notepad or any other plain-text editor (using smth like Word is not recommended, but if you do use MS Word, make sure you save the .sql file as a text file, not a Word document; I was told that Notepad2 is good, but I never tried); then use Edit->Search-and-replace menu of the editor to replace all occurrences of latin1_swedish_ci into utf8_general_ci; save the file when done
- create a new empty database (e.g. ‘nuke2′) with collation set to utf8-general-ci; this will be the new database to use as the source of nuke2drupal migration
- go to the “Import” tab in that new database (nuke2), and use the edited file to import all tables into ‘nuke2′; again, if there’s an option for “file encoding”, check if it’s the same as used for exporting (utf8).
That might do the trick.
Or you can create a duplicate of your current nuke DB (again, let the copy be ‘nuke2′), and then set the collations for all tables to utf8_general_ci… but that might not help, as in MySQL not only every table, but also every text field in the table has its collation, and manually changing all that would take longer than doing backup-edit-restore as described above.
There’s also lot of techincal info here, but I hope you don’t need to read and understand that
.
February 10th, 2008 at 1:20
My nuke based site now is RaveNuke 2.10.01 which is basically PhpNuke 7.6 with tons of security
fixes. The core tables are the same as PhpNuke 7.6.
I have Drupal 5.6 installed with Forum, Polls, BBcode, & Smilies enabled. I have created all
the forum containers to match my nuke site.
A few questions:
Is it a strict requirement to convert nuke 6.5 to drupal 5.2. Or will nuke 7.6 to drupal 5.6
work with this .03 script? Also, are there any other drupal modules I should enable/install
before trying to migrate. Ultimately I want to install Flatforum in Drupal to jazz up the forum.
Should I wait until after migration to install Flatforum?
Thanks
February 10th, 2008 at 3:23
I just tried the migration script and got this in first step:
Giving blank user names a default value (their login)
UPDATE nuke.nuke_users set name=username where name=”
Default values could not be set
February 10th, 2008 at 10:48
Ssace,
drupal 5.2 should be fine, but Nuke 7.6 instead of 6.5 sounds too far, so might not work at the Nuke end.
Only the modules specifically mentioned by the migrate script are needed; also, search the comments for ‘bbcode’ for more info on modules and enabling HTML/BBCode in migrated posts.
I do not know what Flatforum is; but if it is built on-top of drupal’s Forum, then you should first migrate; if, otherwise, it does not need drupal’s Forum module to function, then most probably the migration script will need to be updated to import posts into Flatforum.
The error you got tells that you haven’t edited the scrip to input correct database connection values, OR that your Nuke DB is different from what the script expects. Check if host/database/username/password are correct for nuke DB (in the migrate.php script); if they are – then check the nuke_users table in the nuke database to see if it has both ‘username’ and ‘name’ fields.
February 10th, 2008 at 16:17
Yes, my nuke DB has both ‘username’ and ‘name’ fields. However, the name field is blank.
Nuke 6.5 comes stock with both fields.
February 11th, 2008 at 12:26
Then I don’t know what’s the problem. Try running this query:
UPDATE nuke.nuke_users set name=username where name=”
on your nuke DB in smth like phpmyadmin and see if you get an error message.
February 17th, 2008 at 1:09
Bogdan, I tried again with editing the sql file and replacing all instances of latin1 for utf and it seems that it worked: when I enter to phpmyadmin and check the altered nuke’s database, all the tables are shown as utf-8 instead of latin1 which is good.
I uploaded that database and run the migration script, but the problem persist: all the imported posts are stopped just after any non-english character.
any idea?
February 19th, 2008 at 10:15
Carlos,
I’m out of ideas on this one, sorry. Try asking VValdo, or in some support/expert systems. I never had this kind of problem, and cannot quite imagine what would be the cause.
Well, the cause might be that your query is prematurely terminated due to some reason… one of the reasons would be the presence of the “string termination sign” – like a single quote, or a double quote – but you don’t have those around every accented character.
Another highly unlikely explanation I still can imagine is that “connection collation” isn’t utf8. But that’s highly unlikely.
February 19th, 2008 at 11:35
I have a problem convert data from UTF8 to UTF8 using your script. Then, I found a solution from this website Script to Migrate PHPNuke to Drupal – UTF8 to UTF8
They use your script but with 2 more lines of code and it works!!
February 19th, 2008 at 17:21
Yes, that’s what I’m talking about in my comment #43 – “connection collation isn’t utf8″. Now, when I see that it did help, I’ll add those two lines to the script, and shall post version 0.04 here in a few minutes.
Carlos, if that wasn’t your post on bxtra.net
, then you may want to try the 0.04 version as soon as I put it here. It might help with your “incomplete import on accented characters” problem.
February 19th, 2008 at 17:36
Ha ha ha ha, no, Bogdan, it wasn’t me, promise! But I have read it and that may be the solution to my problem! I’m willing to arrive home and test it. Hope that will work.
In case it didn’t I will try one last thing: search and replace all instances of “á” for &aaccute ; (without space) and so on, if it didn’t work neither, I will delete all accents and non-english characters. It won’t be correct, but it will be easier to understand a text without those characters than being able to understand a text that has been split at the very first character, for example
I would like to ask another question as well (Sorry Bogdan
-I’m sure that after I have migrated my site you’ll be happier than me! ): I have plenty of things to do to accomplish the migration, not only migrating users, posts and news… I have to set up some other modules, taxonomies, write some new pages (FAQs)… this work will take me some time to accomplish, but the script says that the importing should be the first thing to do. If I import users and post, for example, and then I start to do the other tasks, that means either one of these things:
-I have to have my site down for maintenance as long as I finish all the tasks, to avoid the following situation:
-If I don’t turn off my phpnuke, new content and/or users would be lost at drupal’s (remember that I had already run migration script)
Is there any solution to this situation? would it break in case I sign up all categories, sections, pages… and then run the script on the last instance to minimize my site’s downtime?
maybe using two separate installations of drupal? How prevent from overwriting information?
Thanks!
PS: I think I’m near to accomplish the migration. I’m really willing to do it!
PS2: would that script work for 6.x version for Drupal?
February 19th, 2008 at 17:39
by the way: thanks Ty for providing that information.
February 19th, 2008 at 18:17
Yes, thanks Ty, that was useful.
Carlos,
will it be possible for you to minimize downtime by switching from nuke to drupal as soon as all the users and posts and forums are migrated? this way you won’t have all the functionality you need, but maybe that isn’t really bad? Then, your drupal becomes “minimally functional”, with all new content going into it and not into nuke; meanwhile, you’ll be adding all the extra features you need.
The script may work with no problem for the existing installation, it’s just that I never heard/read of someone doing migration onto the “live” drupal – so basically it isn’t really known if it will work OK or if it will fail.
In order to minimize downtime it would be best (in my opinion) to write a custom migrate-configure script, which will do _everything_ needed to convert the original nuke DB into a fully functional Drupal installation. Downtime then will be limited to the time needed to run that script. However, this approach is time-consuming and requires either certain programming skills, or extra money to pay for this one-use script.
So if it’s possible in your case – then just do the basic migration, then lock nuke – launch drupal, and then add features as fast as you can, while your drupal is “half-functional”. If this scenario is possible in your case, of course
P.S. (2): with some modifications – definitely yes; without any modifications – I don’t know, someone needs to try
. Also: I’m quite sure it’s possible to migrate to Drupal 5.7, and then just upgrade to Drupal 6 
.
P.P.S.: WOW! release notes of Drupal 6 look just marvelous! Drupal 6 looks like the best-of-bread beast in the CMS family, now even more than before! It’s only that I find it a little bit more complicated to start with than others; but once learned the idea – it’s a power!
February 20th, 2008 at 1:28
Wow, I haven’t been here for a while, and look at all the progress people are making lately!
Cool new patches, new versions.. good times!
Anyway, I wanted to let everyone know that I finally got around to uploading my old code that migrates the Reviews too.
https://drupal.org/node/202528#comment-724422
as with the Web Links code mentioned above (at http://drupal.org/node/202528#comment-689245) you need CCK and the CCK Links field module…
If someone has the time, it might be cool to make a new version of the script that includes this code. It wouldn’t be hard to do at all really.. I’ve provided all the migration code.. it would just be a matter of packaging it up so it 1. auto-detects that the modules are there and working right, 2. if so, auto-imports the CCK content type, and then 3. run the migration to pull in the web links and the reviews.
Any takers?
W
February 20th, 2008 at 11:21
Hi VValdo, glad to hear from you again!
First I thought that using some “CCK module” isn’t a good idea to incorporate into the (basically universal) script, but after reading this paragraph in the Drupal newsletter I changed my mind:
So the general trend will be to move CCK into the core. Thus it’s perfectly fine to rely on this module.
If no one takes this before weekend, maybe I’ll glue your code into the script.
“New versions” – these are really just minor improvements
. But I still have to push the version up, so that there is no “one version – different files” confusion.
February 20th, 2008 at 23:48
At last! it worked! I have been able to import forum posts pefectly despite having non-english characters. It worked adding only those two lines mentioned here: http://www.bxtra.net/articles/2008-02-15/Script-Migrate-PHPNuke-Drupal-UTF8-UTF8
Thanks to everyone, most especially to Bogdan who has proven that apart from having a good knowledge has a lot of patiente and likes helping people. Thank you very much, Bogdan.
February 21st, 2008 at 10:25
Carlos–
AWESOME! Congratulations!!! It’s seriously great to see that the code is working for others!
Bogdan–
Yes, the two modules “CCK” and “Views” are absolute necessities for any installation of Drupal, in my opinion. They are the two pillars that make Drupal really excel. They are more than mere modules
In any event, you can always do a little auto-detection to check to see if they are installed before offering those last steps. I did something like this to check if the php “tidy” extension was installed before using it to clean up the text.
In this case, by using the drupal API, you could say:
if module_exists(“cck”) { insert all my code } else {echo “CCK not available.”;}
Among my code is the CCK import for a content type. I’m not sure exactly how to get CCK to do the import via code as opposed to the user interface. It might be worth asking on the CCK forum. It may be as simple as using drupal_execute(), but I’m not 100% sure about how to import CCK stuff without using a browser.
Finally– I wonder how well (or if) the code would work with Drupal 6? Assuming the API remains relatively constant, most of my code might still work, although the non-API stuff written by others before I made my changes may not. Would be an interesting experiment..
February 21st, 2008 at 10:32
I should also point out this point in the code:
$config = array(
'logical-emphasis' => true,
'DocType' => 'omit',
'drop-empty-paras' => false,
'indent' => true,
'wrap' => 0,
'output-html' => true,
'char-encoding' => 'utf8',
'input-encoding' => 'latin1', // change as necessary. most older mysql DBs are latin1
'output-encoding' => 'utf8',
'hide-endtags' => true,
'replace-color' => true,
'show-body-only' => true);
notice that when “tidy” cleans, it assumes certain encodings. UTF8 people may want to change this…
W
March 2nd, 2008 at 15:06
Hi Bogdan,
Carlos’ back
I am migrating another phpnuke website -the second and the last one, promise 
– and I get this error when importing stories:
Migrating story Categories:
MySQL Error: Max ID for vocabulary_vid could not be retrieved
Back To Main?
Query used to get the Max ID: SELECT id FROM asf_drupal.sequences WHERE name=’vocabulary_vid’ ; Error returned by MySQL: (0)
I have read that another user had the same problem and you told him to add two lines which are already added at my file. I get the qery, which is empty at drupal’s database, but I don’t know what to do with it.
Thanks
March 3rd, 2008 at 7:18
Try adding One “Vocabulary” and also One “Term” and see if it works or not.
March 9th, 2008 at 22:56
Or just create a forum.
W
June 5th, 2008 at 11:57
Hi Waldo,
i’m trying to migrate from Nuke 6.0 to Drupal 6. Is it possible, with this script and a detour over drupal 5.7, to manage this?
for now, i get the following error:
Migrating users:Giving blank user names a default value (their login)
UPDATE testa.ecolode_users set name=username where name=''
Default values could not be set
June 7th, 2008 at 8:43
Nilsja,
you could just remove that line (starting with UPDATE and with set name=username where name=” substring) from the migration script, to see which error you might get next, and how to fix that next error.
This one – Default values cannot be set – isn’t IMO critical, you can safely skip that.
I only wonder why would this error pop up at all on such a simple query… have no idea yet.
August 15th, 2008 at 1:31
No new version for Nuke 7.X to Drupal 6.X?
Thx
August 15th, 2008 at 15:21
Maniaka,
no new version. If you are willing to create such a version, I’ll do my best to help you. Also, if you could come up with the list of changes necessary to make the current script work for nuke7-2-drupal6 conversion, I might modify the script appropriately for you to test.
November 10th, 2008 at 15:17
G’day, I’m another PHPNuke user (8.1) looking to make the leap to Drupal 6.x. If someone is successfully able to make the migration work on their own site, I’d love to know how you did it.
cheers,
David.
November 11th, 2008 at 14:56
Disregard my previous post.. I did an install of Drupal 5.12, and the conversion worked! I had an error that the users could not be imported, but found that they had been brought into the system. I then changed the url to =stories to move to the second step.
cheers,
David.
October 20th, 2009 at 11:27
Hi I’m trying to use the migrate.php script to leave phpnuke and move everything (almost) in Drupal 6.14, when I run the script it says Query used to get the Max ID: SELECT id FROM xxxx.sequences WHERE name=’users_uid’ ; Error returned by MySQL: (1146) Table ‘xxxx.sequences’ doesn’t exist I’ve seen that this table doesn’t exist anymore in version later than 6…..
How can I do?
Thanks
October 20th, 2009 at 12:08
You have 3 options:
- migrate to Drupal 5 first, then upgrade to Drupal 6
- modify the script
- solution #3 (at the very bottom of this comment)
To modify the script, you will only need to know this:
http://drupal.org/node/114774#db_last_insert_id
It is clear that set_max_id() function is now obsolete, and get_max_id() will have to be modified (I believe one could either call Drupal’s db_last_insert_id(), or just SELECT the ID column, ORDERED BY ID DESC).
Alternatively, you can manually create the “sequences” table in your Drupal 6 database (preserving the structure it had in Drupal 5), run the import (if there are no other errors), then just delete the sequences table you created.
October 20th, 2009 at 12:27
Thanks for the quick answer. I think the easiest way for me is create the table and then delete it, but…..
Can you tell me the structure of the table sequences?? Sorry but I’m new for Drupal….
October 20th, 2009 at 12:57
Here’s what I have:
CREATE TABLE IF NOT EXISTS `sequences` (
`name` varchar(255) NOT NULL default ”,
`id` int(10) unsigned NOT NULL default ’0′,
PRIMARY KEY (`name`)
) ENGINE=MyISAM DEFAULT CHARSET=utf8;
–
– Dumping data for table `sequences`
–
INSERT INTO `sequences` (`name`, `id`) VALUES
(‘menu_mid’, 140),
(‘users_uid’, 84),
(‘vocabulary_vid’, 2),
(‘node_nid’, 265),
(‘node_revisions_vid’, 265),
(‘i18n_node_trid’, 4),
(‘aggregator_category_cid’, 5),
(‘aggregator_feed_fid’, 15),
(‘aggregator_item_iid’, 1697853),
(‘comments_cid’, 440),
(‘term_data_tid’, 24),
(‘i18n_blocks_delta’, 1);
I’m not sure if you have to pre-populate the table with some values, but it won’t hurt if you do – just set all the values to whatever is the maximum of the mentioned ID.
October 20th, 2009 at 14:41
Thanks!!! It worked (for users) I’m trying to understand what’s was wrong with stories and forum….
Bye and thanks again!
November 2nd, 2009 at 0:20
Hey– if/when you do get it working for d6, can you post your modified script for more people to use?
Send to Bogdan and/or post here:
https://drupal.org/node/498
Thx!
W
December 15th, 2009 at 22:37
Hey Bogdan and/or Waldo
I’m making my first migration from Nuke 7.5 to drupal 5 and hopefully next to 6 from there.
I love the migrate script and it seems to be very handy. My main object is to move the users and articles/stories.
The problem I’m having is with the database connections. Your script assumes that there is only one MySql host username and password for both nuke and drupal. However my domain host has my drupal and nuke databases with different user names and passwords. I attempted to add the same users and passwords in each but when I create new users I’m not given permission to specify the username and when I attempt to change the password I get massive errors.
The script is able to connect to the nuke database but the drupal database being seperate is the issue.
My next option is to change the migrate code to reflect the two different databases and their respective usernames. I think I have a general idea just by reading the code but if you can instruct me as to what areas need to have what changed so I don’t miss anything it would be greatly appreciated.
Thank You.
Zmeharen
December 15th, 2009 at 22:54
This should be easy.
First, in addition to these:
add something like
It might be nice to rename $host and company into $host_nuke, …
Then, around lines 268-282, modify the code to connect to 2 databases, and store an extra database link in e.g. $link_drupal variable.
After that, you will have to look for each and every MySQL $query to modify it, so that is uses either $link[_nuke] or $link_drupal.
I’m not doing that myself, as I am currently very badly pressed for time, and wouldn’t be able to test the modified version anyway. However, feel free to ask if you encounter any problems while modifying the script.
Also, please do not forget to share your final working version.
December 15th, 2009 at 23:57
Thanks for the quick reply Bogden,
Thats exactly the approach i made. I was easily able to find all insert and update queries to adjust to the drupal database. Where do I post my final working version?
I think I’ve done all I could now I’m still stuck at the beginning and I’m not sure why.
Here’s what the script has done and the error I recieved.
Giving blank user names a default value (their login)
UPDATE d*******1.nuke_users set name=username where name=”
Default values set..(1 rows affected)
MySQL Error: Max ID for users_uid could not be retrieved
Back To Main?
Query used to get the Max ID: SELECT id FROM d*******7.sequences WHERE name=’users_uid’ ; Error returned by MySQL: (0)
I’ve placed the *** for the database names for safety.
Here is the code I’ve changed in the get_max_id function:
function get_max_id($field)
{
//message("Getting Max ID for $field");
$d_sequences = $GLOBALS["d_sequences"];
$query = "SELECT id FROM $d_sequences WHERE name='$field'";
$result = mysql_query($query, $link_drupal);
if ($row = mysql_fetch_object($result))
{
//success("Max ID for $field retrieved!");
return($row->id);
}
else
{
failure("MySQL Error: Max ID for $field could not be retrieved");
echo " Query used to get the Max ID: $query ; \n";
echo " Error returned by MySQL: (" . mysql_errno() . ") " . mysql_error() . " \n";
exit();
}
}
As you can see i’ve changed the $link to $link_drupal.
December 16th, 2009 at 0:16
You can send the updated script to me at webmaster _at_ bogdan.org.ua, I’ll post it here within a few days.
Your problem is similar to what is discussed in comments 65-68 on this page. This shouldn’t be happening for Drupal 5. However, you could try using my suggestions in comments 65-68 (from comment 68, for users, you would only need to set sequences.users_uid to whatever is the maximum or maximum+1 of the users table).
December 19th, 2009 at 9:10
Hey Bogdan,
Still working on the script.
I was able to figure out the solution to my previous problem, since I created another connection to the drupal database outside the function I had to declare the global database link in the function. I added this in all areas that the global d_sequences was declared.
I am now able to get the max id at least for users, but I think this should work for the other areas of the code too.
The second problem that I’m running into is copying the Nuke users and moving them to the Drupal database. Initially in the script this was done with a single INSERT … SELECT query. This is doable in the script if you have the same username and password for both databases. This was not going to work with me however. I decided then to divide the query into two sections.
First to execute the SELECT query on the Nuke database. Then loop through the results and INSERT them individually into the drupal database.
Here is that section of the code, and this is all I have so far.
January 4th, 2010 at 0:09
I feel a little dumb by not offering the use of db_query in my comment above – that could have solved the problem Zmeharen had, and improve the script by extending the use of proper Drupal API…
Here’s an example of the proper use of db_query (with 2 substitution variables):
For SELECT, we could then proceed with e.g.
April 18th, 2010 at 12:13
FYI: I’ve created a module for drupal 6 that performs a migration using the drupal batch api. It is implemented from scratch, not based on current scripts and is easily customizable/extendable if you know php.
https://drupal.org/project/phpnuke2drupal
April 18th, 2010 at 20:01
Thanks for the info, I’ve added the link to the module page to the top of the post.
November 9th, 2013 at 15:57
Sorry for the recent comment spam. I’ve enabled moderation for *all* comments now, so garbage from spam-idiots should no longer make it through.
November 10th, 2013 at 14:42
Thanks Bogdan for stopping the large amount of spam messages arriving to our mailboxes. I have to say, however, that this time receiving spam has proved to be good, because it has made me come back here after so many years. You may like to know that thanks to your script and patient guidelins I managed to migrate from nuke to drupal, and since then I’ve been a drupal user myself and I’ve been learning a lot (in fact now I am ashamed of some of the comments I made so long ago). Currently I have developed some interesting drupal sites and lately I started working as drupal developer working at Ymbra a drupal-based company. So, in all, I wanted to thank you again for your work, without that it’s very likely that my present would be really different from what it is today. Hope you are doing fine as well.
Best,
Carlos
November 10th, 2013 at 18:06
Hi Carlos,
I’m definitely glad to know that this blog post back from 2006 helped you achieve the state of life you seem to like/enjoy
Sharing this feedback was very kind of you – thanks!
Yes, I’m fine, too. I had somewhat departed from [professional] web-development, including Drupal… I’m moving towards higher involvement into various data analysis projects. Right now I’m a “microbial bioinformatician”
Within the next few weeks I’ll need to develop a web-interface to one of the tools I’ve developed, but since my favourite language is Python, I’ll most probably do that using Django. It will be interesting to see how different Django and Drupal are from the developer’s viewpoint…
Best wishes,
Bogdan