I almost don't know where to start... first of all, let me say due to time pressure we have gone live a few weeks ago, and there is no way I can re-import, or undo what has been done. Hopefully some things can be mended!

First off, we imported from PhpBB 3.0, and the forum and user import was a breeze, perfect.

However, the PM import was (and is) a mess. All deleted messages of years were imported as well, and all in one huge big thread. We only found out after we went live, since I (as the main tester) had never deleted messages and had only a few PM's to start with.

Also, I upgraded the privatemsg module to dev version of March 5, and all of a sudden I found out that MY own imported thread is not accessibly anymore, since it is shown as site/messages/view/0
I could (and can when I revert) still access it with the RC2 version of privatemsg, but not anymore.

Is there any way in which we can still split the message threads without jeopardizing the site, and equally important, can I get my thread back? If so, I would REALLY appreciate what can be done... thanks!

Comments

naheemsays’s picture

for the deleted messages, are the thread_id for them all set as 0?

What version of the phpbb2drupal module did you use? the beta2 I assume (as you have it set?)

and were any of the messages threaded in phpbb3?

if not, you can try to via phpmyadmin set the thread_id = mid for all the messages in the pm_index table. (Please try this on a test site first to make sure it works correctly).

Sophia’s picture

Some messages were threaded, and yes, I used the latest version of beta2 (Jan 16). However, threaded or not, they all ended up in one huge thread, one thread per user I might have to add.

I'll try the thread_id = mid fix on our test site, and let you know the results :) Oh boy, if this can be fixed, you just made 200 people VERY happy indeed :)

Edit: No, the thread id did go up, messages/view/1 messages/view/2 etc

Another edit: I have performed the thread_id = mid query, and this could certainly be an answer.... thanks for your help so far! I have put it before the group, I can't make this big decision on my own and they will have to tell me if that is what they want. After all, it really splits ALL the topics, threaded or not, new and otherwise... so it might not be what some of them want. But it's a start, and I wish to thank you for your help so far.

naheemsays’s picture

did you try

  UPDATE pm_index SET thread_id = mid;

? choose the sql tab and type that in followed by go or execute button.

Sophia’s picture

Yes, I did, nbz and thanks so much for your help. Would it be possible to do this on an individual basis, such as

UPDATE pm_index SET thread_id = mid WHERE uid = 5

Or something like that? Oh that would be the answer for sure... I wish I knew this weeks ago, my fault for not reporting it sooner :)

naheemsays’s picture

If the original solution works, then yes that would also work (but just for when the uid =5 as you wanted.).

Sophia’s picture

Great, you made my day :) Thanks again, oh one last question, could it be done with messages created before Feb 13 (the day of the move) only?

naheemsays’s picture

Title: PM import issues » Thread_id is not correctly set for imported threads
Version: 6.x-2.0-beta2 » master
Category: bug » task

Just updating the bug report.

I have (slightly earlier) committed a work around to HEAD for the above issue giving each message a unique thread_id( = mid) on import, but that is just a stop gap solution - in reality the code needs to be re factored to keep the correct threading as done by phpbb.

naheemsays’s picture

@ comment 13 - yes. Try something like

  UPDATE pm_index SET thread_id = mid WHERE (uid = 5 AND mid < 734)

Where 734 is the largest mid that was imported. If you do not know which it is, you may need to calculate it from the data in the pm_message table.

Sophia’s picture

Super! I have put it all before the group, and will let you know the result in a few days... thank you for all your help, and good luck with improving this awesome module!

Edit: I don't have to wait a few days... people love it. I am going to update the OLD forum threads into separate threads, and leave the new ones the way they are (threaded). Thanks again, and now I'll go back to nag the privatemsg people for separate folders instead of tags :) Teasing!

Sophia’s picture

Hi, it's me again, this time I am trying to convert Invision to Drupal. As far as I know, the only way is via phpBB.

After much headache I finally managed to export successfully to phpBB, and import to Drupal. Users and posts are imported flawlessly, however... I cannot import PM's. They display correctly in phpBB, and the tables seem in order.

But, when I convert to Drupal, the table pm_message gets filled with all messages, but the table pm_index is completely empty. Any idea how I can resolve this, are there any fields I need to pay attention to in the phpBB private message tables?

Thanks :)

naheemsays’s picture

hm... is there nothing at all in pm_index? not even junk data? or any error messages upon import?

it could be (but I doubt) a problem with the drupal_write_record... on lines 149 and 153 of phpbb2privatemsg.module there is the following:

  $result = drupal_write_record('pm_index', $message);

Can you try replacing both instances with:

  $result = db_query('INSERT INTO {pm_index} (mid, thread_id, uid, is_new, deleted) VALUES (%d, %d, %d, %d, %d)', $message['mid'], $message['thread_id'], $message['uid'], $message['is_new'], $message['deleted']);

and then re running the import of the private messages? It seems weird that the pm_index table was not populated...

Sophia’s picture

Hmm mmm mmm I must be doing something wrong :P I did manage to fill the pm_index, but all the messages seem shifted... user A has all of user B's messages etc. I shall do some more testing and I'll let you know the results...

EDIT: it is not the php2drupal module, but the Invision2phpBB where it goes wrong. This module still rocks :)

naheemsays’s picture

Status: Active » Fixed

http://drupal.org/cvs?commit=212660 should fix this, but is untested. If anyone has tested the new import code, please comment to confirm.

Status: Fixed » Closed (fixed)

Automatically closed -- issue fixed for 2 weeks with no activity.