• 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

jeffwidman

Active member
#3
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.
 

Chris D

XenForo developer
Staff member
#4
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.
 

jeffwidman

Active member
#6
One which defines the tags (xf_tag) and this caches a few bits of data, e.g. last_use date use_count etc.
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.

and a second one which defines each time a tag is used (xf_tag_content).
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.
 

Chris D

XenForo developer
Staff member
#7
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).
 

jeffwidman

Active member
#8
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.
 

Chris D

XenForo developer
Staff member
#9
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.
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.

Plus if a tag importer gets added to core at any point, it'll need a way to rebuild the tag caches.
Certainly the importer would handle the rebuild of the tags caches itself, it wouldn't be a separate thing.

Agree with you that building it into the existing Threads rebuild option rather than a separate option is probably the cleanest solution.
We'll see how things go. I can probably point you in the right direction, at least, if we don't handle it ourselves.
 

jeffwidman

Active member
#10
I can probably point you in the right direction, at least, if we don't handle it ourselves.
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.

There's plenty of caches that work similar that don't have a rebuild.
Gotcha. I didn't realize that.

Certainly the importer would handle the rebuild of the tags caches itself, it wouldn't be a separate thing.
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
Alright, so I successfully converted the board over from vB 4.2 to XF, and now like to import the old vB tags.

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).
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.
 

adwade

Active member
#12
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?
 

Alfa1

Well-known member
#15
I had an vbulletin tags importer developed for me. If anyone wants to share in the costs then please contact me.
 

Alfa1

Well-known member
#19
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. :)