[bigtreesjoe]

Why were all the users duplicated as imported_someusername? Did I do something wrong in the conversion template?
I did not see any mention of the creation of these artificial users in the documentation that exists for the import forums function, nor did the Repair Forums clean up the artificial users.
I had pruned my user database before conversion so fortunately I only had a little over 400 to go through. All of the imported_username type users had 0 posts so I was able to delete them a page at a time.
Hopefully everything will go smoothly from here on,
joe

[bigtreesjoe]

I just noticed that after doing the import from smf 1.1.8 (I made all the needed talble and field name changes, etc) that my user table now contains two versions of each imported user. One version looks right the other has a prefix of imported_ on both the usename and the email address.

Is it OK to clean out these odd ones?
thanks,
joe

[bigtreesjoe]

well, I turned on wp debug and found a simple syntax error in my file that was causing all / most of the problem.
I had included an authentication function that I think might have worked but had backed it out thinking it might have been causing the problem.

For anyone else thinking about using any of the converters, I would strongly recommend that you set WP_DEBUG to true in wp-config.php first.

[bigtreesjoe]

I have started the import using my modified version of the smf 2.xx converter file (I’m on smf 1.1.8)
The converter has been just sitting there saying “starting” for several minutes.
There isn’t that much data to go through because I pruned old messages and inactive members.
If there were some sort of error, would the importer report it?

One thing that is different is that I included the prefix in the importer file itself (like smf_boards rather than boards) and left the prefix field on the importer empty.
joe

[bigtreesjoe]

By the way, shouldn’t this:

		// User password verify class (Stored in usermeta for verifying password)
		$this->field_map[] = array(
			'to_type'      => 'members',
			'to_fieldname' => '_bbp_class',
			'default'      => 'SMF'
		);

be this instead:

// User password verify class (Stored in usermeta for verifying password)
$this->field_map[] = array(
‘to_type’ => ‘user’,
‘to_fieldname’ => ‘_bbp_class’,
‘default’ => ‘SMF’
);

[bigtreesjoe]

I had basically finished writing a converter template for smf 1.1.8 when I came across your post and your script. Good news is it looks like I got pretty close.

I would like to understand better what the authenticate_pass function is supposed to do. If it is just supposed to return true if the current user’s password matches the old smf hashed password then it seems that I should be able to use a function similar to ssi_checkPassword that was included in the SMF ssi.php script, assuming that the sha1 function is available.

Is there something more complicated that I am missing?

I realize that due to SMF licensing issues I would not be able to distribute the code I write for myself based on the ssi.php code.