port phpbb2drupal to Drupal 7

i REALLY need a this for Drupal 7. What is the likelihood?

subscribe

subscribe

subscribe

Sorry for repeating myself, but is this module likely to be made into a V7 version? Is it likely someone working on one, or is it how it looks - that no one is going to bother? If there is every likelihood of this being updated for V7, is it likely to be weeks, months, or years.

Alternatively, is it possible to convert my Drupal 7 website into a Drupal 6 one in order to implement this module (as I only need to use it once), then upgrade back to Drupal 7? I have zero code knowledge.

Importing an existing phpBB forum is essential to my project, as the client (a mate - I'm doing this as a favour), has been using a phpBB forum as his entire site for about six years. It has hundreds of members, and he wants the exiting content and the forum and it's existing members to be fully integrated with the Drupal 7 site I have created for him.

As we can't achieve the main objective of the project, it has been brought it to grinding halt. Having spent 60+ hours on the site and daily checking this issue to no avail is becoming soul-destroying.

Someone please give me some reassurance or advice!

Hi,

I would recommend you to use a fresh install of Drupal 6, then run this module* to migrate from phpBB to Drupal 6. You can even do this locally in your computer if you have a powerful one, the upgrade to Drupal 7 and you are done.

I can see at least one problem downgrading to Drupal 6 from 7 and that is the users passwords are now with a salt protection, so you might lost the ability to login back to the site after downgraded.

* make sure to follow the steps and I also recommend having multiple backups of the phpBB database

I'd also love to see this module ported to D7. I currently have a phpbb3 forum that I've run for years that I'd like to migrate to Drupal. I've tried starting with D6, going through the phpbb2drupal process, then upgrading to D7 -- and there seem to be a few issues that pop up along the way. I'm going to try it again a couple times and see if I can put together a detailed walkthrough of the process. In the meantime, it would be wonderful if the module could be updated to support D7 natively, but unfortunately I don't possess the programming knowledge to help that process along.

subscribe

A major note about this project: its a pick up and throw away sort of module where people generally only need to use it once and then never again.

I needed to use it 3 years ago so I ported it to Drupal 6.

However now it has been a long time since I have touched the code, so its not something I am looking forward to tinkering with.

The best option is if someone who has vested interests to try and port it (step 1: run it through coder.module) - you dont need much experience or php skill - I still dont have any.

Doing code update via:
http://upgrade.boombatower.com/tools/php/directories

First patch is for the coding style update for 6x/7x.

This second patch is for core API changes, etc.

Also see the attached review file.

+1

subscribe

Those two patches by Ryanbach are they for import to Drupal 7?
I have a phpBB site I would like to be imported to Drupal 7.
I am not sure what version of phpBB the client is running - at the site it say "phpBB © 2001, 2005".
Is there a file on the server that tell me the version?

Please advise and I will give it a try to see how an import would work for this and report back to here.
I only have limited coding knowledge.

Quick way to get the phpBB version number
http://www.phpbb.com/kb/article/quick-way-to-get-the-phpbb-version-number/

The above two patches are to port this module to Drupal 7. Yes, this module should import phpBB to Drupal.

I'm having trouble applying the coreapi path - the codingstyle patch went through without any problems.
But the coreapi is throwing errors.

git apply -v phpbb2drupal-6.x-2.1-coreapi.patch
Checking patch phpbb2drupal.info...
error: while searching for:
; $Id: phpbb2drupal.info,v 1.8 2008/07/09 18:51:53 nbz Exp $
name = phpBB2Drupal
description = "Migrate your phpBB data into a Drupal forum."
core = 6.x
dependencies[] = bbcode
dependencies[] = comment
dependencies[] = forum

error: patch failed: phpbb2drupal.info:1
error: phpbb2drupal.info: patch does not apply
Checking patch phpbb2drupal.install...
error: while searching for:
<?php
// $Id: phpbb2drupal.install,v 1.9 2008/02/10 01:36:37 nbz Exp $
function phpbb2drupal_schema() {
$schema['phpbb2drupal_temp_forum'] = array(
'description' => t('Maps phpBB forum forum_id to Drupal taxonomy tid.'),
'fields' => array(
'forum_id' => array('type' => 'int', 'unsigned' => TRUE, 'size' => 'small', 'not null' => TRUE, 'default' => 0, 'disp-width' => '5'),
'tid' => array('type' => 'int', 'unsigned' => TRUE, 'not null' => TRUE, 'default' => 0, 'disp-width' => '10')),

error: patch failed: phpbb2drupal.install:1
error: phpbb2drupal.install: patch does not apply
Checking patch phpbb2drupal.module...
error: while searching for:
// ; $Id: phpbb2drupal.module,v 1.107 2009/10/03 18:02:13 nbz Exp $

/**
* Implementation of hook_menu()
*/
function phpbb2drupal_menu() {
$items = array();

error: patch failed: phpbb2drupal.module:2
error: phpbb2drupal.module: patch does not apply
Checking patch phpbb2drupal.pages.inc...
Hunk #1 succeeded at 3 (offset -1 lines).
Hunk #2 succeeded at 135 (offset -1 lines).
Hunk #3 succeeded at 168 (offset -1 lines).
Hunk #4 succeeded at 217 (offset -1 lines).
Hunk #5 succeeded at 229 (offset -1 lines).
Hunk #6 succeeded at 271 (offset -1 lines).
Hunk #7 succeeded at 310 (offset -1 lines).
Hunk #8 succeeded at 348 (offset -1 lines).
Hunk #9 succeeded at 363 (offset -1 lines).
Checking patch phpbb2privatemsg.info...
error: while searching for:
; $Id: phpbb2privatemsg.info,v 1.2 2008/02/10 23:34:51 nbz Exp $
name = phpBB2Privatemsg
description = "Migrate your phpBB private messages to Drupal privatemsg."
core = 6.x
dependencies[] = privatemsg
dependencies[] = phpbb2drupal
package = phpBB to Drupal
; Information added by drupal.org packaging script on 2009-11-08
version = "6.x-2.1"
core = "6.x"
project = "phpbb2drupal"
datestamp = "1257699044"

error: patch failed: phpbb2privatemsg.info:1
error: phpbb2privatemsg.info: patch does not apply
Checking patch phpbb2privatemsg.install...
error: while searching for:
<?php
// $Id: phpbb2privatemsg.install,v 1.1 2009/05/17 02:01:56 nbz Exp $
function phpbb2privatemsg_schema() {
$schema['phpbb2privatemsg'] = array(
'description' => t('Maps phpBB forum forum_id to Drupal taxonomy tid.'),

error: patch failed: phpbb2privatemsg.install:1
error: phpbb2privatemsg.install: patch does not apply
Checking patch phpbb2privatemsg.module...
Hunk #1 succeeded at 30 (offset -1 lines).
Hunk #2 succeeded at 40 (offset -1 lines).
Hunk #3 succeeded at 62 (offset -1 lines).
Hunk #4 succeeded at 105 (offset -1 lines).
Hunk #5 succeeded at 126 (offset -1 lines).
Hunk #6 succeeded at 135 (offset -1 lines).
Checking patch phpbb_redirect.info...
error: while searching for:
; $Id: phpbb_redirect.info,v 1.2 2008/02/10 23:34:51 nbz Exp $
name = phpBB_Redirect
description = Redirects links incoming from old phpBB forum to the new Drupal forum.
core = 6.x
package = phpBB to Drupal
; Information added by drupal.org packaging script on 2009-11-08
version = "6.x-2.1"
core = "6.x"
project = "phpbb2drupal"
datestamp = "1257699044"

error: patch failed: phpbb_redirect.info:1
error: phpbb_redirect.info: patch does not apply
Checking patch phpbb_redirect.module...
Hunk #1 succeeded at 14 (offset -1 lines).
Hunk #2 succeeded at 52 (offset -1 lines).
Hunk #3 succeeded at 67 (offset -1 lines).
Hunk #4 succeeded at 76 (offset -1 lines).
Hunk #5 succeeded at 88 (offset -1 lines).
Hunk #6 succeeded at 97 (offset -1 lines).

Ryanbach,

Do you intend on publishing your D7 changes back so everyone can use them?

The current patches on this thread do not apply, presumably since the code they are based on has changed. Publishing your changes back to GIT would effectively make you the D7 maintainer of this project, so I'd understand if you don't want to do it.

I'm in the same boat as a few people here. I have a PHPBB3 forum that I'd like to migrate to D7 but without this module it's a non-starter. The forum is a busy one so I can't afford the downtime of migrating to D6, upgrading, then installing and configuring all the D7 modules needed to make the new site what I need.

I am, however, a PHP developer, so I can take this on. I'm just checking if you're doing it so I don't step on any toes.

Martin...

subscribe

I changed everything for Drupal 7 by myself in this module.
Now I can activate the module and configure the migration. But when I click on "Execute the migration" it shows me only a line "Phpbb 2 Drupal Migration FormArray" and nothing else.
Don't know where to start to look for the failure.

Any ideas?

Evidently Ryanbach didn't patch the git repo. I tried that as you did, and it doesn't work. The clue is in the link to boombatower, which seems to be a tool to automatically upgrade modules.

Download the module distribution tarball, untar it, and patch that. This worked for me. Presumably you could also process a tarrred version of the git working directory through boombatower to get the same effect.

wget http://ftp.drupal.org/files/projects/phpbb2drupal-6.x-2.1.tar.gz 
tar xzvf phpbb2drupal-6.x-2.1.tar.gz
patch -p0 <phpbb2drupal-6.x-2.1-codingstyle.patch
patch -p0 <phpbb2drupal-6.x-2.1-coreapi.patch

As to whether this results in something functional, I've not yet checked.

Further to the above, I've managed to apply the patches to the git master branch. Now investigating how to get them back into the main repository, so that people more clued-up with Drupal than I can review them (I hope). I've created a patch-set using git-format-patch as described in http://drupal.org/node/1054616.

Note, these are still untested.

subscribing...

if any 7.x dev version comes up i'd be happy to test it and give feedback

Looked, and asked nbz about contributing to the canonical git repo for phpbb2drupal. No answers so far.

For now, I've published my repository on github, here:

https://github.com/wu-lee/phpbb2drupal

dargno, perhaps you could give some feedback?

One question: phpass claims to implement the "same approach that is used for Drupal 7" (http://drupal.org/project/phpass, http://drupal.org/node/29706#comment-784370). That would suggest that phpass is not actually required, and possibly might cause problems when used on Drupal 7. Correct? In which case one job for a Drupal 7 port would be to strip any phpass dependency from the code.

we do not need phpass for drupal 7.

I will look at getting an initial import done over the coming weekend, thats for the gitrepo, I will see if I can use that as a basis.

I've pushed some more commits to the git repo, in particular the branch 1033316-code-audit, in which I add a list of audit tasks from http://drupal.org/update/modules/6/7 (there are a *lot*), and attempted to manually check them off. I've got as far as the database API changes, but ran out of steam and will have to stop for now. Possibly I am not the best person to be doing this anyway.

This is having tested the branch 1033316-reapply-ryanbach-conversion and found it containing broken code: syntax errors ('"$file_path/$file->physical_filename"' gets converted to ' $file_path $file->physical_filename '), and errors on invocation like "Fatal error: Call to undefined function db_fetch_object() in [...]/phpbb2drupal.module on line 159". My aborted attempts to fix these are in the 1033316-test-ryanbach-conversion branch.

This dysfunctionality appears to come from the original patch uploaded above; presumably the boombatower tool is imperfect. I'm not sure if Ryanbach got any further than I but it looks like he would have had do a lot more work. Hence my decision to try and convert the code manually.

Please use as much as you can; I may be able to help later, if we can find a way to avoid duplicating work.

I've committed all the changes from that branch to Master - it is as good a position to start off from as anything.

PS for those feeling that they are out of their depth, my very first coding project was porting this very module from drupal 5 to drupal 6 (and I am still not a very good coder), so there is track record of going this way.

I will also adda few quick fixes for hacks that existed in the drupal 6 branch and earlier (the phpass stuff is no longer needed and the phpbb2drupal_comment_save function may no longer be needed, but that will need to be tested.)

No time for actual testing yet though.

nbz, you don't mention which branch "that branch" is explicitly, so I should check you noticed there were core commits than you added, and just chose not to add the rest? It looks like you just imported the commit that in the github repo happened to be current. See https://github.com/wu-lee/phpbb2drupal/network

If you want to import the lot simply, try:

git remote add wu-lee git://github.com/wu-lee/phpbb2drupal.git
git fetch wu-lee # now you can see my commits with gitk --all, use git diff master wu-lee/$some_branch, etc.
git merge $branch_of_your_choice # into the current branch

That is confusing - I did not intend to only partially pull from your branch.

I am used to visual tools, so I simply downloaded the tarball from https://github.com/wu-lee/phpbb2drupal and then did a manual diff to have a quick look over the changes.

Does that mean I have not got all the changes that had been made on github?

nbz: I would say not. The tarball would be a snapshot an older commit from the git repository there on github, so by using that you are throwing away a wealth of information which could help you and future maintainers. I've actually got a fork of your entire git repository there, with a number of branches appended, but an arbitrary, older branch is selected on the website and I suspect that is what you downloaded. I'll update the github repo to point to the tip of the newest branch in case that helps.

In case you missed them, have a look at my earlier posts, they describe which branches are which I created, and link to a page on Github which show a diagram of the network these branches make, which will help you visualise what's happened. What you need to do is use git's facilities to fetch and merge in differences between the github repository and yours, and you can then inspect and integrate them locally (see my suggested use of git-remote above).

There are visual tools for git, but what you choose depends on your OS and personal preferences. Googling will find them. This question appears on stackoverflow.com and other places, and is somewhat out of the scope of this discussion so I shan't elaborate here; however, feel free to ask me to elaborate in an email.

Looks like I've come to this late.

About six weeks ago I used the coder module to upgrade phpbb2drupal to D7. I did the conversion then got rid of the syntax errors that caused PHP to complain, then ran out of time so nothing more has been done.

I guess my port is from the D6 version directly, without looking at the patches posted on here. What is the state of things now? Should I continue with my port or are you far enough on that my time might be better spent help with wu-lee port from github?

Can't comment on nbz's progress - I've not heard anything not posted here not seen any additions to the git repo - but I've not done any more on this. Partly because I have other things to do but mainly because I don't want to duplicate work nbz may be doing.

Ideally we would have a way to divide up the work defined by the audit check-list here:

https://github.com/wu-lee/phpbb2drupal/blob/1033316-code-audit/upgrade_r...

Then some attempt to merge the separate contributions can be made, something nbz would need to do I would guess. I can think of a couple of ways of doing that, but none of them perfect.

Well, I've had a look at my port and everything was done.

db calls changed, obvious syntax errors corrected and and initial run revealed a few errors on the settings page, but they've been resolved and it runs now.

Of course, when I start the migration all I get is

Phpbb 2 Drupal Migration FormArray

So there's a long way to go yet.

I guess we need to see what the best starting point is and have a look at getting an initial, broken, D7-dev branch added here. I'm more than happy to post what I have already if anyone wants to compare what's going on, but there seems little point in duplicating effort.

Whatever happens, I'm happy that something is finally happening with this, a few people seem to need it.

Can you publish your changes in git repository, like I did? Possibly you could fork mine on github and insert your commits there. That way we can all see what you did and (hopefully) how you arrived there, compare that with what nbz and I have done, and nbz (or anyone with the time) can collect together all the best bits into what might become the final branch. Punting all this around is exactly what git's designed to do.

I didn't see the point in forking your repo since we started at different starting points, so I've created my own, I guess forking the D6 version. I know there are problems in in the main module but without much experience of creating D7 modules (yet) I'd appreciate any help anyone can offer in getting this working.

https://github.com/DarkSnow/phpbb2drupal

I think I have merged everything from the partial db-api-conversion branch into the master here - please let me know if this is just the one commit again, or everything?

I kept the upgrade userpoints file out, which I think would be better to have on the issue tracker instead.

@darksnow: Ok, then the question is, what *was* your starting point? My current best guess is the tip of the 6.x-1.x branch, whereas, shouldn't we be starting work on 6.x-2.x?

i.e. I added your repo as a remote to mine, and used git to diff against various candidate points in the history, looking for the smallest difference. I noticed you seem to be starting from a version with a very old CREDITS.txt. Searching back down the history, it looks like this one which was last seen in this commit from 2008-12-13.

However, searching further it looks like a better match for the tip of 6.x-1.x, which has been modified recently to remove CVS tags, and your version doesn't have CVS tags in the code. It also makes more sense that you'd start from the current tip of a branch corresponding to a release. Right?

But either way,

* we all need to start from the same point
* I would guess we should start from 6.x-2.x, else we're working on ancient history (in internet terms)

I integrated your change into my local/github repo by merging the 6.x-1.x branch into it:

# locally on my laptop
git remote add darksnow https://github.com/DarkSnow/phpbb2drupal.git 
git fetch
git checkout -b  1033316-test-merge-darksnow-6.x-1.x darksnow/master
git merge -s ours origin/6.x-1.x
git push github 1033316-test-merge-darksnow-6.x-1.x # push my merge onto github remote

Thus if you now fork my repo, you'll see your changes and the rest of the phpbb2drupal module's history, merged at the branch 1033316-test-merge-darksnow-6.x-1.x, which I suspect is a better starting point than one commit with no history.

But as say, I think we need to re-apply your changes on to nbz's 6.x-2.x branch (which nbz is currently modifying in his master branch in the main git repo). Perhaps using something like this:

# my local git repo again, assuming my github repository on a  remote called 'github' and 
# 6.x-2.x and 1033316-test-merge-darksnow-6.x-1.x branches exist to match the equivalents in github
git checkout 6.x-2.x   # checkout this branch
git cherry-pick -m 2 1033316-test-merge-darksnow-6.x-1.x   # attempt to re-apply darksnow's patch
# now resolve conflicts....

I've not finished that job, too tired, but I suggest this is something best done by the authors, who know what they changed where and why. I hope I've managed to be clear, apologies if not, questions welcome.

@nbz, I'm about to keel over from exhaustion so I'll reply to you later.

Having had a fresh look at the conflicts resulting from inferring darksnow's edits to 6.x-1.x and cherry-picking them onto 6.x-2.x: they're not all trivial. Clearly there are significant changes in 6.x-2.x, and I would find it hard to resolve these conflicts myself, so I'm going to pass on this.

If anyone (especially nbz or darksnow) wants to try and repeat this and are struggling with magic git incantations, please please ask me, I want to help facilitate this upgrade.

@nbz: the way you've copied my changes all in in one big blob into your git repository makes it harder to check, and loses all the information from my commit history. I suggest you make it easier for you to add any of my future changes - and for me to see what you have done with them - by adding a remote connection from your local repository to my github repository. Then you can merge my branch into yours with the normal git-merge workflow, resolving conflicts, and publishing the result in the central repo.

Perhaps like this:

# In nbz's local git repo,
# add a remote connection called 'wu-lee'
git remote add wu-lee git://github.com/wu-lee/phpbb2drupal.git 

# append my commits, without changing local history
git fetch wu-lee

# checkout the starting point you want to merge my changes into
git checkout 6.x-2.x 

# Merge in my commits as a 'feature' branch, then resolve conflicts 
# (there should be none if you start on 6.x-2.x)
git merge wu-lee/1033316-partial-db-api-conversion --no-ff --log  

# At this point the differences introduced are explicit and no information has been lost

Now you could add or remove whatever corrections you deem necessary - it is also a good idea to committing each logical change as a separate commit, to make later auditing simpler.

As for the "upgrade userpoints file" AKA upgrade_review_points.org:

* I think it's fine to leave it out if we don't lose any info. i.e. Please can we keep the points somewhere that we can all see and contribute to?
* Do you propose adding [counts them] 263 issues, one for each point? Or one for each of 17 groups? Or something else?

Speaking for myself, if I were working on this alone I would *need* to check off a point-by-point list like this to have any idea what to do and how far I'd got, so I'd miss the list if there weren't something equivalent. In any case, it seems a good thing to be as thorough as the Drupal developers have been, and show we've addressed every point with one or more commits.

(As an aside, I do suspect it would be easier if we were all working on github could use the rather excellent facilities there. In fact I would be surprised if this weren't actually a common way of working on drupal modules. The main repo could stay on drupal.org, where nbz or other maintainers could push "official" changes into it as they do currently.)

I have pushed some more changes to master.

Can someone please comment on this commit? I have no idea if that will work with the new database layer and if that is not the right approach, we need to figure something out.

Next tasks:

1. fix _phpbb2drupal_check_tables and any other problems in phpbb2drupal.pages.inc
2. (Still TODO:file field tests on relevant nodes and comments)
3. input format select code in phpbb2drupal.pages.inc is mouldy and semi broken.
4. Need to fix phpbb2drupal_migrate_form in phpbb2drupal.module.
5. Test and fix actual migration.

Any help here is most welcome.

I havent used phpbb in years and it is confusing me.

Can someone help guide me to create new users in phpbb?

I cant seem to register accounts with fake email addresses and the admin does not seem to have the ability to create new users.

I installed "ACP Add User MOD" using automod but I cant see where the permission to allow the admin to add users from.

It is all a bit crazy.

(I want to test how far current master gets to in importing. I suspect it will fail at the first hurdle, but being aware what that is, we can combat it.)

I think the database handling is currently totally broken and the commit mentioned in comment 41 is totally wrong too - the correct way should be to adda new database driver to the databases global array and let it deal with the prefixing.

@nbz: I've sent you some contact details via the drupal site, which should be able to get you a quicker answer from me, at least.

Creating new users is something I've not really had to do - the users do it themselves and I just need to activate the accounts. I suspect the standard way to do it is just to register as if you were the user, and tweak the account afterwards.

Fake email addresses aren't going to work if PHPbb expects the email it sends to be validated, and there is an option which validates the domain has an MX record, too (In ACP->General->Server Config->Security settings). Use temporary email addresses instead; spamgourmet.org may help there if you have no means to do that. Note that PHPbb can also disallow multiple users sharing an email address (in ACP->General->Board Config->User Registration Settings),

Can't help with "ACP Add User MOD", I don' t have that.

I ahve responded to the email.

For everyone else following along:

I dont know too much coding etc and my first real dab was when I needed this module for drupal, so I hacked away at it til I got something to work after a few months.

As for how to proceed with the porting, my way is to progressively get further in the import process.

Currently the configuration page works, but the database connection code switching code is broken, so that is the major task to focus on. At the same time we can fix the commit introduced in this commit which was the wrong way to deal with the prefixing. the correct way is to feed in the correct prefix into the database connection settings.

I doubt this will be the easiest task, but it should be possible to fix (get the configuration page to save a connection array, and then in _phpbb2drupal_db_connect load it into the $databases['default']['phpbb'] array).

the multiple database connection code in master should now be working.

(commit mentioned in comments 41 and 47 has also been fixed.)

Next task is to fix user import.

Since last night user import and the creating of categories/forums works.

Next challenge is to fix import of topics to nodes - first step of which is fixing the query at around line 588 of phpbb2drupal.module.

This is a good point for others to jump in now to see if they can fix problems and get progressively further. Ther eis no magic to it, see each point of failure as a hurdle and when you fix that, you will get through to the next point of failure.

Just a note to say I'd like to help test this but I won't be able to work on this for a couple of weeks now.

awesome, nice progress... just like wu-lee as soon as you got a dev-release i'd be happy to test it against a test phpbb and drupal install

I tried to connect to a mysql database while the drupal db is sqlite and just visiting the configure page crashes and I cannot edit the database settings as the page does not display.

Something that is a major issue - I assume a test in the database connections settings page may fix this problem, but it needs to be written.

latest master *should* be able to import users, categories, topics and posts into drupal (last two without the attachments that code has been untouched) as long as the phpbb tables are in the same database (and maybe even require to have the prefix "phpbb_" - something for the curious to test).

For those that know how to set the phpbb database credentials in the module without visiting the configure page (so more or less hacking the module), you should also be able to import from another database.

The problem I ran into was when trying to import into an sqlite database from mysql, I could not get to the configure page to enter the mysql credentials - the automatic table checking code would crash the page. But entering the details manually I was able to import data from a mysql database into an sqlite database. I only did it once, and from a datababase with 1 topic and 2 comments and 3 users, so I cannot confirm that it is flawless.

So what is going on here?
Where are the problems?

I really need to have this module on D7! Probably I can help to remove the remaining issues, but for that I've to know what's the actual state of the project :)

You can download latest master from here: http://drupalcode.org/project/phpbb2drupal.git/shortlog (click on the snapshot link next to the top line, that should also have the tag of "master" on it).

Currently the problems are:

1. The database code does not seem to work if incorrect credentials are present for the phpbb DB. Easiest way around this is to have the phbb tables int he same database as the drupal database. Otherwise edit phpbb2drupal.module and find function _phpbb2drupal_db_connect and in there edit the following bit:

  if ($same) {
    // The phpbb data is in the same database as the drupal data.
    // We simple need to copy databse settings and use the correct phpbb prefix.
    // Code done following guide at http://drupal.org/node/18429.
    $other_database = $databases['default']['default'];
    $other_database['prefix'] = $pre;
    Database::addConnectionInfo('phpbb', 'default', $other_database);
  }
  else{
    $other_database = array(
      'database' => variable_get('phpbb2drupal_db_database', $databases['default']['default']['database']),
      'username' => variable_get('phpbb2drupal_db_username', $databases['default']['default']['username']),
      'password' => variable_get('phpbb2drupal_db_password', $databases['default']['default']['password']),
      'host' => variable_get('phpbb2drupal_db_host', $databases['default']['default']['host']),
      'driver' => variable_get('phpbb2drupal_db_driver', $databases['default']['default']['driver']),
      'prefix' => $pre
    );
    Database::addConnectionInfo('phpbb', 'default', $other_database);
    if ($test) {
      if (!db_connect($databases['phpbb']['default'])) {
        return 0;
      }
    }
  }

with

    $other_database = array(
      'database' => 'Database Name',
      'username' => 'Database Username',
      'password' => 'Database Password',
      'host' => 'locahhost', //I am guessing at this - I assume most have it as this
      'driver' => 'mysql', // or other database type
      'prefix' => $pre // or replace that with whatever prefix you have for the phpbb database tables.
    );
    Database::addConnectionInfo('phpbb', 'default', $other_database);

With this hack, you can test the module.

For those that want to help fix this issue, what is needed is for phpbb2drupal_check_tables function to not fail if the requested tables are not found.

2. "Transform URLs" is broken. This database query needs to be fixed in phpbb2drupal_replace_url:

$result = db_query('SELECT ptt.nid, n.body, n.teaser FROM {phpbb2drupal_temp_topic} AS ptt LEFT JOIN {node_revision} AS n ON ptt.nid = n.nid');

It needs to take into account that the body is now a separate field not stored in the node_revision table.

3. Fix import of private messages. The code needs to be tested and see where it is incorrectly setting things up - I am importing the code, but the imported messages do not seem to show in the message listings.

5. Fix import of attachments.

Attempted import of my database using a fresh install of drupal 7.7, mysql->mysql, and master branch (ID 1bddd70e86...). Imported users and forums ok, but there was an eventual error importing topics, specifically, it seems to fail importing topics with phpbb_topic.topic_status = 2. Error below (the full listing goes on with similar errors for pages).

* Found 566 topics: Beginning Import
* Could not find post details of topic: 491
* Could not find post details of topic: 535
* Could not find post details of topic: 536
* Could not find post details of topic: 539
* Could not find post details of topic: 540
* Could not find post details of topic: 541
* Could not find post details of topic: 542
* Could not find post details of topic: 543
* Could not find post details of topic: 544
* Could not find post details of topic: 545
* Could not find post details of topic: 575
* Successfully Imported 555 topics

# Warning: reset() [function.reset]: Passed variable is not an array or object in forum_node_presave() (line 328 of /var/www-virtual/edinburghtwins.noodlefactory.co.uk/drupal-7.7/modules/forum/forum.module).
# Warning: key() [function.key]: Passed variable is not an array or object in forum_node_presave() (line 329 of /var/www-virtual/edinburghtwins.noodlefactory.co.uk/drupal-7.7/modules/forum/forum.module).
# Warning: Invalid argument supplied for foreach() in forum_field_storage_pre_insert() (line 525 of /var/www-virtual/edinburghtwins.noodlefactory.co.uk/drupal-7.7/modules/forum/forum.module).

The topic IDs above are all those topics with status 2. My guess is that the code in phpbb2drupal.module here triggers it on line 680 (final line below), when hook_node_presave($node) is called within node_save(). I can't currently see why.

    if ($topic->topic_status == 2) {
      db_set_active('phpbb');
      $forum_id = db_query('SELECT forum_id FROM {topics} WHERE topic_id = :topic_id', array(':topic_id' => $topic->topic_moved_id))->fetchField();
      db_set_active('default');
      $moved_tid = db_query('SELECT tid FROM {phpbb2drupal_temp_forum} WHERE forum_id = :forum_id', array(':forum_id' => $forum_id))->fetchField();

      $node->field_tags[$node->language][]['tid'] = $moved_tid; // which forum it used to be part of
    }
    else {
      $node->field_tags[$node->language][]['tid'] = $tid;
    }


    db_set_active('default');
    node_submit($node);
    node_save($node);

Some other observations:

* The module's config defaults expects phpbb tables in same database. Unchecking this option and saving allowed me to specify the correct credentials, and so I didn't need your hack above. In fact, I don't understand your point 1. above, where you say "The database code does not seem to work if incorrect credentials are present for the phpbb DB..." - surely it couldn't possibly work without correct credentials?

* i didn't initially realise what "test on copy first" meant

...and that it must be checked for the conversion to be possible. The way it is worded it makes it sound like it enables a dry run mode, but in fact I realise it means that it means "yes, I really want to do this".

* some of the module config help texts need their menu navigation paths updated for d7

For example I suspect Don't forget to enable bbcode in the selected input format (admin > input formats > configure) should be Don't forget to enable bbcode in the selected input format (admin > config > formats), and the rest of the instruction looks like it may be describing d6 features which aren't in d7.

* The module's config defaults expects phpbb tables in same database. Unchecking this option and saving allowed me to specify the correct credentials, and so I didn't need your hack above. In fact, I don't understand your point 1. above, where you say "The database code does not seem to work if incorrect credentials are present for the phpbb DB..." - surely it couldn't possibly work without correct credentials?

This may be a sqlite only issue, which is how I tested multiple database import - when sqlite does not detect the looked for tables on the configuration page, it crashes the whole page so that alternative credentials *cannot* be entered at all.

That is when you need the hack to manually set the database settings.

Thanks for the rest of the feedback - a few issues to work on.

As for the topic_status = 2 issue, can you try replacing the whole if/else statement with:

$node->field_tags[$node->language][]['tid'] = $tid;

Either the comments on that code are wrong or it seems to be doing the wrong thing. (I suspect that that code is needed, but is very badly commented.)

Just one other thing I think is wrong:

On Line 654/655

    $node->uid      = $uid;
    $node->uid      = NODE_PUBLISHED; // published or not - always publish

Guess that can not be correct as we override the $uid by NODE_PUBLISHED.. shouldn't it be:

    $node->uid      = $uid;
    $node->status      = NODE_PUBLISHED; // published or not - always publish

The issue with the warnings seems to be, that the D7 forum-module expect to have a field taxonomy_forums set to an array!
Probably they renamed field_tags?

I shortly analyzed the attachment-import. There is actually just a db-import of the paths. Shouldn't we implement an option to copy the file into the drupal-filesystem? This would make it possible to delete the phpbb installation after the import from the server (or isn't this possible?)

Trying to understand the code I mentioned above handling phpbb topics with status=2 (I infer this means 'moved'), it seems to be trying using use the "taxonomy" meta-data tagging facility of drupal to label the topics with their (original) forum id. See phpbb2drupal.install where it says phpbb2drupal_temp_forum "Maps phpBB forum forum_id to Drupal taxonomy tid".

I say "trying" since I don't understand Drupal's API well enough (read: at all) to be able to see if this is likely to work or not.

I notice a blog post by Dave Reid which states "I highly recommend using [field_get_items()] rather than trying to get the values directly using statements like $items = $node->field_tags[LANGUAGE_NONE];".

I also notice this (line 518 of phpbb2drupal.module):

      // Stupid stupid taxonomy taxonomy_term_save does not return the saved term object.
      // We need to make do by loading the tid from the database directly from the database table.
      $forum['tid'] = db_query('SELECT MAX(tid) FROM {taxonomy_term_data} WHERE ( vid = :vid AND name = :name)', array (':vid' => $forum['vid'], ':name' => $forum['name']))->fetchfield();

Checking the docs for taxonomy_term_save it seems that you can get the new term id from the $term object, since it is modified in-place by the function call. So you can avoid a database query here.

@ comment 55 - the node import errors should be fixed. Please can you test this again and confirm if the topic_status = 2 error still persists? (I have not fixed it explicitly, but I wonder if it was simply a sideeffect).

@ comment 57 - fixed.

@ comment 59 - while we can use field_get_items() to *get* previously saved values, we cannot use it to set/store the data as we are here. The link to the blog was useful though to figure out what form the data should have - set. but this should also now be fixed - I was saving it to the tags field when I should have been saving to the forums field.

fixed the taxonomy_save_term thingy - thanks for the pointer.

@ comment 58 - the code sets the file path to be relative to the "files" directory in drupal - there is a manual step involved where the files folder would manually need to be moved into the correct place after import for the file links to work.

Wow, loads done on this.

Sorry that I went quiet, I've been very busy. I've got the latest "master" version of this and tested it against my setup and it's thrown up a couple of issues.

Firstly, it looks like the post dates are being lost, so it looks like all forum posts were made at the time of the import. I've not looked into this yet.

Announcements in PHPBB are essentially posts without a forum assigned, so they appear above all forums. Since the forum_id in the table is 0, this causes an error in the import. I'm not sure there is a way to fix this, but maybe it could be added to the initial setup phase as a warning. Giving the topic ID of any announcements so the user can change them to global topics in phpbb before the import or lose the topic. Of course, globals don't appear global in Drupal either, but that's another issue.

I've fixed the phpbb2drupal_replace_url function. The database schema has changed a lot between D6 and D7, so I've used API calls in there instead of the replace queries that were there. Similarly, I've updated the _phpbb2drupal_replace_links_ functions towards the end of the module file.

I've attached a diff of the changes against master, hopefully they can be integrated in.

I'm more than happy to help with this as long as I have the time. I'm currently admin on a busy PHPBB site so I know how it works inside out if anyone needs any advice with that. I'm a PHP programmer but I'm not that experienced with the D7 API.

Great work so far to all those involved, I think with a little push we could get this done soon.

I'll carry on testing and fix anything I can.

Martin...

I am in favour of using more API calls as and when we can.

The diff attached seemed to be blank though?

Sorry about that. It was late and it seems that when I piped git diff to that file, it never did anything.

Hopefully the one attached will be better ;)

The above patch is committed.

I have also committed a patch to fix the timestamp problem.

I had a choice in between forking the core functions, or adding hacks - I added the hacks and hopefully that will be enough.

In the future if node_submit allows the changed time to be passed to it as is the case with comment_submit, another hack can be removed.

This now leaves:

1. The filter format choosing code on phpbb2drupal.pages.inc is flaky.
2. private messages import is broken.
3. attachment import is broken.

Great.

I was just looking at the topic_time issue and I came to the same conclusion, so a hack to prevent the core functions from setting the timestamp, glad I don't have to bother now ;)

As I said, I run a PHPBB forum so have loads of test data. I'll have a look at the private message stuff this evening and let you know how I get on.

Martin...

hm... because the apis are used to transform url's, we will need to update the "changed" times again manually or go back to updating the database table directly.

Right...

Could we make updating the time stamps the final stage of the migration?

Or skip the URL transform altogether? Perhaps not, but I'm not convinced it will work at all. It looks like it's looking for "forum/viewtopic.php" for example, but what if the forum in question is not stored in the forum directory? There will be no URLs that start with forum/.

Also, I've been running the URL transform for over ten hours and it's not done, so I guess it's broken.

Looks like you're the lead on this nbz, so what do you want me to look at next?

I'll have a look at the private message import in it's entirety, seems like a decent chunk of work that I can get stuck into, and self contained enough that I won't step on anyone's toes.

I'll also have a think about how to handle announcements, though I think, as said above, it will just be a warning during import setup because there's no real automated way to fix them short of assigning them arbitrarily to the first valid forum.

Anyway, onto the PMs for now, then I'll see what you need me to do.

Martin...

Ive tried replacing the api calls with the following uncommitted code:

  foreach ($result as $tt) {
  $data = db_select('field_data_body', 'f')
    ->fields('f', array('body_value', 'body_summary'))
    ->condition('entity_type', 'node')
    ->condition('entity_id', $tt->nid)
    ->execute();
    
  db_update('field_data_body')
    ->fields(array(
      'body_value' => _phpbb2drupal_replace_links($data->body_value),
      'body_summary' => _phpbb2drupal_replace_links($data->body_summary),
    ))
    ->condition('entity_type', 'node')
    ->condition('entity_id', $tt->nid)
    ->execute();

    // Transform urls in comments linked to this node.
    $cids = db_query('SELECT cid FROM {comment} WHERE nid = :nid', array(':nid' => $tt->nid));
    foreach ($cids as $cid) {
    $data = db_select('field_data_comment_body', 'f')
      ->fields('f', array('comment_body_value'))
      ->condition('entity_type', 'comment')
      ->condition('entity_id', $cid)
      ->execute();
      
    db_update('field_data_comment_body')
      ->fields(array(
        'comment_body_value' => _phpbb2drupal_replace_links($data->comment_body_value),
      ))
      ->condition('entity_type', 'comment')
      ->condition('entity_id', $cid)
      ->execute();
    }
  }

and for some reason that doesnt work. Any ideas?

EDIT - yes, you can work on the private message import first. Here, in privatemsg 6.x-2.x there should be some code in an update function that may be useful to "clean up" the imported data to remove duplicates. It may not be needed though.

@ Darksnow - just to add that if you use phpbb_redirect, the transformation of urls is not necessary. (though the module may require customisation to look for viewtopic.php etc in the correct place - it is hard coded to look for it in the "forum" path.)

#68, what's not working about it? It looks fine, like it should do what you expect.

I've done a first pass at the private message import. It's basically a rewrite to merge a few queries (faster to do joins that run loads of queries in loops) and use the pm_ API to create messages and thread.

Using my test PHPBB data, which is extensive, it seems fast and it seems to work.

I've attached the diff below. It would be good to get other people to have a look at it and tell me where it doesn't work or where it gets stuff wrong. All I know is that it doesn't crash and it looks like all my PMs from phpbb can be read by my Drupal user :)

Next up I'll patch the code to skip announcements, it's better to ignore them than to crash, and I'll have a crack at getting a warning in the setup screen working. Maybe tomorrow, but I have all day Tuesday clear (unless I get paid work to do) so plan to do more work on this then.

Good night

Martin...

EDIT - I needed to put foreach loops in code in comment 68:

  foreach ($result as $tt) {
  $rows = db_select('field_data_body', 'f')
    ->fields('f', array('body_value', 'body_summary'))
    ->condition('entity_type', 'node')
    ->condition('entity_id', $tt->nid)
    ->execute();

  foreach ($rows as $row) {
    db_update('field_data_body')
      ->fields(array(
        'body_value' => _phpbb2drupal_replace_links($row->body_value),
        'body_summary' => _phpbb2drupal_replace_links($row->body_summary),
      ))
      ->condition('entity_type', 'node')
      ->condition('entity_id', $tt->nid)
      ->execute();
  }

    // Transform urls in comments linked to this node.
    $cids = db_query('SELECT cid FROM {comment} WHERE nid = :nid', array(':nid' => $tt->nid));
    foreach ($cids as $cid) {
      $rows = db_select('field_data_comment_body', 'f')
        ->fields('f', array('comment_body_value'))
        ->condition('entity_type', 'comment')
        ->condition('entity_id', $cid)
        ->execute();
  
      foreach ($rows as $row) {
        db_update('field_data_comment_body')
          ->fields(array(
            'comment_body_value' => _phpbb2drupal_replace_links($row->comment_body_value),
          ))
          ->condition('entity_type', 'comment')
          ->condition('entity_id', $cid)
          ->execute();
      }
    }
  }

However I still get the following error:

Recoverable fatal error: Object of class stdClass could not be converted to string in DatabaseStatementBase->execute() (line 2108 of C:\wamp\www\drupal-7.7\includes\database\database.inc).

I am committing the code now though.

Having a look at the privatemsg import patch in comment 70, it seems to rely on having the phpbb data and the drupal data within the same table.

That is not somehting we can rely on in the module (though it will work for specific scenarios).

I have now fixed the privatemsg import code - something ready to be tested now.

So this leaves the following issues:

1. user import leaves an undefined index - I think the roles may not be properly set.
2. The filter format code in phpbb2drupal.pages.inc needs to be looked at - it is setting an extra option than is needed.
3. import of attachments.
4. Announcements. Another option here to consider is if there are announcements, creating another forum tid for them and adding all announcements to that forum.
5. get rid of the recoverable error when transforming urls.
6. test phpbb_redirect.
7. bug #1248114: PDOException: SQLSTATE[HY000] when calling db_table_exists when table with prefix does not exist. which I think is a core bug.

I'm a little confused here.

I've just updated my local copy of the repo and compared the committed changes against the patches I submitted and it seems that all my code has just been disregarded.

I'm more than happy to help, and pretty much rewrite the private message import code last night, but am I just wasting my time?

The reason I wanted to change to using API functions instead of direct manipulation is that when the time comes to port this to D8, the coder module will be able to translate API calls to the newer equivalents. It also greatly simplifies the code and the required understanding of the underlying database structure. Finally, while perhaps it could cause issues with the timestamps attached to things, a quick update query to solve that after the import is done would solve that problem without PHP loops containing SQL queries, which makes the import very slow.

Anyway, I'm not sure what you do on this project now. No point spending hours on something if it's going to be ignored.

Cheers,

Martin...

I had no intention to cause wasted work and while I do want more and more API's to be used where possible, here (and for privatemsg import) it seemed that direct manipulation of the tables was easier.

Granted it was committed to early, as an error is thrown when using it (and it may not work), but the aim here was to request help to see if I was missing something obvious.

We can always revert this code and go back to using API's if it is felt that that is the superior method (but then since we are working around node_save twice, it may be best to fork that for our own purposes too).

(I had planned to use the privatemsg import code too, but it did not work when using multiple databases)

I noticed that avatars are not being set in the database. Turns out the user_save API function needs a proper file object. We can get this from a file_copy of the file referenced in the phpbb user table and then call file_copy to copy that into the Drupal file system. That gives us a managed file reference in the database.

Obviously this would be dependant on the "import attachments" stuff, which I haven't looked at at all yet.

I assume it gets some sort of reference to the source file system and imports everything into the Drupal file system.

Maybe time to look at the Attachments stuff now, before I fix the avatars issue.

Odd, that previous message should have been sent at lunch time.

I've had a closer look at the private message stuff. PMs don't really support folders as far as I can tell, but you can tag them for easier management. Would it be worth looking into tagging any phpbb PMs that were in folders with the name of the folder?

I would like a discussion about the best approach to get round the limitations of the API and timestamps. I don't think forking core code is a good idea and would prefer to manually update just the timestamp where needed. Are we also losing user registration dates because of this too?

Of course, there's also an argument for getting this code working by any means and as quickly as possible. It should generally be getting used by the technically competent so rock solid stability is not an absolute requirement. My concern is that any changes to anything we deal with here will need to be taken into account, while perhaps a lot of it would be hidden and handled by the relevant APIs. I'm pretty sure we're taking everything into account when adding a user, for example, but phpbb2drupal is setting the "picture" of a user to a string which should represent the path to the image file, while the API needs an object. I just wonder if there are subtleties to the database structure that we are in danger of missing.

Aside from that, use of the API should create generally cleaner and shorter code, which will help with maintenance and eventual upgrading for D8 when the time come. The private message code is a case in point. We can update the messages and the index of messages to mock up the structure required, or we can see if a message is threaded and if that thread exists and create a new message or a reply to an existing thread, as required and let the PM API deal with what goes into which table.

At the end of the day, I just want this to work and can see both sides of the API discussion.

I have a free day tomorrow and plan to look into attachments and see if I can automatically import all files from phpbb into the drupal file handling system. Attachments and avatars.

I will of course check back here frequently.

Keep up the good work. :)

Martin...

I wont have any real time to work on the module over the next few days (though might find some).

As for import of files, in the code comments there is a link to another site that explains how to programattically create nodes and in the example, there is a file, so that may be good to look at.

(but before then, there needs to be code to decide what field to import the file into and maybe a selection box on teh configuration page.)

This module could benefit from some documentation of the phpBB 3 data schema (or references to external documentation), the resulting Drupal data schema, and the way one is transformed into the other. For example, how Drupal's taxonomy is used to mark moved forum topics.

It doesn't have to be exhaustive, beautiful, nor detailed to help. Even a little in comments would help a lot. The point would to try and give contributors an overview, and maybe highlight where the the unknowns are.

I've had a look at the result of ticking "import attachments" in the interface and what it appears to do, is add an entry to the files database table, leaving the copy of the files to the user later. I guess that's all fine but I think I would prefer that do be done in one step.

You point the Drupal install at a directory containing the files that need to be imported and then the code could intelligently copy the files to Drupal's file system, skip any missing files and clean the database a bit, and do all that using the Drupal API.

The downside is, again, the time stamp of the file.

http://api.drupal.org/api/drupal/includes--file.inc/function/file_save/7

That code saves an entry to the Drupal database and it explicitly sets the time stamp to the import time. At this stage I'm reluctant to continue until we have a discussion about how best to handle this. Do we carry on and create dead database entries directly, for files that don't exist in the Drupal file store, or do we come up with a consistent plan to deal with the time stamp issue across the board and use the API?

I for one would prefer to use the API everywhere, and work round it to deal with time stamps, either at import time, or as an additional optional step at the end of the import. I would write the code to understand the PHPBB database schema, and use the Drupal API everywhere, getting rid of the need to understand which table needs to be updated to add a given node type to Drupal, that's what the API is there for after all. As far as I can see, it's only timestamps that are an issue that way, and they can be fixed in one sweep at the end of the import.

For reference, and in answer to wu-lee, the following should be all you need to know about the PHPBB database schema:

http://wiki.phpbb.com/Tables

Any thoughts?

I am a pragmatist - I like the idea of using API's, but I have some reluctances, probably because I am comfortable enough with meddling with the database and the main aim is to get things working so that the module can once again be ignored in peace for another 3 years (I only needed the module when I did a single migration in 2008 and needed to port the module to Drupal 6).

A third option is to plug into the migrate module where we simply provide an import schema.

I don't like the idea of using file_save after node import - we can get the file imported at the same time, but even in this case if we have to tell the user to move the files folder into the right place, I do not see this as too big of an issue as the old files will need to be available whatever the case.

Personally, I prefer the diea of getting the module to work first and then doing other nice to have things - question is what is faster right now - API calls or direct manipulation? Either option I am fine with and the current approach is a melding of both where either due to how code was before or what was easier, we are using both API's and direct manipulation to get the desired effect.

In drupal 6 we had a forked comment_save function, which we no longer need now, so I do not think it terrible to fork functions as long as it is clear what is happening and why. Same with the phpbb database prefixing code - before it was ahack and now for drupal 7, it is using normal drupal API as it has become easier to do what was needed with it.

What does Migrate module do here? I assume it has the same set of issues, so it may not be a bad idea to peer at its code...

I have a blog mod installed on PHPBB, as well as a gallery of images (and a map of ski resorts, but I'l handle that myself) so I'll have a look at the migrate framework to get at least the blog entries imported.

Could be that everything we're discussing here has been dealt with there and all that's needed is a migration schema as you say. I've just had a quick read of the migrate documentation and it addresses something I was going to ask about here, drush support.

But, back to the big question. I'm a big fan of doing things "the right way" tm ;)

But, as you say, I'm also a pragmatist and understand that we just need things to work. Especially for a module which hardly gets used and when it does it's a one off rather than something that has to be rock solid and run for a thousand years non stop. With that in mind, a collection of hacks that work would get the job done.

Put like that, it's perhaps best to just look at how the existing code worked for D6 and change as little as possible to get everything working.

Anyway, when I get the time, I'll have a look at the migrate module and see how blogs are stored inside my PHPBB so I'm better informed about the migrate module and can advise on it's use for the whole migration.

Ultimately, I just want all my phpbb stuff in Drupal, no matter how it's done.

Martin...

I will assume that the mod of phpBB that you are using is nothing that changes too much of the structure of the content.

As such, I will expect the "blog" posts to simply be forum topics that are in the "blog" (or similarly named forum) forum.

If this is the case, then all you need is to check if the phpbb topic is in that blog and if so, not to add a tid, but instead give the node type the value of "blog" instead of "forum".

(We could do a similar thing wth announcements - create an announcement node type and move all announcements to there.)

The mention of drush makes me think: that would be damn good for testing the basic conversion - to be able to script it. Especially for regression tests.

Is that possible, currently? Are any automated tests possible?

Finally had a good chance to get back into this...

@nbz: The user blog mod is an add on to PHPBB3 that, as the name suggests, allows users to create their own blogs. It actually creates new tables to manage the blogs so is entirely independent of the forum system. This, I thought, made it good for testing the D7 migrate module to see how it works.

@wu-lee: The migrate module gives you a drush interface without any work.

I've created a partially working migration for PHPBB3 Users. My intention was to migrate the blog entries using the mapping table that phpbb2drupal already creates, but that's not really how the migrate module works, so for simplicity I thought I'd just write, from scratch, a user migration.

I fell over on a few things, most notably that the classes needed to implement a migration can't have a number in there name (PhpbbBlog instead of Phpbb3Blog) and some other basics of actually creating a module altogether.

I've complete the user migration anyway, and it does what this module does, stripping + signs and making them spaces, taking into account the user_type field and skipping anonymous and bots. It does it in about fifty lines of code!

I've also got the module install creating fields for IM accounts and websites and plan to add a field migration and image migration.

But I digress.

The point of my test was to see how easy migrate was to implement and to see if it gets round the issue we have here with dates when using the API, and the answers are:

It's really easy to do. As long as you understand the fields available to a given node type (or entity in D7) and the schema of the source table it's just a case of telling it where to get the data, which are the index fields so it can create the mapping tables and which field in the source maps to which field in the target. It does all the hard work for you, even creating a nice bar graph as it's going.

Most importantly, the created and access times are correct in my test. Use of the API causes these dates to be wrong. The API source forces the current time stamp for book keeping purposes, which is fair enough. It seems the migrate module does direct DB manipulation so the dates stay right.

To my mind, and perhaps controversially, this gets round the issues we have here. It will simplify the code, means we can use an API (the migrate one) and can get the migration done without any nasty hacks.

In short, I'm proposing a complete rewrite of this module using migrate sub classes.

Thoughts?

Im all for pushing the legwork to Migrate module (though probably as a 2.x rewrite instead of a 1.x release which we have almost stable for the simplest of cases).

Does migrate work with multiple databases?

It looks like yes. http://drupal.org/node/1014558

I'm looking into completing the user migration I've already done by importing PHPBB custom fields as Drupal fields, instead of using the deprecated Profile module, importing all the various IM fields into a multi-value "IM" field and getting it to automatically import user avatars as user pictures.

Is it acceptable to have the user edit a source file to set database credentials and options, or do I need to look into getting user input?

I'm glad we agree on this but I guess the pertinent questions is, how close are we to getting this to work as it is without a rewrite?

Does any of this work in Drupal 7? I would really like import my phpbb 2 forums into my Drupal forums. How can I accomplish this?

"The drupal 7 version of this module will only support migrating data over from phpbb 3.x and not phpbb 2.x."

It mostly works, but a few things still need to be fixed like attachment import.

However, this is only for importing from phpbb3 - phpbb2 import is not supported and the last version that did is to drupal 6 (the phpbb2drupal-6.x-1.5 release.)

I can't even get it installed properly. I will upgrade my phpbb version to version 3 to make this work. What is the secret to get it installed in Drupal 7? I'm getting all kinds of different errors. The main one right now I think is, it's looking for the profile module to be installed. I have installed profile2 to see if that would work, but it did not.
Please help. I really want to make this work. Is there a V7 download that will install properly?

I have not tested profile2 and the module is currently requiring profile from core. You can hack the module to not require profile module and to not import the extra profile data (I assume that profile 2 will require the data to be input in a different method).

I took out the profile module requirement and it still will not allow me to enable it. Is there a main download area? I am not a programmer and I don't understand all the diff files, blobs, commits, etc.... I don't understand exactly which files to grab?????
Can someone tell me which files I should download to make this work in Drupal 7????

Make you have the bbcode module and then try using this: http://drupalcode.org/project/phpbb2drupal.git/snapshot/bde9b7e.tar.gz (7-zip is AFAIK the best program to use for compression/decompression on windows and it supports these archives).

that should be the latest tarball from now but you will still need to edit the info file to remove the dependency on profile module.

then test the module on non live data to see what works and what doesnt work.

Let me know how far you get - and if the transform "urls" function works at all or not and if it destroys data.

I did make it over to that page before you posted this. I grabbed all of those files, put them in the sites/all/modules/php2drupal, and I was able to enable it finally. However, I still can't run it. I tried the link admin/php2drupal or whatever it was in the readme, and it just goes to the modules page. Do I have to edit my phpbb database info before it will run? I'm sorry for all the trouble, but I'm not a programmer, and this whole thread is confusing to me.

OK, I disabled it and reenabled and it started working. Is it not able to ask where the db is? I'd rather not put this info in my drupal database first. I'd like to import it from the old db elsewhere.

I guess the location of php data portion needs to be fixed? As I stated above, I'm trying to import the data from another site.

it asks for the old db details in the configuration screen - simply untick the box that says "same db" and when you click submit, it will bring up the option to enter new credentials for the old db.

Please click around - this is a power user module and you will need to and have a look at all the options and do multiple imports of data and start again a few times, all to try out differnet things to see what works for you.

Cool, I didn't think about unchecking it and then saving. I assumed it would automatically pop up at that point. I really appreciate your help with this. I'll copy my DB now and give it a try.

Thanks again!

I tried it 5 days ago with a snapshot from the master. Everything works fine, but every post besides the first one in a thread is now mapped to the admin. only the first post in a thread is mapped to the right person.
any ideas?

After setting everything up and getting it running, I'm getting these errors after I put in the database connection info. I can connect to the db with a mysql client using the same credentials..........

Additional uncaught exception thrown while handling exception.
Original
PDOException: SQLSTATE[HY000] [2013] Lost connection to MySQL server at 'reading initial communication packet', system error: 110 in db_table_exists() (line 2701 of /home/content/39/8188839/html/includes/database/database.inc).

Additional
PDOException: SQLSTATE[HY000] [2013] Lost connection to MySQL server at 'reading initial communication packet', system error: 110 in db_merge() (line 2385 of /home/content/39/8188839/html/includes/database/database.inc).

--------------------------------------------------------------------------------

Uncaught exception thrown in shutdown function.
PDOException: SQLSTATE[HY000] [2013] Lost connection to MySQL server at 'reading initial communication packet', system error: 110 in db_delete() (line 2421 of /home/content/39/8188839/html/includes/database/database.inc).

--------------------------------------------------------------------------------

Uncaught exception thrown in session handler.
PDOException: SQLSTATE[HY000]: General error: 2006 MySQL server has gone away: INSERT INTO {watchdog} (uid, type, message, variables, severity, link, location, referer, hostname, timestamp) VALUES (:db_insert_placeholder_0, :db_insert_placeholder_1, :db_insert_placeholder_2, :db_insert_placeholder_3, :db_insert_placeholder_4, :db_insert_placeholder_5, :db_insert_placeholder_6, :db_insert_placeholder_7, :db_insert_placeholder_8, :db_insert_placeholder_9); Array ( [:db_insert_placeholder_0] => 0 [:db_insert_placeholder_1] => php [:db_insert_placeholder_2] => %type: !message in %function (line %line of %file). [:db_insert_placeholder_3] => a:6:{s:5:"%type";s:6:"Notice";s:8:"!message";s:36:"Trying to get property of non-object";s:9:"%function";s:23:"_drupal_session_write()";s:5:"%file";s:50:"/home/content/39/8188839/html/includes/session.inc";s:5:"%line";i:175;s:14:"severity_level";i:5;} [:db_insert_placeholder_4] => 5 [:db_insert_placeholder_5] => [:db_insert_placeholder_6] => http://fishingtheusa.com.previewdns.com/admin/config/phpbb2drupal [:db_insert_placeholder_7] => http://fishingtheusa.com.previewdns.com/admin/config/phpbb2drupal [:db_insert_placeholder_8] => 208.109.80.102 [:db_insert_placeholder_9] => 1315273263 ) in dblog_watchdog() (line 157 of /home/content/39/8188839/html/modules/dblog/dblog.module).

Can that site connect to the same database?

Having a quick google suggests that this is because you are trying to access a remote address and your mysql.cnf may not be allowing that. (its a slightly different error, but it is available here: http://forums.mysql.com/read.php?52,152265,152265)

Maybe try making a local copy of your database to test this with?

So, are you saying that my Drupal database is not allowing a connection to my phpbb db? It is hosted at Godaddy so they might be blocking that. I thought the problem was on my phpbb side, but maybe not?????
I'm seriously considering setting up a server at home for a little while to get all of this running correctly!

The error is containing something about failing to read a communication packet.

Is your phpbb database hosted in the same place?

It could be an error with either the phpb database or the drupal server not being able to connect to it (basic security - don't let every external connection to the database work, just the ones that are set up to be accepted) or even a problem with this module.

You can test stuff on your home PC by isntalling wampserver: http://www.wampserver.com/en/ it has all you need and you just need to get a copy of your databases and upoad them to the local server and test with that.

I think I'm just going to dump the phpbb db and import it into the Drupal db just so it can access the tables. It should work like that I would think. I think the problem is on the GoDaddy side. I can connect to my phpbb db through a MySQL client, but I can't connect to the database on GoDaddy with the same client. If it's all local to GoDaddy, it should work.

@ resii (comment 100) - I assume you mean that all comments are mapped to the wrong user, while the nodes are to the right user?

I have committed some fixes here and you can test if it fixes the problem - it should.

I was able to import my phpbb tables into my Drupal database. I was able to get the connection properties set up properly. I am now getting errors when I try to import topics. I haven't applied your last commit though. How do I get that commit??? Here are the errors.........

PDOException: SQLSTATE[HY000]: General error: 1366 Incorrect integer value: '' for column 'last_comment_uid' at row 1: INSERT INTO {node_comment_statistics} (nid, cid, last_comment_timestamp, last_comment_name, last_comment_uid, comment_count) VALUES (:db_insert_placeholder_0, :db_insert_placeholder_1, :db_insert_placeholder_2, :db_insert_placeholder_3, :db_insert_placeholder_4, :db_insert_placeholder_5); Array ( [:db_insert_placeholder_0] => 23 [:db_insert_placeholder_1] => 0 [:db_insert_placeholder_2] => 1315711815 [:db_insert_placeholder_3] => [:db_insert_placeholder_4] => [:db_insert_placeholder_5] => 0 ) in comment_node_insert() (line 1298 of /home/content/39/8188839/html/modules/comment/comment.module)...

I am getting this error when I try to import users..................

•Notice: Undefined index: name in phpbb2drupal_user_save() (line 1015 of /home/content/39/8188839/html/sites/all/modules/phpbb2drupal/phpbb2drupal.module).
•PDOException: SQLSTATE[23000]: Integrity constraint violation: 1062 Duplicate entry '' for key 2: INSERT INTO {users} (uid, created, data) VALUES (:db_insert_placeholder_0, :db_insert_placeholder_1, :db_insert_placeholder_2); Array ( [:db_insert_placeholder_0] => 24 [:db_insert_placeholder_1] => 1315717964 [:db_insert_placeholder_2] => a:9:{s:16:"ckeditor_default";s:1:"t";s:20:"ckeditor_show_toggle";s:1:"t";s:14:"ckeditor_popup";s:1:"f";s:13:"ckeditor_skin";s:4:"kama";s:15:"ckeditor_expand";s:1:"t";s:14:"ckeditor_width";s:4:"100%";s:13:"ckeditor_lang";s:2:"en";s:18:"ckeditor_auto_lang";s:1:"t";s:7:"contact";i:1;} ) in drupal_write_record() (line 6861 of /home/content/39/8188839/html/includes/common.inc).
..

The second error (comment 108) is one you will run into when running user import twice into the same drupal database.

What version of phpbb are you trying to import from?

Latest current snapshot: http://drupalcode.org/project/phpbb2drupal.git/snapshot/24525bf.tar.gz

@ #106
yes, that is what I mean :-) I experienced that with a snapshot from the version from 2011-08-15.

With the newer Versions I get this Error:

Error message
Strict warning: Only variables should be passed by reference in phpbb2drupal_import_users() (line 336 of C:\xampp\htdocs\drupal\sites\all\modules\phpbb2drupal-24525bf\phpbb2drupal.module).
Notice: Undefined index: name in phpbb2drupal_user_save() (line 1021 of C:\xampp\htdocs\drupal\sites\all\modules\phpbb2drupal-24525bf\phpbb2drupal.module).
Strict warning: Only variables should be passed by reference in phpbb2drupal_user_save() (line 1021 of C:\xampp\htdocs\drupal\sites\all\modules\phpbb2drupal-24525bf\phpbb2drupal.module).
PDOException: SQLSTATE[23000]: Integrity constraint violation: 1062 Duplicate entry '' for key 'name': INSERT INTO {users} (uid, created) VALUES (:db_insert_placeholder_0, :db_insert_placeholder_1); Array ( [:db_insert_placeholder_0] => 2 [:db_insert_placeholder_1] => 1315751893 ) in drupal_write_record() (line 6868 of C:\xampp\htdocs\drupal\includes\common.inc).

I started with a backup of the db that did not have any importing done. I'll grab the newer files and try them. I did grab the newer module file.

Phpbb version is the newest version of 3.

I'm pretty sure my db is clean and free from any incorrect imports. I have a backup that I keep going back to in order to try again. It looks like the other guy is getting similar errors?? There is still something that is not quite right.
Can you help? I really want to make this work.

I'm still getting these errors. I'm digging around in the users' tables in both databases and can't see what is being duplicated.........

•Notice: Undefined index: name in phpbb2drupal_user_save() (line 1015 of /home/content/39/8188839/html/sites/all/modules/phpbb2drupal/phpbb2drupal.module).
•PDOException: SQLSTATE[23000]: Integrity constraint violation: 1062 Duplicate entry '' for key 2: INSERT INTO {users} (uid, created, data) VALUES (:db_insert_placeholder_0, :db_insert_placeholder_1, :db_insert_placeholder_2); Array ( [:db_insert_placeholder_0] => 26 [:db_insert_placeholder_1] => 1316373367 [:db_insert_placeholder_2] => a:9:{s:16:"ckeditor_default";s:1:"t";s:20:"ckeditor_show_toggle";s:1:"t";s:14:"ckeditor_popup";s:1:"f";s:13:"ckeditor_skin";s:4:"kama";s:15:"ckeditor_expand";s:1:"t";s:14:"ckeditor_width";s:4:"100%";s:13:"ckeditor_lang";s:2:"en";s:18:"ckeditor_auto_lang";s:1:"t";s:7:"contact";i:1;} ) in drupal_write_record() (line 6861 of /home/content/39/8188839/html/includes/common.inc).
..

around line 435 of phpbb2drupal module try replacing

        // 'roles' => array(DRUPAL_AUTHENTICATED_RID),

with

        'roles' => array(DRUPAL_AUTHENTICATED_RID => DRUPAL_AUTHENTICATED_RID),

See if that makes a difference.

(you are importing into a clean drupal database where no previous imports have been done?)

I'm trying to run this using the 24525bf.tar.gz snapshot above. I entered the wrong password for the phpbb database user. I went back to fix the typo, and get an HTTP error:

Module CustomErrorModule
Notification SendResponse
Handler PHP53_via_FastCGI
Error Code 0x80070021
Config Error This configuration section cannot be used at this path. This happens when the section is locked at a parent level. Locking is either by default (overrideModeDefault="Deny"), or set explicitly by a location tag with overrideMode="Deny" or the legacy allowOverride="false".
Config File \\?\C:\inetpub\Drupal\web.config

This is on IIS (windows server 2008).

I can move the phpbb tables into the drupal database, but when I go back and Reset phpbb2 database url, I still get the above error. I've tried uninstalling the mod and reinstalling it, but I still cannot navigate to the config page to enter the db information. How do I either fix the error or fully uninstall it so I can import the tables into the drupal db and try again?

Thanks!

I'm almost positive it is completely free of any imports. I don't see anything in the db that would indicate that it does. When I do try, it does try to add one user ID into the php2bb_temp_user table. I have been going in and removing that and trying again at this point.
What tables should I look at to see if there are any duplicates?

When I make that change, I get this error............

•Notice: Undefined index: name in phpbb2drupal_user_save() (line 1015 of /home/content/39/8188839/html/sites/all/modules/phpbb2drupal/phpbb2drupal.module).
•Notice: Undefined index: label in entity_token_token_info_alter() (line 54 of /home/content/39/8188839/html/sites/all/modules/entity/entity_token.tokens.inc).
•Notice: Undefined index: label in entity_token_token_info_alter() (line 59 of /home/content/39/8188839/html/sites/all/modules/entity/entity_token.tokens.inc).
•Notice: Undefined index: pass in phpbb2drupal_user_save() (line 1023 of /home/content/39/8188839/html/sites/all/modules/phpbb2drupal/phpbb2drupal.module).
•Notice: Undefined index: created in phpbb2drupal_user_save() (line 1024 of /home/content/39/8188839/html/sites/all/modules/phpbb2drupal/phpbb2drupal.module).
•PDOException: SQLSTATE[23000]: Integrity constraint violation: 1048 Column 'pass' cannot be null: UPDATE {users} SET pass=:db_update_placeholder_0, created=:db_update_placeholder_1 WHERE (uid = :db_condition_placeholder_0) ; Array ( [:db_update_placeholder_0] => [:db_update_placeholder_1] => [:db_condition_placeholder_0] => 28 ) in phpbb2drupal_user_save() (line 1027 of /home/content/39/8188839/html/sites/all/modules/phpbb2drupal/phpbb2drupal.module).
..

@ comment 117 - If you manually delete the imported users, the data will still be there in the index for the user table. You need to clear that too.

@ comment 116 - if you go to admin/phpbb2drupal, there is a cleanup link there that will delete the manually entered database credentials. click on that and you can go back to the config page to enter the correct credentials.

This does need to be looked at though - incorrect credentials shouldnt crash the page. Anyone have any ideas?

OK, Maybe it is an index issue. I didn't clean up the indexes. I'll try that and let you know!

Thanks

I tried that and it may have worked better. I need to take out the stuff that you had me add yesterday and try again............

PDOException: SQLSTATE[23000]: Integrity constraint violation: 1062 Duplicate entry 'user_yim' for key 2: INSERT INTO {profile_field} (title, name, explanation, category, page, type, weight, required, register, visibility, options) VALUES (:db_insert_placeholder_0, :db_insert_placeholder_1, :db_insert_placeholder_2, :db_insert_placeholder_3, :db_insert_placeholder_4, :db_insert_placeholder_5, :db_insert_placeholder_6, :db_insert_placeholder_7, :db_insert_placeholder_8, :db_insert_placeholder_9, :db_insert_placeholder_10), (:db_insert_placeholder_11, :db_insert_placeholder_12, :db_insert_placeholder_13, :db_insert_placeholder_14, :db_insert_placeholder_15, :db_insert_placeholder_16, :db_insert_placeholder_17, :db_insert_placeholder_18, :db_insert_placeholder_19, :db_insert_placeholder_20, :db_insert_placeholder_21), (:db_insert_placeholder_22, :db_insert_placeholder_23, :db_insert_placeholder_24, :db_insert_placeholder_25, :db_insert_placeholder_26, :db_insert_placeholder_27, :db_insert_placeholder_28, :db_insert_placeholder_29, :db_insert_placeholder_30, :db_insert_placeholder_31, :db_insert_placeholder_32), (:db_insert_placeholder_33, :db_insert_placeholder_34, :db_insert_placeholder_35, :db_insert_placeholder_36, :db_insert_placeholder_37, :db_insert_placeholder_38, :db_insert_placeholder_39, :db_insert_placeholder_40, :db_insert_placeholder_41, :db_insert_placeholder_42, :db_insert_placeholder_43), (:db_insert_placeholder_44, :db_insert_placeholder_45, :db_insert_placeholder_46, :db_insert_placeholder_47, :db_insert_placeholder_48, :db_insert_placeholder_49, :db_insert_placeholder_50, :db_insert_placeholder_51, :db_insert_placeholder_52, :db_insert_placeholder_53, :db_insert_placeholder_54), (:db_insert_placeholder_55, :db_insert_placeholder_56, :db_insert_placeholder_57, :db_insert_placeholder_58, :db_insert_placeholder_59, :db_insert_placeholder_60, :db_insert_placeholder_61, :db_insert_placeholder_62, :db_insert_placeholder_63, :db_insert_placeholder_64, :db_insert_placeholder_65), (:db_insert_placeholder_66, :db_insert_placeholder_67, :db_insert_placeholder_68, :db_insert_placeholder_69, :db_insert_placeholder_70, :db_insert_placeholder_71, :db_insert_placeholder_72, :db_insert_placeholder_73, :db_insert_placeholder_74, :db_insert_placeholder_75, :db_insert_placeholder_76); Array ( [:db_insert_placeholder_0] => YIM [:db_insert_placeholder_1] => user_yim [:db_insert_placeholder_2] => [:db_insert_placeholder_3] => Contact [:db_insert_placeholder_4] => [:db_insert_placeholder_5] => textfield [:db_insert_placeholder_6] => 0 [:db_insert_placeholder_7] => 0 [:db_insert_placeholder_8] => 1 [:db_insert_placeholder_9] => 2 [:db_insert_placeholder_10] => [:db_insert_placeholder_11] => AIM [:db_insert_placeholder_12] => user_aim [:db_insert_placeholder_13] => [:db_insert_placeholder_14] => Contact [:db_insert_placeholder_15] => [:db_insert_placeholder_16] => textfield [:db_insert_placeholder_17] => 0 [:db_insert_placeholder_18] => 0 [:db_insert_placeholder_19] => 1 [:db_insert_placeholder_20] => 2 [:db_insert_placeholder_21] => [:db_insert_placeholder_22] => icq [:db_insert_placeholder_23] => user_icq [:db_insert_placeholder_24] => [:db_insert_placeholder_25] => Contact [:db_insert_placeholder_26] => [:db_insert_placeholder_27] => textfield [:db_insert_placeholder_28] => 0 [:db_insert_placeholder_29] => 0 [:db_insert_placeholder_30] => 1 [:db_insert_placeholder_31] => 2 [:db_insert_placeholder_32] => [:db_insert_placeholder_33] => Website [:db_insert_placeholder_34] => user_website [:db_insert_placeholder_35] => [:db_insert_placeholder_36] => Contact [:db_insert_placeholder_37] => [:db_insert_placeholder_38] => url [:db_insert_placeholder_39] => 0 [:db_insert_placeholder_40] => 0 [:db_insert_placeholder_41] => 1 [:db_insert_placeholder_42] => 2 [:db_insert_placeholder_43] => [:db_insert_placeholder_44] => Location [:db_insert_placeholder_45] => user_from [:db_insert_placeholder_46] => [:db_insert_placeholder_47] => Personal [:db_insert_placeholder_48] => [:db_insert_placeholder_49] => textfield [:db_insert_placeholder_50] => 0 [:db_insert_placeholder_51] => 0 [:db_insert_placeholder_52] => 1 [:db_insert_placeholder_53] => 2 [:db_insert_placeholder_54] => [:db_insert_placeholder_55] => Occupation [:db_insert_placeholder_56] => user_occ [:db_insert_placeholder_57] => [:db_insert_placeholder_58] => Personal [:db_insert_placeholder_59] => [:db_insert_placeholder_60] => textfield [:db_insert_placeholder_61] => 0 [:db_insert_placeholder_62] => 0 [:db_insert_placeholder_63] => 1 [:db_insert_placeholder_64] => 2 [:db_insert_placeholder_65] => [:db_insert_placeholder_66] => Interests [:db_insert_placeholder_67] => user_interests [:db_insert_placeholder_68] => [:db_insert_placeholder_69] => Personal [:db_insert_placeholder_70] => [:db_insert_placeholder_71] => textfield [:db_insert_placeholder_72] => 0 [:db_insert_placeholder_73] => 0 [:db_insert_placeholder_74] => 1 [:db_insert_placeholder_75] => 2 [:db_insert_placeholder_76] => ) in phpbb2drupal_import_users() (line 331 of /home/content/39/8188839/html/sites/all/modules/phpbb2drupal/phpbb2drupal.module)...

Nope, even after cleaning the db, and taking out the stuff I put in yesterday, I still get that error now.

Can you please try with a pristine copy of the drupal database?

It seems that here, there is preexisting data from a previous attempt in the profile_field table.

With this module, you WILL need to have a database backup of the drupal database and be willing to return back to it multiple times in order to overcome all the various issues.

I was able to run the conversion on a drupal 6 site using the older phpbb2drupal tool, then upgrade to 7, but I don't think the site migration goes quite as smooth as it ought to (not the forums so much as just stuff in general).

I tried the cleanup link, that didn't clean it up.

Would it not be a good idea to create a 7.x-dev Branch of this module?
Then we should start creating new tickets with problems in the 7.x-dev branch.. this thread is going to be very confusing...

I'm going to test the current state in the comming week and I'll post what is going wrong..

Is it just me or are the downloads corrupted? I tried grabbing the mod as is, but files were corrupted. Tried GIT but no good there either. Am I missing something?

From Firefox 7:

• Corrupted Content Error
• The page you are trying to view cannot be shown because an error in the data transmission was detected.
• The page you are trying to view cannot be shown because an error in the data transmission was detected.Please contact the website owners to inform them of this problem.

I've re-attempted an import. Some notes here:

https://github.com/wu-lee/phpbb2drupal/wiki/Import-notes

And some patches to follow when I get more time.

For others who are attempting to debug this module, but are not experienced PHP developers, here are a couple of tips I found useful:

• Quick-and-Dirty Debugging
• the PHP error_reporting function and E_ALL
• the drupal debug() function

In particular, the lullabot site shows how to get full stack traces out of drupal error messages, and one of the comments shows how to log values to a file on the server you can inspect after a failure. Only by using this latter tool was I able to figure out to fix things such that this module imports my database successfully.

I say "successfully", but I will have to go back and do it again, I suspect the earlier import failures left debris which screwed up later imports.

HTH, more later when I get time.

Ok - another import trial later: with some fixes to the module I've managed to get it to import the data without mishap.

In earlier attempts I also encountered what looks like the bug donwiggins mentions in comment #108 ("Integrity constraint violation: 1062 Duplicate entry '' for key 2"), but I think I have fixed it, along with some other problems, and some suggested adjustments to the text. These fixes are published on the 1033316-wu-lee-fixes branch here:

https://github.com/wu-lee/phpbb2drupal/tree/1033316-wu-lee-fixes

@nbz, I recommend merging them like this, to retain the individual commits and their messages in your repository rather than flattening them together into one big delta:

git clone http://git.drupal.org/project/phpbb2drupal.git
cd phpbb2drupal/

# create a remote connection, get the data
git remote add wu-lee git@github.com:wu-lee/phpbb2drupal.git
git fetch wu-lee

# merge my fixes into master.
git checkout master
git merge --no-ff --log wu-lee/1033316-wu-lee-fixes

Although (hooray!) the merge now succeeds without errors, the conversion still isn't quite correct.

• Links in the "Topic" column on a forum listing showing who started a thread show the right user name, but actually link to the wrong user - the wrong links always seem to be to the same user as the user linked in the "Last reply" column.
• Topic import reports "Could not find post details of topic: XXX" for a number of topics, which also happen to be the only ones with phpbb_topics.topic_status = 2 and phpbb_topics.topic_moved_id != 0. I think they are shadow-copied topics. Should I be worried about this, or is it just removing duplication? Is some sort of shadow-copy retained in the Drupal conversion?
• custom bbcodes like [googleplace] defined in phpBB are not translated to html. remain as-is.

Any pointers to starting points addressing these appreciated.

EDIT - now merged into master and pushed. I have also created the 7.x-1.x-dev branch.

Links in the "Topic" column on a forum listing showing who started a thread show the right user name, but actually link to the wrong user - the wrong links always seem to be to the same user as the user linked in the "Last reply" column.

Could this be an issue with the theme you are using as opposed to a problem with the actual import?

Sorry, I gave you the authenticated git URI instead of the public one, git://github.com/wu-lee/phpbb2drupal.git

Re: theme - I'm not certain, but I suspect not since I'm using the default theme in Drupal (whatever that's called) - i.e. I've not changed anything, the import is into a fresh install of Drupal 7.8. Hopefully there's enough info to replicate what I did (minus he data itself) in the import notes.

Links in the "Topic" column on a forum listing showing who started a thread show the right user name, but actually link to the wrong user - the wrong links always seem to be to the same user as the user linked in the "Last reply" column.

For those topics can you have a look at the node_comment_statistics
table and see who the last_comment_uid is saved as?

Worst case scenario, we will need to add a hack after line 907 of the
phpbb2drupal.module fiule to manually to update this column.

Either that or there is a bug in our import code which we can find.

For those topics can you have a look at the node_comment_statistics
table and see who the last_comment_uid is saved as?

In the node_comment_statistics the records for the misbehaving forum nodes (which I suspect is all of them) have last_comment_id set to the UID of the last commenter, as named and linked correctly in the "Last reply" column (unless there is only one post, in which case there is no link).

It is not clear where the "By ..." links in the "Topic" column are getting their UIDs from. The correct user name is used, but the link is to the last_comment_id user.

Now here's the rub: if I create a new forum topic as "admin" and add a reply as another user "joe", then this has the same problem. The "By admin" link links to joe's profile.

This suggests it's a bug in the forum module. Looks to me like it's this bug here, and a fix exists which will supposedly be applied in D7.9.

I tried using the current git and dev coded versions of this module and this is the error I get trying to import users

Strict warning: Only variables should be passed by reference in phpbb2drupal_import_users() (line 336 of /var/www/localhost/htdocs/drupal_test/sites/all/modules/phpbb2drupal/phpbb2drupal.module).
Strict warning: Only variables should be passed by reference in phpbb2drupal_user_save() (line 1024 of /var/www/localhost/htdocs/drupal_test/sites/all/modules/phpbb2drupal/phpbb2drupal.module).
PDOException: SQLSTATE[HY000]: General error: 1366 Incorrect integer value: '' for column 'created' at row 1: UPDATE {users} SET pass=:db_update_placeholder_0, created=:db_update_placeholder_1 WHERE (uid = :db_condition_placeholder_0) ; Array ( [:db_update_placeholder_0] => $H$9fqqSPzhR.d1W1iyk/PpLfox5b0JkG/ [:db_update_placeholder_1] => [:db_condition_placeholder_0] => 2 ) in phpbb2drupal_user_save() (line 1036 of /var/www/localhost/htdocs/drupal_test/sites/all/modules/phpbb2drupal/phpbb2drupal.module).

subscribe

I tried to run the module and received the following error,

http://aquickstop.com/admin/config/phpbb2drupal

Error message
PDOException: SQLSTATE[42S02]: Base table or view not found: 1146 Table 'aqu1128608504454.filters' doesn't exist: SELECT COUNT(*) FROM {filters} WHERE module = :module AND format = :format; Array ( [:module] => bbcode [:format] => filtered_html ) in phpbb2drupal_admin_settings() (line 256 of /home/content/49/6536949/html/aquickstop-com/sites/all/modules/phpbb2drupal/phpbb2drupal.pages.inc).
The website encountered an unexpected error. Please try again later.

I am in the code now, trying to figure out what to change as this is stopping me in the admin, so i cant even change settings.

I did make a mistake with the database in that I did not have the four tables moved into the drupal database (still not 100% sure I should, but doing it now)

Any guidance would be great.

From reading it appears I will lose the passwords due to the different type of password handling hash vs drupal method???

My goal is to move about 40 users and about 2000 posts. just big enough that I don't want to do it manually, but its starting to feel like the amount of time with the process of automation may end up to be a wash compared to manual method.

thank you

i found what I believe is the problem with "PDOException: SQLSTATE[42S02]: Base table or view not found: 1146 Table 'aqu1128608504454.filters' doesn't exist: SELECT COUNT(*) FROM {filters} WHERE module "

it should be FILTER not FILTERS

new error now, will start looking in .module

PDOException: SQLSTATE[23000]: Integrity constraint violation: 1062 Duplicate entry '2' for key 1: INSERT INTO {phpbb2drupal_temp_user} (user_id, uid) VALUES (:db_insert_placeholder_0, :db_insert_placeholder_1); Array ( [:db_insert_placeholder_0] => 2 [:db_insert_placeholder_1] => 1 ) in phpbb2drupal_import_users() (line 342 of /home/content/49/6536949/html/aquickstop-com/sites/all/modules/phpbb2drupal/phpbb2drupal.module).

@ comment 136 - pushed the fix and this should be available in the next dev nightly release.

@ comment 137 - is this a second import attempt on the same database? if so, this is not supported because certain remnants always remain when trying to clear up the results of the original failed import. Try starting again from a pristine drupal database.

Thanks NBZ,

found another 'bug' with the url redirect. phpbb_redirect.module is selecting from "comments" table but should be "comment" table. line 72, 80

not an error, but for those that may need to change the directory path (p2d uses /forum) line 36 and line 42, 104 I believe should be changed to reflect the actual path. I have no idea how long or difficult it would be but if the path could be entered into the setup form it would be nice.

the redirects don't appear to be working for me. http://aquickstop.com/viewtopic.php?f=4&t=256 should be the same as http://www.paid2trade.com/viewtopic.php?f=4&t=256

"The page you requested does not exist. For your convenience, a search was performed using the query viewtopic.
Page not found "

ive fixed the two uses of {comments} in phpbb_redirect.

The other step is a feature request as opposed to a simple port and two hackish way of getting around with it for now are:

1. hack the module to always change that to the correct url of the old forums.
2. use apache redirect rules to redirect from the old forum to the new one and then let this module complete the process.

Thanks NBZ

since i dont know how to define apache redirect I am working on changing the module code. I just did a test with http://aquickstop.com/viewtopic.php?f=3&t=325 and on the top left corner you should see (i believe) 325 = post id. I am using a simple echo at the end of the code. i get the following error message.

"Error message
Notice: Undefined variable: post_id in include_once() (line 109 of /home/content/49/6536949/html/aquickstop-com/sites/all/modules/phpbb2drupal/phpbb_redirect.module)."

I am more or less over my head trying to figure it out as I go along. the test was to see if the variable is getting populated from the url string but I still am not sure due to the error (I guess I may need to define it)

after taking a look into the code I settled with this (i left the rest alone but added this at the very end)

if (isset($_GET['t']) && is_numeric($_GET['t'])) {
$topic_id = $_GET['t'];

// $nid = db_query('SELECT nid FROM {phpbb2drupal_temp_topic} WHERE topic_id = :topic_id', array(':topic_id' => $topic_id))->fetchField();
$nid = db_query('SELECT nid FROM {phpbb2drupal_temp_topic} WHERE topic_id = 325', array(':topic_id' => 325))->fetchField();

header('HTTP/1.1 301 Moved Permanently');
drupal_goto("node/$nid");

}

This appears to be working and I have not found an issue YET. I don't know enough php to know what I may broke, but I do know enough to break things.....

I have a lot of work to do yet. I had to turn off changing the bbcode to html due to an error. so all the posts that had it (lucky not many) will have to be filtered

also a lot of posts (especially replies) didn't seem to make it. While it was not a total success, I consider the migration a success in that in was much faster than manually having it done (or paying to have it done)

Another thanks to those that took the time to write the code. hopefully my add on here will help someone else too.

its standard to not change the bbcode to html - just add the bbcode filter to the default filter format and the bbcode should start working.

in your code snippit, it seems you have hard coded topic 325, so it may not work for all others?

Apologizing up front, it won't be a proper patch, just collecting what I experienced during a migration.

phpbb2drupal.module, line 719 (original version gives "Parameter was not defined" errors):

$files = db_query('SELECT * FROM {attachments} a WHERE a.post_msg_id = :a.post_msg_id', array(':a.post_msg_id' => $topic->topic_first_post_id));

to

$files = db_query('SELECT * FROM {attachments} WHERE post_msg_id = :post_msg_id', array(':post_msg_id' => $topic->topic_first_post_id));

phpbb2drupal.module, line 725, 728 (table name is different in D7):

$id = db_insert('files')->fields(array(
...
'filepath' => substr( $file_path . $file->physical_filename, 0, 255),

to

$id = db_insert('file_managed')->fields(array(
...
'uri' => substr( $file_path . $file->physical_filename, 0, 255),

phpbb2drupal.module, line 735 (no longer present in D7), remove:

$fid = db_last_insert_id('files', 'fid');

the db_insert() itself just above returns the last id.

phpbb2drupal.module, line 737:

{upload} table is removed from later D7.

Lines 908, 913, 917 are similar to the ones above.

{comment_upload} table is also non-existent.

The whole file import code is broken and not ported over from drupal 6.

in the code, there is a link to a guide to creating programattic nodes in drupal 7 which includes sample code that may be able to be dapted to import the files data too.

It still seems to work, with the modifications noted above. I'm somewhere in the middle of porting the posts themselves but what I've seen so far is all right. I'm only working on a double copy (both the PHP2BB and the new Drupal sites are just test sites, so I can test them thoroughly and without any fear of breaking things).

But anyway, I'll need to port the forum all right, so I'm more than willing to contribute to the effort. I'll report back later when all posts have been transferred (there are around 50,000 in this site now).

ok, as for comment_upload - that is now non existant and not needed.

what you need to do is to add a file field to a comment and then import the data into there.

Ideally we should have an option on the settings page to choose *which* filefield we import into, but that can be done once the actual code works for a dumber case.

I'm back. Me likes what me sees... :-)

The forum went on after I made a backup of its database but this only can amount to a couple dozens posts. Out of the current ~56,000, I received 51,387 after migrating. Users are all right, content is mainly OK (no error in what I could see, just this missing few topics, I did get warnings about some missing topics, that should account for it).

Now that I know it's not yet ready for prime time but getting close, I move all the data under a test site in a virtual machine and will test it again locally, with a smaller database for sure.

From a cursory look into the update script in system.install, the field is determined for us, we should use what the core uses for this purpose. I'll look into this but I'd probably need some help on the phpBB side (eg. how it stores attachments and similar) because I never actually went near it.

The original forum had a hierarchy of forums and topics, this was not translated to containers and forums inside. Could that be an error in the module or simply the original forum wasn't set up correctly? The fact that I don't know phpBB starts to show... :-)

In relation to attachements, in PHPBB they are stored in an attachements table under a randomly generated name. That table also stores the original name and the post or topic it is linked too. All the actual files are stored in a /files/ directory under the phpbb root.

Good eve everyone, great to see the devs of this module still working hard at getting it going. I've got a few questions.

First question, currently I am running a Joomla site with phpBB forums. I have decided and am completely committed to moving my site from Joomla/phpBB to Drupal. Integration would work unfortunately phpbb3forum is quite the feat for a none coder like my self, (hell I understand Drupal is as well, but I have enough friends that can offer assistance whenever they can, but that is besides the point) Currently my plan is to use Joomla2Drupal to convert all the content and users, would anyone know of a reason, phpbb2drupal would cause a problem if I use Joomla2Drupal's user import instead of phpbb2drupal.

Now this has to do with forum posts, posting numbers, etc.

My second question, this goes along with my migrating the forums first. phpbb2drupal is setup and ready to start pulling data across my databases. (I had quite a few problem, but got it working) when I run the import users, it only pulls 100 or so users then does one of two things. It either gives me a Internal Server Error, or it goes back to the Execute Migration page.

If I remember correctly the reasoning for this is because I am using a godaddy host (yes shun me now) and it doesn't allow imports of Databases larger than 1 meg.

My Final question is this, would I have more luck with using this tool by pulling my phpbb database into my drupal database via a bigdump.

Any help with these questions would be greatly appreciate.

Thanks,

Samm

OK. I'll contact you off this issue queue if you don't mind, with smaller things as I go on. I only have time to start to test it under a VM from now.

Hi.

I've been working on a Migrate based module to do this work. My version doesn't have a UI so far, so is very much a developer tool, but used a lot of the ideas for data clean up from this module. I'll release it at some point soon.

Also, at over 150 messages, it might perhaps be time to stop this thread altogether and post individual issues to the issue queue so they can be assigned to developers (to prevent overlap and redundant work) and keep things clearer for people.

Cheers.

So I've been working hard at getting this to work for D7, it appears that I am unable to complete the task. I can pull roughly 100 users before it either kicks me back to the import user page or gives me a 500 internal server error. Forgot to add a bit here. I have tried this both with the phpbb_ database being in the same database as the drupal one and it being an external database.

I would much rather use this tool than embed phpbb into the site. So any help would be greatly appreciated.

Samm.

Likely you're script is timing out. Are you trying to run it on shared hosting?

Take a copy of everything to a local install and try again. If for no other reason than to rule out any issues with a shared host.

Not a bad idea darksnow.

My mind is so blargged right now I didn't even think about that. I'll give that a shot.

With reference to #81 and the subsequent discussion about migrate support...

I've created a migrate based module to do what I needed. I've cleaned it up a bit and put it in a sandbox.

http://drupal.org/sandbox/darksnow/1353038

I dunno if this gives some people ideas about how to integrate the work of this module with the framework provided by the migrate module, but it's working for me.

It was done mainly as a learning exercise for me, my first complete module.

Cheers.

Can you give a brief overview of the modules current capabilities?

Does it migrate the files or the poll data? (this module currently does neither, so either one of them is a big win.)

I'm experimenting with it right now, on a test server. Yes, it migrates all the files. And it's nothing short of fantastic... ;-))

I've not had a look at Polls yet but it's on the list.

I'm also planning an optional migration of Smilies and custom BBCode.

Attachments get migrated into a file field attached to the forum posts, though I think there's a better way to do this, connected to how the Media module handles media embedded in content, which is what I think we're after with attachments.

Anyway, a brief overview of the system's capabilities is now on the projects page.

Cheers.

• Import of any custom BBCode to BBCode module
• Import of any custom smilies

Unless you intend to convert these into html, all you really need to do is to tell the admin to turn on these filters in the text format that the content is using.

While that's true, what I was planning on porting over were the custom codes added by phpbb admin. The smilies module allows the import of smiley paks, so I presume I can import any custom smilies into that, but the BBCode module doesn't allow me to add any custom tags.

For example, I have [youtube] and [vimeo] tags that allow me to embed video clips. While these can be handled by Media now (which is maybe the best way) some people might have custom bbcodes not currently supported by the BBCode module.

I migrated almost all the site, the remaining problem is with attachments. Judging from the error messages (I haven't yet had the time to go deeper into the code), it looks for the real image names in the original phpbb folder and reports them missing. What is true, certainly, because those files still have the random generated phpbb names there.

so as now this new module (darksnow's) imports&renames&moves the attachments in the right folder automatically or this function is not ready yet?

- if there was a complete module to migrate all phpbb3 functions (especially attachments/files and forum hierarchies) all automatically, I would have converted my two phpbb forums to drupal years ago :)
(then there would be those small things like custom bbcode and smilies and I would be super happy)

I have a crazy nested forum that had troubles to keep the hierarchy(categories/subforums) when importing with php2drupal module and another that migrating it without working attachments it would not make sense.

---
btw thanks darksnow for your new module! I'm following your progress and nice you're making it for D7.

Well, sure, it should do it but I'm struggling with it right now... Martin, where are ya when the country needs ya? ;-))

@162 - have you looked at the xbbcode module (not on drupal.org as the author does not want to confuse users...: http://ermarian.net/downloads/software/drupal/xbbcode/)?

I have not used it but I think it allows you to create custome bbcode tags like you want.

Oops: it's not yet documented, I found it in the code:

// TODO: Automatically rename the files on disk before starting. Currently done by drush command.

So, off to drush-land, I'll report back.

Sorry, I was sort of expecting feedback in the other project page.

There is a drush command I wrote which uses the phpbb attachments table to rename all the files before the import takes place. Since drush must be run within the Drupal install, you need to pass it the full path to the attachments directory. This operation can also be undone. Just type in drush and it will tell you the command (they should be the last ones in there).

I will get around to documenting all this (unless someone else wants to do it ;)) but I'd like to finish it first.

I've been looking at polls and I think I'll go with pollfield as a target. There is a smileys module to target but I'm not so sure about custom BBCode, perhaps it would be better to convert most BBCode to HTML and provide a hook to allow a developer to write a conversion routine for any custom BBCode they have.

Anyway, part of the reason for making a whole new module was to get away from this stupidly long thread ;)

I'm glad my work has been of help to some already.

I have no Drush on that particular site and not even SSH access, so it won't be easy to solve in a matter of minutes. If would be nice to find another solution but I ran into problems in the phpBB database. I'll go on with the problems over there...

Decided to go with a fresh install of drupal, getting this error now.

Strict warning: Only variables should be passed by reference in phpbb2drupal_import_users() (line 336 of C:\xampp\htdocs\oldrep\sites\all\modules\phpbb2drupal\phpbb2drupal.module).

Does anyone have a fix for this.

I'm getting about 250 users to go now. Also is there a version newer than what is on the site or is the November version the best we have right now.

Hi,

Can you post what versions you used? both drupal and phpbb? It just wont work for me - I have raised another bug report.

Thanks,

Paul.

I'm using the 7.x dev version of phpbb2drupal and 7.10 version of Drupal.

After looking into the problem a bit. I have found that this line is causing the problem...

  if (!($user = array_shift(user_load_multiple(array(), array('name' => $phpbb_user['name']))))) {
    $account = new stdClass();
    $account->uid = FALSE;
    $user = user_save($account, $phpbb_user);

Please try the phpbb3 import module by darksnow to see if that lets you get further.

phpbb3.0.7-PL1, 2 years old, a few mods & Drupal 7.10, Fresh Install, just to see if I can do the import.

After configuration, I tried to import the users. It said something like 250 whatever users, Beginning Import. However, no import happened. No time-outs, nothing. Still only my admin account. I then got this error after trying again:

PDOException: SQLSTATE[23000]: Integrity constraint violation: 1062 Duplicate entry '2' for key 1: INSERT INTO {phpbb2drupal_temp_user} (user_id, uid) VALUES (:db_insert_placeholder_0, :db_insert_placeholder_1); Array ( [:db_insert_placeholder_0] => 2 [:db_insert_placeholder_1] => 1 ) in phpbb2drupal_import_users() (line 342 of /***/sites/all/modules/phpbb2drupal/phpbb2drupal.module).
The website encountered an unexpected error. Please try again later.

I understand this happens when you try to import a 2nd time, according to above comments.

It DID import the profile fields (yim, msn, occupation...) but that's it. No actual accounts were imported.

So I moved along anyways, just to see what I could get imported. I went to "Import Categories"

Forum vid: 2Says okay, but I don't know what this means.

Then the error.

Error messagePDOException: SQLSTATE[HY000]: General error: 1366 Incorrect integer value: '' for column 'parent' at row 1: INSERT INTO {taxonomy_term_hierarchy} (tid, parent) VALUES (:db_insert_placeholder_0, :db_insert_placeholder_1); Array ( [:db_insert_placeholder_0] => 6 [:db_insert_placeholder_1] => ) in taxonomy_term_save() (line 645 of /***/modules/taxonomy/taxonomy.module).
The website encountered an unexpected error. Please try again later.

Again, something imported. The top level categories imported, however the subcategories did not. Therefore, moving on to importing topics would be a waste.

But I will anyways, because I'm stubborn like that. No errors.

Execute Migration
Status message Found 1763 topics: Beginning Import

No topics, either. As expected.

Needless to say, I have NOT gotten this to work. I even did it from another browser... just in case.

Did I miss anything? The to-do list, where I put all the phpbb information suggested that it was all good to go.

I have just committed the 7.x-2.x branch of this code.

It is a copy of my sandbox project from http://drupal.org/sandbox/darksnow/1353038

It uses the migrate module, as detailed above in #157 and on the sandbox page. There were a number of issues being worked on in the sandbox, which I would appreciate if they could be reported again, against the correct branch of this module.

I would also rather that this thread be stopped since it's getting very big and any specific issues with the new migration be added as individual issues.

Thanks.

that's nice. is not like there aren't followers or future users of this module. I'm following quietly and I'm sure others too.
I'm not a programmer so I can't help with code, but when those issues will be ironed out and a dev will be out, I'll try it and report.

I'm bored of phpbb3 and to manually edit its code for plugins that at every update give me a lot of troubles, so I'd like to move and it's bad for drupal that there wasn't a good and stable migration module for it until now.
This will be a great and useful module.
subscribing this and your sandbox.

The last checking appears to be November?

The check in I did can be seen here:
http://drupalcode.org/project/phpbb2drupal.git/shortlog/refs/heads/7.x-2.x

I'm planning on cleaning up two things (repeated first post bug and use of media for attachments) then I'll do a dev release.

The reason it says November looks like a mix up with my local setup for git which is using a different email address than the one registered here. Hopefully my next check in will sort all that out.

Is there any forward progress on this? This module is fantastic, but I'm stuck on importing attachments as media entities on comments.

PHP Fatal error:  Unsupported operand types in /sites/all/modules/migrate/plugins/destinations/file.inc on line 486
PHP Fatal error:  Class name must be a valid object or a string in /sites/all/modules/migrate/plugins/destinations/file.inc on line 563

If anyone has any direction I would appreciate it.

I am looking into integrating or importing an existing phpBB forum to a Drupal 7 site.

Is the php2drupal Drupal 7 port fully functional at the moment or should I use a bridge solution until there is a stable release?

Thank you

I would advise you to try it on a site copy - I would suspect that this is the way to go and way better than any bridge solution, but it depends on your needs.

I'm a bit worried that the documentation link for this module lists so many workarounds and advises an approach of multiple backups and retries till everything is imported. Would you say that there are no serious issues at the moment?

This is the type of module that peopel only need to use once and if there are issues that arise, they will only by found by trying the module.

So make a backup and see what happens.

And since the module does alter database data, it cannot be emphasised enough to have multiple backups and retries - it is the only way for this type of module where you import data in one go while transforming it. If anything goes wrong, you cannot undo the changes, but restart from a prestine backup.

Sorry I've been away from this for so long. I received a couple of email about it which I'm addressing.

As NBZ has said, this is the sort of module people use once and never again. As such, I've not used it since the last time I talked about it, which is a very long time ago now.

I'd love to get this into a perfectly working solution that any end user could use but the fact is, something will always come up and this is the sort of module that the developer of a new site should be using, and even if I, or somebody else, committed a lot of time and code to this project it may never work properly.

Having said that, some people have offered code to this module so I'll have a look and see if we can move this forward.

Sorry for any inconvenience caused but my use of this module has passed and I have very little time to give these days.

DarkSnow.

I am fixing a few bugs for this at present.

I started with D7 and this module and with some teething issues I managed to get data imported. I don' t know how well the D6 version worked to compare.

If people could test the current code and raise new issues under 7.x-2.x-dev rather than this thread that would be great. I will try and track and fix while I am working on my current migration project.

Could you mention the teething issues you encountered and how you overcame them, as a reference for the rest of the community (in a new thread)?

I'm still trying to decide between this module and a bridge solution...

Thanks!

Mostly the issues i had were with regards to the avatar importing. Before that was fixed I just blanked the avatar field in the database.

Also had to make sure users had permission to create direct messages otherwise they wouldn't save. Other than that it worked pretty smoothly. Issues I had were with customizations to phpbb, which I wouldn't expect the module to fix.

Did you install additional modules to get the phpBB look'n'feel?

Again, if possible, please document the steps you followed (for the avatars, permissions, etc.) in a new thread if you have the time. Thanks!

first, thank you for taking care of this module, I have two forums to migrate, one full of attachments and thousands of users, so I'll try it soon.

I tried (months ago) the previous version but it had too many issues I couldn't 100% fix in short time, so I didn't migrate at the time.

---
I see you released a new dev version, gonna try it next days and report issues in detail in their own threads as you asked.

some generic questions i found in my 6 months old notes, next days I'll try your updated dev and try to explain them better.
- a problem I had was handling of attachments, there were two choices, with media module or without.

- drupal uses file_usage table in db to attach files to content, IIRC this module, when not using media module, wasn't doing this right but simply showing attachments with wysiwyg tags

there were some other issues, like with media module, table prefix, but those were fixed at some time.

I'll report soon.

Thanks, I need to check out attachments. Avatars were suffering some of the same issues and they seem better but that is something for my to do list.

I have fixed most of the simple issues. I am proposing that I release a 7.x-2.0 version. There are some other fixes I have in the pipeline but I would like to have a stable version out before I start committing them and I think another dev branch is overkill.

I am going to set this issue as fixed. If anyone has objections to a stable 7 release then please let me know and we can reopen this issue and address.

I don't want to reopen this issue but wanted to first apologise for being a bit of an absentee landlord of this module and thank Jeremy for taking over.

After my migration from PHPBB3 I addressed a few issues here then became really busy with numerous other projects, none of them using Drupal at all, so I sort of fell off the radar here.

It's a bit rubbish of me really, and the project I migrated too Drupal using this module has suffered as a result of my lack of maintenance.

So, huge thanks to Jeremy for taking this on. I rewrote the D6 version of this from scratch, using ideas and small snippets from the old code. If you come across anything that doesn't make sense or is not well commented enough, let me know and I'll see if I can offer any insights I can.

Cheers again Jeremy and good luck.

Thanks for all of your hard work with this. All that was needed in most places was a tweak or two.

Most things seem to be now working, other than some issues with files and with private messages of deleted users.