Legacy [VB5 Version Request] Redirect URLs after Import from DownloadsII

[Webbstre]

Redirect URLs after Import from DownloadsII

This request goes alongside my other one about the import system. After an import system it would be VERY useful to have some kind of redirect system in place to take people following old links in the DownloadsII database to the new vbDownloads location. It would help retain search engine rankings and prevent users from thinking that a file no longer exists. When you have a thousand or more files in your database to import it is very impractical to manually create a redirect for every single entry.

 

[Webbstre]

I'm bumping this request back up, since a lot of time has passed. Even if it required the new SEO modification I want to see some form of redirect script that we could replace the downloadsII php script with that would allow users going to that file to be redirected to the new location within vbDownloads. I think it shouldn't be too difficult to implement, if a new table was created within the database that housed the IDs from DownloadsII and the new IDs for vbDownloads.

 

[Fillip H.]

The problem is that once the import has been done, vBDownloads no longer knows about the relation. At this time I can't think of an easy way to tie these two back together, when (in the case of your other thread) the titles aren't necessarily identical any more.

 

[Webbstre]

Honestly, I wasn't hoping for anything post-import. My thought (when I bumped this, now that I have taken apart the sql tables for both a couple times) was that during the import process the IDs could be preserved and saved in a new table alongside the brand new vbDownloads FileIDs and DownloadID. Specifically:

Table: dl2_downloads, column: fileid
table: dbtech_downloads_download, column: downloadid

So for example, for my test domain, the link http://www.mysite.com/downloads.php?do=file&id=698 would take you to the page http://www.mysite.com/vbdownloads.php?do=download&downloadid=1243. If you stored the two IDs together in a table and replaced the DownloadsII php file with the custom file that redirects based on the input url then I think it might not be that difficult to manage. Unfortunately I don't have the php skills to make it myself.

 

[Fillip H.]

Can you give me a complete layout of all DownloadsII URLs? I want something like:

downloads.php?do=cat&id=X - Category browser, reads from some_table_name, column some_column

Does that make sense?

I can't promise I will have time to implement this for the next version (I will implement the comment thread linking, though), I at least want to create the tools / store the data needed to create the "redirect file" later down the line.

 

[Webbstre]

No problem! Here's everything you need:


downloads.php?do=file&id=X - File browser, reads the id from prefix_dl2_files, column: fileid
downloads.php?do=cat&id=X - Category browser, reads the id from prefix_dl2_categories, column: id
downloads.php?do=search - Search Page
downloads.php?do=add - Add File Page
downloads.php?do=manfiles - Moderator Approval Page


Here are a few screenshots that may help as well:
https://www.dropbox.com/s/9bfum4e0dwa29vo/Screenshot 2014-03-30 07.23.43.png
https://www.dropbox.com/s/wil1hhqfxpfljav/Screenshot 2014-03-30 07.29.32.png
https://www.dropbox.com/s/iu01ot4vymxf44c/Screenshot 2014-03-30 08.08.37.png
https://www.dropbox.com/s/au4alw1f26s99wr/Screenshot 2014-03-30 08.15.38.png


Let me know if you need anything else!

 

[Fillip H.]

The only other thing I can think of is where the current comment thread ID is stored? I can't seem to spot it in either your downloads or files table.

I figured I should add that to the importer as well.

 

[Webbstre]

Oh, that may be because it was a separate installation to the regular DownloadsII. It's by the same author but he never bothered to make it part of the main installation.

If the user has the Create New Thread Add-On installed it adds the column dl_thread to the table prefix_dl2_files.

So for example, the first result in that column for my forum is 4274, which takes you to this thread. (Note the URL)

 

[Fillip H.]

I've patched the files to add support for the dl_thread column in the dl2_files table in the importer

 

[Webbstre]

That is awesome, thank you! Now I just need to go in and manually add in all the threads previously made by vbDownloads (I'm assuming it doesn't automatically know what thread it already made a post for).

 

[Webbstre]

Bumping this thread to see if there is any update on the possibility of a redirect file for the DownloadsII URLs to redirect to the places they were imported to in the vbDownloads database. We've got the comment thread urls (thanks again for that) but I haven't seen that last piece in the recent updates, so I was wondering if it's still on the table.

 

[Fillip H.]

I'll keep this tab open - I've been reminded of the vB3 version of D2 not importing correctly and I'm wanting to resolve that over the weekend - that'll be a good opportunity to have another look at this as well

 

[Fillip H.]

Update: In the next version, there will be a new file in a do_not_upload folder that will act as a redirector for old Downloads II links

 

[Webbstre]

Thank you! I'm looking forward to testing it out

 

[Fillip H.]

After testing the vB3 version of the importer, I've discovered multiple issues that means the 301 redirects are not going to work as intended just now.

The old file IDs were not correctly stored in the importer table, necessitating a re-import. This would have been fine, if it hadn't been for the fact that recent changes to vBDownloads have broken compatibility with the "was this download already imported?" check. Any attempts at re-importing the DII entries just now will create duplicate downloads, but those newly created downloads will be "immune" to this issue.

Sorry for the trouble

 

[Webbstre]

So... a little longer? I'd it the same for the vb4 version?

 

[Fillip H.]

Yeah, the same issues affected the vB4 version.

Basically, the script checks for date stamps when determining whether the existing files or downloads exist, and recent changes updated those date stamps so that they no longer match. Recent versions of vBDownloads changed this, by preserving the original upload date and instead adding a new "updated" date, exactly the same as Downloads II does.

The problem is that existing files and downloads that have been edited since they were imported will no longer be recognised by the importer, so duplicates will occur unless all imported downloads & files are erased, which would need to be done manually