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

Implemented Import thread tags from vbulletin

Discussion in 'Closed Suggestions' started by Alfa1, Jun 25, 2015.

  1. Alfa1

    Alfa1 Well-Known Member

    It would be extremely useful if we could import tags from vbulletin. For example my site has 35,000 tags which we really need to keep. I'm sure there are many like me.
  2. Fred.

    Fred. Well-Known Member

    I agree, I would also like to import the tags that I had in vBulletin.
  3. jeffwidman

    jeffwidman Active Member

    Could this possibly be done as a SQL Query if you have a copy of the old VB database?

    Depends how it's implemented under the covers, but should be easy if it's just a xf_tag table with a foreign key to the xf_post table. Perhaps @Chris D could comment on that.
  4. Chris D

    Chris D XenForo Developer Staff Member

    There are two main tables.

    One which defines the tags (xf_tag) and this caches a few bits of data, e.g. last_use date use_count etc. and a second one which defines each time a tag is used (xf_tag_content).

    In theory it's relatively simple. So if we don't do it in the core, I'm certain thre are plenty of others who can do it as an add-on.
  5. Alfa1

    Alfa1 Well-Known Member

    Hopefully its simple enough to squeeze it in 1.5 beta.
  6. jeffwidman

    jeffwidman Active Member

    If I insert the tags with dummy values for the cached data, will the cached data get updated whenever the tag is next applied to a post?
    That'd work fine for me, at least until there was a 'rebuild tags' option in the 'rebuild caches' section of the ACP.

    Is this just a many-to-many association table with id, tag_id, post_id?

    If it's just these two tables, and dummy data is fine for cached values, then it's trivial to insert straight across from a VB database.

    Reason I ask here is I am planning to migrate a medium-sized VB4 forum to XF next week, but if it'll be possible to insert the tags straight across using the SQL queries I outlined above, then I'll wait until 1.5 lands.
  7. Chris D

    Chris D XenForo Developer Staff Member

    That should all work, but one issue is there's another cache I forgot to mention: there's a cache in the xf_thread table which is a serialized array of the tags used on each thread. That's probably key, in fact, as theoretically none of the tags will show without that.

    They will appear when you click on edit tags, and adding a new tag or editing the existing tags should rebuild the per thread cache (and indeed, yes, the last use date and use count etc. should rebuild too) but until then those tags won't be visible.

    Also it's not a given that we'd implement anything to rebuild the thread tags cache, so that would still likely require custom development. Though, at the same time, the code to rebuild tags might be easy enough to insert into the existing Threads rebuild, manually (if you're comfortable with that kind of thing).
    ForestForTrees likes this.
  8. jeffwidman

    jeffwidman Active Member

    Thanks Chris.

    Populating the xf_thread cache starts to sound like it may be more trouble than it's worth, I'll have to think on it. I just hate to lose any Google juice when I migrate and have tags.php* urls start throwing 404's. Even if I 302 them until a workaround comes out, it's still an inconvenience.

    Yeah, I understand you aren't promising anything to rebuild the thread tags. However, I'd be surprised if it doesn't get built into core at some point, it just seems like an obvious thing to do as a way to proactively head off bug reports when people complain their tags aren't working. Plus if a tag importer gets added to core at any point, it'll need a way to rebuild the tag caches.

    Agree with you that building it into the existing Threads rebuild option rather than a separate option is probably the cleanest solution.
  9. Chris D

    Chris D XenForo Developer Staff Member

    Well, that's a big "if". A rebuilder would be needed IF the thread tags cache isn't working for some reason or has the tendency to become outdated for some reason. With how this works, there's no reason to believe that would ever happen. There's plenty of caches that work similar that don't have a rebuild.

    Certainly the importer would handle the rebuild of the tags caches itself, it wouldn't be a separate thing.

    We'll see how things go. I can probably point you in the right direction, at least, if we don't handle it ourselves.
    ForestForTrees and Alfa1 like this.
  10. jeffwidman

    jeffwidman Active Member

    Thanks Chris. I'll probably ask for help on that xf_thread cache rebuild column once I actually migrate the board... it'll be easier to see what I do/don't need once I see what the DB data actually looks like. Normally I work in Python, never spent much time in PHP, so while I can sketch the general functions, the syntax details would take a bit for me to figure out.

    Gotcha. I didn't realize that.

    Not sure I understand why it's structured that way. I haven't looked at the underlying code, but I assumed if you're going to write a cache builder, might as well just build it into the existing cache rebuild tools and then have the importer queue up a delayed job that calls the generic cache rebuild functions... otherwise you potentially end up just repeating code or limiting cache rebuild tools to just the importer. You guys are smart enough to realize that; probably I'm not understanding some of the design tradeoffs.

    That said, don't worry about it, you've answered my questions at a detailed enough level for me to make decisions. I really appreciate that, and since I know you have limited time, I'd rather it's spent working on the product than satiating my curiosity here.
  11. jeffwidman

    jeffwidman Active Member

    Alright, so I successfully converted the board over from vB 4.2 to XF, and now like to import the old vB tags.

    I am comfortable inserting custom code into the PHP files, but most of my experience is in Python, not PHP, so not comfortable writing the actual code. I'm also comfortable writing the SQL queries to copy the data over into the normalized locations that the denormalized caches are built from.

    Any chance you can provide said custom code?

    I can write a quick how-to that includes the SQL queries, and I suspect there's a good number of owners who migrated from vBulletin who'd apply this, so I know I'm not the only one who'd benefit.
  12. adwade

    adwade Active Member

    I realize your import has been completed, but if the [Tinhte] XenTag add-on is installed before an import is performed, it's my understanding that vB TAGs will be imported into it. Then it seems one could use the XenTag Importer add-on to move the XenTags into XF's new core TAG system…is this correct?
  13. imthebest

    imthebest Formerly Super120

  14. Alfa1

    Alfa1 Well-Known Member

    ^This is incorrect. Xentags has no vbulletin tags importer for xf 1.5
    Only for vb tags into xentags for xf 1.3. (uses xentags system instead of xf tags)
    ForestForTrees likes this.
  15. Alfa1

    Alfa1 Well-Known Member

    I had an vbulletin tags importer developed for me. If anyone wants to share in the costs then please contact me.
  16. Slavik

    Slavik XenForo Moderator Staff Member

    Had or have?

    I have one available.
  17. Alfa1

    Alfa1 Well-Known Member

    Its completed now.
  18. Chris D

    Chris D XenForo Developer Staff Member

    Last edited: Feb 23, 2016
    jeffwidman and Alfa1 like this.
  19. Alfa1

    Alfa1 Well-Known Member

    Thanks for implementing it. I am sure many will enjoy it.
    Too bad that I had just hired a developer who created this importer to me, but so is live. :)

Share This Page