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).
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.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.
Certainly the importer would handle the rebuild of the tags caches itself, it wouldn't be a separate thing.Plus if a tag importer gets added to core at any point, it'll need a way to rebuild the tag caches.
We'll see how things go. I can probably point you in the right direction, at least, if we don't handle it ourselves.Agree with you that building it into the existing Threads rebuild option rather than a separate option is probably the cleanest solution.
I can probably point you in the right direction, at least, if we don't handle it ourselves.
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.
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 had an vbulletin tags importer developed for me. If anyone wants to share in the costs then please contact me.
We use essential cookies to make this site work, and optional cookies to enhance your experience.