copy/paste from vanilla/vanilla#1546
Hi people,
so I've got this wonderful DB/forum software combo that I've gotta transfer to Vanilla 2.x. MySQL 5.5.23-55 with PHPBB 2.0.6 (yeah, don't say anything, I know). I see no point in upgrading to PHPBB3 because I'll dump the whole mess that is the PHPBB platform and move to something more modern and with better integration with WordPress, namely Vanilla.
And let me apologize in advance I didn't want to open 4 separate issues for this. I've already forked, and will patch some of this functionality and submit a pull request so you guys can check it out and include it in some future version of Porter.
So anyway, let's start with the DB config.
Aka Part 1.
DB collation latin1_swedish_ci
DB charset from the SELECT CHARSET('some_field');
is utf8
It's a Percona server not MYSQL per se, and it's on a shared hosting. I can remote mysql into it, which I discovered as I'm writing this so that's one plus for getting the dumps without PHPMYADMIN.
Plain old conversion via the vanilla2export.php does transfer all data specified (but not all data required, but that'll be another issue), but the Croatian characters come out mangled. This is particularly troublesome with nicknames that have characters like šćđž in them.
If you force the script to read the character set with the lines below at the very top of ForumExport function in the phpbb2 class, you do effectively nothing in this example because the script gets the charset which is utf8 anyway.
$CharacterSet = $Ex->GetCharacterSet(':_users.username');
if($CharacterSet)
$Ex->CharacterSet = $CharacterSet;
When a post with a [quote="Ašow"]...sometext...[/quote] in it transfers to Vanilla's post table and you're using the above patch, the actual quote comes out saying quote="A and that's it. That's a pretty big problem
So it's a hydra-like problem.
- the collation is wrong for the language used.
- the script doesn't connect to the DB in the default collation, it's UTF-8 or die
- the script, although it does utf8_encode as per proper PHP fashion because it doesn't check for collation of the table and checks only for charset (as far as I can see) it doesn't output the proper character set :/ Or better said, it outputs the right data but in the wrong character map.
But that's solvable (I hope) with some iconv and mysql magic, and isn't really needed in the script, for someone who has prior knowledge in PHP&MYSQL UTF-8 problems.
Part 2 of the problem is the following line of code.
// Skip pending memberships
$Ex->ExportTable('UserRole', 'select user_id, group_id from :_users
union
select user_id, group_id from :_user_group where user_pending = 0', $UserRole_Map);
That's just plain wrong. There is no group_id in phpbb_users table in phpbb2, at least on the version I'm currently trying to transfer.
Either it should say:
// Skip pending memberships
$Ex->ExportTable('UserRole',
'select user_id, group_id from :_user_group where user_pending = 0', $UserRole_Map);
Or it should do a join on three tables like:
$Ex->ExportTable('UserRole',
'select u.user_id, g.group_id from :_users u
join :_user_group ug on ug.user_id = u.user_id
right join :_groups g on ug.group_id = g.group_id
where ug.user_pending = 0',
$UserRole_Map);
Both examples have the exactly same effect. That'll be upped later on my fork, so I can submit a pull request for it.
Part 3 of the problem.
PHPBB2 forums (don't know for ver 3.) don't require assigning users to some default group. When Vanilla Porter does it's magic, large number of users (most, except for those assigned to some group like say moderators, or private forum groups), don't get assigned to any group.
From this stems two problems, users don't get assigned to some default group, and Administrators (if there are more than 1, which is normal with larger forums) except for the one specified in the import procedure, are not assigned as Administrators.
This is as I gather from the import script (which complains if users are not assigned to a group) required. Wouldn't it be better then to assign by default anons/guests to group Guest and users to group Users no matter what.
This also isn't doable without going into SQL for existing users. It's not a problem for someone who does this for a living, but for some rookie... Yeah, it could be :) It can be done with some button in the Vanilla admin dashboard, assign all existing users to ... Similar functionality exists for new users, but not for existing ones.
Part 4
No bans are imported. Either the banlist (IP, Mail, Name), or is the user banned into the user table. Is there a reason for this? I really need this functionality, and I'll implement it myself if I have to, but I wouldn't want to get, oh no, the way you that isn't compatible with .
As I've said I'll implement it myself because I need it, but can I at least have some guidelines on how the banning works. What has priority (the user table or the ban list)? Is the banlist (I'm thinking ahead right now) only in effect during the user creation and the user table field for normal operation or how it's done if not that way :)
Part 5
Just kidding, that's it (for now) :P
I'll post patches/guides for anything I can, and I hope I'll get some feedback on this TL;DR issue... Vanilla features OOB are amazing, and probably with plugins just get better and better, but first I need to get the site up and running with data displaying as intended.