Issue: Cant get past import config

If the form won't submit, one of the fields might be failing validation. I would expect an error message to appear directly above the field that is not validating.

For the attachment path, it cannot use the path specified in the vB install's own settings, because that is the path relative to the vB file system. If the XF install is on a different server, it is unlikely that the path to the attachments is relevant to the XF server. You must specify an attachment path that exists on your XF server, and the vB attachment files must be located there.

This is the only message on the page:

Setup the information needed to access and process the source data.
Its quite cryptic.


All XF importers including the official importers validate the vb attachment path. I have used a dozen importers.

When I fill in the information exactly as it appears in your old vault/core/controller/import/config/vw.php file, I get the following errors, which are displayed on the page:
This means that the source database does not contain VaultWiki 3 (or the table prefix is wrong).
This means that the source database doesn't contain vBulletin (or the table prefix is wrong).

I have fixed an issue on your site where the form was resetting the inputs when an error occurred.

XenForo's importer only validates the vB attachment path to the extent that it checks whether a directory by that path/name exists on the local file system. This is the same validation that is performed by VaultWiki's importer.

I have just opened the vault/core/controller/import/config/vw.php file and used the exact data from that file to log into phpmyadmin and find the vw3 vault tables which are prefixed with exactly the table prefix defined in this config file.

This database is the same vb3 database that I did all my imports from including the previous vw imports.

I now see that when I open the importer I can select a previous import. It doesnt show any difference between the previous imports as it only shows the date. Which is the same for all. It doesn't let you choose to delete previous imports.

This was not the case before. When I choose one, then it goes straight to the import. Which seems to mean that the data is correct?

I had 3 imports before. When I try to enter the data again, I get the same page without any error. But the 3 previous imports are still listed, without the 4th.
The data is saved except for the import name.

Fixed. The table-prefix setting was not working when importing into XenForo.

The old imports have invalid configurations that were created during my tests.

The way to tell the imports apart is by using unique import names. Am I understanding correctly that the custom import name is not saving and it is saving instead as only "My Import"?

EDIT: I see that the custom import name was not preserved when an error occurred. It defaulted back to the example "My Import" and was necessary to re-enter it.

Yes, your understanding is correct. Please advise on how to proceed.

In my tests, the custom import name field was not preserved when an error occurred, and reverted back to the default "My Import" text. In this case, this was the only field (aside from the field that generated the error) that needed to be changed again before trying to save the import again. I fixed this yesterday; it should no longer be necessary to re-enter the custom name if there is an error.

If the issue persists today, please let me know. However, it should be possible to identify an import started today since it will have a different "Started" date than yesterday's tests. Additionally, if they are bothering you, you can also remove any previous attempts with a query:
If you actually truncate the table (resetting the primary key), then you will also need to truncate the scratch table vw_import, as well as the config directory in internal_data/vwimport

Did you notice the database error in admincp?

I triggered that on purpose to see why it was claiming there was no VW3 in the database. It wasn't using the table prefix at the time. We fixed that issue yesterday.