XF 2.2 VBulletin5 url redirect with old vbulletin4 id's

[rouar]

Hi all, hoping someone has seen this before.

I installed Xenforo yesterday and am very very happy. We have nearly everything working except for very old links that predate our vb5 installation.

Installation:
Xenforo 2.2.6
Plugins: Xenforo Importers 1.5.0; Xenforo Redirects for VBulletin 1.1.9

Problem:
VB5 url redirects are working great.
Example: Throttle Hang Fix url redirects fine.
But older urls from our VB4 days are redirecting to random threads.
Example: Timing Belt FAQ url with id 105 is redirecting to a random unrelated thread with id 12.

Context:

• Old VB5 path was /ceg-vb/
• New Xenforo path is /forums/
• This is a very old forum that was started in 2006 with vb3, and later vb4. It was upgraded to vb5 in 2014.
• When you upgrade to vb5 (at least in the early vb5 days), entity id's are not preserved. known behavior by design So, from 2014 onward, links containing old id's were redirected to the new vb5 id.
• When importing, I did not preserve ID's. The import created a table import_log_vbulletin_5_1 containing old_id and new_id.

In the Timing Belt FAQ thread example, it looks like the id is being interpreted as "old_id" and redirecting as such:



But we actually have three id's, a very old one in the vbulletin 'node' table:





So in essence, we require two redirects:

• the vb4 very_old_id (105)
• the vb5 node_id == xenforo old_id (189)
• the xenforo new_id (96) -- correct result!

Has anyone encountered this before? I'm investigating further, and hoping that the solution is not to rebuild our xenforo import.

 

[FTL]

Since this is a new XF installation why didn't you install the latest 227 patch 1?

 

[rouar]

We are upgraded to 227 patch 1 as of this afternoon (after I sorted out backup cron jobs), but for the initial install I used the known stable version that I had been testing. There is no difference in the redirect behavior.

 

[rouar]

This issue is important to us because our forum was most active when it was on vb4. The majority of our links use this old id.

I have a solution design proposal. However, it would be best to involve xenforo development, as it requires changes to both the vbulletin5 import script and the redirect plugin.

1. Create a new column in the import_log table. For brevity, we'll call it very_old_id.
2. In the import script vbulletin5.php, for the threads and posts steps, add "node.oldid" to the SQL select query. Insert that value into import_log.very_old_id.
3. In the redirect plugin, if a url comes in with [t] or [p] query parameters, then first check very_old_id. If exists, then redirect to new_id. Else use old_id. (I might have a bug in this proposal, if the vbulletin5 posts are also using those parameters)

Let me know how to proceed: should I open a support ticket, a bug, ?

 

[rouar]

Ok, I have a partial design solution for this built.

I exported the vbulletin4 id's from the vbulletin node table as follows:

select oldcontenttype.class, nodeid, oldid from node
join contenttype as oldcontenttype ON (oldcontenttype.contenttypeid = node.oldcontenttypeid)
where oldcontenttype.class IN ('Thread','Post')

I will import this data into my xenforo import_log table, and then edit the xenforo redirect plugin to give preference to these values when it encounters a vbulletin4-style url. (Meaning to say, when it encounters a redirect originating from 'showthreaded.php'.)

I have two design approaches for the import:

• Create a new column in import_log table called very_old_id, and insert the vbulletin4 id into the existing rows.
• Do not create a new column. Create two new content_type metadata called "thread_vb4" and "post_vb4". Import the data as new rows. This will create more bloat in the table. But it seems less risky in case the xenforo codebase explicitly expects only three columns in the table.

Asking for thoughts - which is better?

edit 5:30pm est - I have decided to go with the latter.

 

[hstammlerj]

Hi rouar,

we encountered similar issues by migrating a former ubb around 2006 to vb3, later vb4 and then -cut- to vb5. Because of several issues we were forced to postpone the long-term planned shift to XenForo really fast, so by today there are roughly half a dozen URI schemes to be redirected to keep as many old URI working as good as possible.

My advice (against your 5:30 decision, sorry):

• Try to keep new infrastructure modification-free to be future-proof without ongoing service time to keep it up and running. (This was our main lesson with vb3/vb4 coding: you could do everything, but you had to pay in long term... )
• Try to fix everything in static sources like import_log and give younger ids priority (yes, the internet doesn't forget, but: many topics lose their relevance over time because of product/market changes ).
• If there is "the one and only" long-lasting thread being redirected wrong, make a one-time decision which id should win and edit import_log (very_old_id of a 100-pager or old_id of a mayfly thread? ).
• If needed, implement additional redirect schemes by placing them appropriate (at old URI locations) and/or utilizing additional server-side redirect rules.

For our case, over the years we built a handful static redirect schemes including locally coded id-crosslists in PHP combined with server rewrite rules. They offer live forwarding for most old (and relevant) ubb URI, vb4 cms URI, hard-coded html static URI and some other weird stuff of the past.
Concerning our screwed-up vb5 weeks: the import_log table was hardly modified like you did with some SQL magic to find and redirect vb4 ids by priority and scrape vb5 duplicate ids which didn't gain enough relevance in that short time period of vb5 being somehow alive.


Since you do not have millions of posts: some local PHP forwarding scripts should do the most work for you. Redirecting 1k distinct ids of "content.php" vb4 cms URI only took less than a 20 kB php file including a local cross-id table/array without the need of a DB connection. Doing the same for 30k ids / ubb URI took a 500 kB php file. All these redirect file sources are dropped to the server once and can be forgot for long time as long as PHP and redirect rules keep working. (And if it no longer works in five to ten years: Does anyone still care? )


We can be sure to say: If there is any issue, we can do updates immediately without checking mods/hacks, also for addons including vb redirect. Feels better that way every single day.

cu
Herbert

 

[rouar]

Hi Herbert- thank you!

I agree, a local forwarding script is my backup option. I consider this a bug, and am hoping to identify a fix that the dev team can clean up and publish.

Although this thread hasn't seen much traction, I suspect this will be a problem for many 'up-and-coming' customers who take a journey from VB4->VB5->Xenforo like you and I, particularly as VBulletin recently stopped VB4 support. Although recent converts like yourself can get away with rewriting existing old_id's as you have suggested.

It's funny you mention UBB. We have a separate UBBThreads instance that we maintain as a read-only archive - a decision made before my time. Some of the posts are over 20 years old. Sounds like textbook data hoarding, but due to the nature of our website, the "early years" contained some valuable information.

I have a working solution and will be posting it soon.

 

[hstammlerj]

Hi rouar,

you're right, there are still a lot of VBx out there on the run to migration. From my point of view, you had bad luck to switch to VB5 too early having that very_old_id issues. Many VB platforms I knew/had chosen for "competitive compare" also waited and kept VB4 running as long as possible (so: not having that very_old_id issue) always hoping VB5 will get magically better and less harmful to server load than the first gold releases... which honestly never ever happened.

It's funny you mention UBB. We have a separate UBBThreads instance that we maintain as a read-only archive - a decision made before my time. Some of the posts are over 20 years old. Sounds like textbook data hoarding, but due to the nature of our website, the "early years" contained some valuable information.

A difficult decision. Again, for us it was important to be able to cut off old server instances and code. Probably you now still need to run a server instance with very old Apache/CGI/PHP versions to keep the long-deprecated code still working? That scenario we try to avoid wherever possible.
I didn't check specially for UBBThreads, but afaik VB (3/4, yes, no joke, maybe good as an in-between hop because they support ancient systems and charsets) and XF do offer really good importers.

Hope you get along well with the id collisions and find a good way,
Herbert

 

[rouar]

Thanks! The company that makes UBBThreads is alive and well, and upgrading to their latest 7.7.x was a journey I embarked on last year. I have offsite backups of the older database, so a conversion is possible. The eventual goal is to merge the data, but for now, this is our best approach at URI preservation.

To be on topic: My solution works for me today, as can be observed in the top post's examples. However, I want to redesign it to be less invasive before posting.