Implemented Import thread tags from vbulletin
- Thread starter Alpha1
- Start date
jeffwidman
Active 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.
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
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.
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).
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
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.
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.
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.
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.
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.
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
Well-known 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?
imthebest
Well-known member
You are totally correct. I have done that and it worked flawlessly although I used this importer: https://xenforo.com/community/resou...porter-for-tinhte-xentag-to-xenforo-1-5.4403/
This is implemented in XF 1.5.6.
We've released this in the Resource Manager which should help if you have already completed your import:
https://xenforo.com/community/resources/thread-tag-importers.5069/
We've released this in the Resource Manager which should help if you have already completed your import:
https://xenforo.com/community/resources/thread-tag-importers.5069/
Last edited:
Similar threads
- Question
- Locked
- Question
- Suggestion
