Issue: VW3 showthread.php to VW4 (XF) redirection

In VaultWiki 3 showthread.php links that pointed to wiki articles were already 301 (permanent) redirects to the showwiki.php script. Thus, any sophisticated crawlers or bookmarks should have never indexed the showthread.php version of the URL. Because VaultWiki 3 automatically replaced showthread.php links with their showwiki.php counterparts in the page output, it is also unlikely that users ever saw the original showthread.php link in order to copy-paste those somewhere.

The only exception is for wikis that existed before VaultWiki 3 was installed, where the wiki forum was converted to a VaultWiki 3 wiki forum at such time -- links that existed already may have used showthread.php versions. We do not handle this very small percentage of links.

For those fringe cases, you are talking about many years already that 301 redirects have been in place. Our general practice for a version 3 to 4 conversion has not been to give 301 redirects for anything except VaultWiki 3's showwiki.php (and this is only automatic in the vBulletin version).

--

Still, we have recently been considering other ways to redirect things, and other things that may need redirecting. For example, we are migrating our own (vBulletin CMS) News pages into VaultWiki and need to preserve whatever vBSEO did to those URLs, but those versions of the URLs are not stored in the database to capture easily during an import process. If I recall correctly, this is the only thing holding us back from a vBulletin CMS to VaultWiki 4 migration path.

Looking at the redirection scripts that are available for showthread.php in XenForo, it looks like they are designed to give up if a thread is not found. This doesn't work well when you are looking to have both a showthread.php handler for wiki URLs and one for standard XenForo URLs. There are a lot of things to consider for a showthread.php handler.

You are probably right that the showthread wiki links originate from NuWiki. Vaultwikis predecessor.

At this point in time I am looking into the possibility of a better showthread redirection script. I will be importing content from forum threads into separate content types like article system, reviews system, etc. So within that context it makes sense to redirect showthread to wiki as well.

I believe this is implemented in 4.0.21.

I did mass replacement in the post table to replace all instances of /showthread.php?t=x by /threads/x
So many forum posts linking to the wiki, have dead links.
And as the showthread.php urls are automatically redirected to xenforo's /threads/x Google has indexed many hundreds of xenforo threads.

Do you have any solution for this?

If you imported in 4.0.18 or later, in AdminCP > Options > VaultWiki: Miscellaneous, set Redirect Content IDs from Import = your import. This will attempt to redirect all the source IDs from that import to the target wiki content.

Prior to 4.0.18, imports were not logged in a way that works with this setting.

If your content is from multiple import sources, or if you re-imported the same source without using a clean state, this may not work well for you. Unfortunately there is not an easy way to automate such a situation, since you could have ID collisions.

I used 4.0.19 but it doesn't seem to work:
/threads/32111/page-6
I see in the import log that 32111 has a targetid 51.

In the following files:

• library/vw/XenForo/ControllerPublic/Attachment.php
• library/vw/XenForo/ControllerPublic/Forum.php
• library/vw/XenForo/ControllerPublic/Post.php
• library/vw/XenForo/ControllerPublic/Thread.php

Find:
Replace with:

Thanks, but it still doesnt redirect.

The only other issue that I see is in the following files:

• library/vw/XenForo/ControllerPublic/Forum.php
• library/vw/XenForo/ControllerPublic/Thread.php

Find:
Replace with:
But you are not getting the associated error message in your logs, so it seems like there is another issue happening, such as an add-on conflict that is bypassing this code, or another XenForo/PHP bug that I have encountered: if your XenForo config file has certain caching turned on, there is a bug where your XenForo options are not actually updated on all pages even though you changed them. In these cases, I needed to restart PHP in order to get XenForo options changes to take effect. (If your options were not updated in cache, the code still thinks no import was selected to redirect).

If you continue to have an issue with this, you will need to open a new ticket.

Did you report that XF bug to the XF team?

Does it matter that I am now using NGNIX? (I moved away from my old host to Digital Ocean)

In library/vw/XenForo/ControllerHelper/ForumThreadPost.php, find and remove:
It looks like the code was added for debugging and was not properly removed.

This is changed. But no redirection yet.

I have opened a ticket.

This works now. The problem was that the import-forwarding was relying on XenForo_Controller::getHelper to return a singleton, but that is not the designed behavior of the method.