Yeah, a text search works. Looking at the HTTP headers, I’m not sure how it’s actually making the determination how to map from the old thread to the new - there are two 301 redirects that take place; one that goes from:
(Weird that it goes to http rather than https), and then from the HTTPS version of that link to
non_space’s issue, though, is that his bookmarks all use the parameterized URLs. I suppose it might be possible for him to export those links and automate the search on Google to get the static links (Python with Mechanize, maybe?), but that’s going to be pretty custom stuff.
Ah, yes, 1.2+ million. That’s a huge redirect table to build, and even if it were automated by the content migration process, the time to do the lookup from old link to new link wouldn’t be instantaneous. But now I’m curious how the static link redirect works at all.
ETA: The redirect from HTTP to HTTPS is handled by another request header - “upgrade-insecure-requests”. So that mystery is solved (I should’ve thought of that, too early in the morning and I haven’t had my tea yet).
ETA2: And it looks like the migration tool does build topic-level redirects, but those seem to be handed using a “thread ID” mapping to “topic ID”, which clearly is pretty quick. But with threads in vBulletin that could have hundreds of messages, doing the conversion of “post ID” (which seems to be the parameter in the links that aren’t working) to “topic ID” would be more time consuming to do.
ETA3: It looks like the mapping table is a static table (looking at the code for the migration tool), but it looks like it also should work with bookmarks/links that use the topic ID (looking at the code) - it pulls from
Topic.listable_topics (that’s the Ruby variable name) - so it’s based entirely on the vBulletin topics and not posts. But it does that and just creates a CSV file with the redirects in it.