1. This site uses cookies. By continuing to use this site, you are agreeing to our use of cookies. Learn More.

Fixed Edit History importer (vB) importing edits in wrong version order

Discussion in 'Resolved Bug Reports' started by AlexT, Jul 9, 2013.

  1. AlexT

    AlexT Well-Known Member

    After importing the edit history from vB (3.8 tested), the edits in the history are not in the correct order.

    Here is why:

    vB stores edits in its history table slightly differently than xF. Specifically, in vB, in the postedithistory table, in each row, pagetext refers to the current edit. In contrast, in xF, in the xf_edit_history table, in each row, old_text refers to the previous edit.

    Also, if you look at an imported edit history, you see that the first edit (in the bottom of the list), is always identical to the actual first post (in vBulletin in the postedithistory table it is referred to the "original" post).

    I have posted a code snippet that would import the edit history in the correct order and make sure that the edit labelled as "original" would not be imported as an edit.
    Hornstar, whynot and xf_phantom like this.
  2. AlexT

    AlexT Well-Known Member

    Something else:

    - Using the importer from 1.2b5, a post's edit_count isn't correctly set. The importer sets it either to 0 for no edits, or to 1 for one or more edits, rather than filling it with actual number of edits. This appears to be intentional (shortcut?).

    - Edits from the history aren't actually imported. This is a bug caused by this line (~2774):

    'old_text' => $this->_convertToUtf8($this->$edit['pagetext'])
    should be

    'old_text' => $this->_convertToUtf8($edit['pagetext'])
  3. Mike

    Mike XenForo Developer Staff Member

    The edit count thing is intentional (especially as the full data may have been pruned, so the edit history total may not be correct either).
  4. AlexT

    AlexT Well-Known Member

    I see. Mike, did you look at the code snippet I linked above? Rather than going through vB's postedithistory table by postedithistoryid, I processed the table by postid. This way, I know exactly how many edits are available per post (so a post's edit_count can be set correctly), and you can also shuffle around the pagetext to fix the versioning order.
  5. Kier

    Kier XenForo Developer Staff Member

    Should be all fixed now - I changed the approach to select all edits for batches of 100 posts, ensuring that we can manage them fully.
    Eagle, shenmuee, AlexT and 1 other person like this.
  6. AlexT

    AlexT Well-Known Member

    Kier, sorry to bring this one up again; I see in 1.2 RC you're importing the edit history sorted by postid now. Skimming the code, though, I don't see that the edit order within each particular post history hasn't been fixed.

    I haven't done a test import with RC, and perhaps I am wrong. :oops:
  7. Mike

    Mike XenForo Developer Staff Member

    The page text is offset by 1 edit ($pageText refers to the previous edit) so it should be ok.
  8. AlexT

    AlexT Well-Known Member

    Thanks Mike, it is a very elegant solution then.

Share This Page