XF 2.1 Import just not working

$ php cmd.php xf:import --verbose
Starting import from vBulletin 4.x (Beta)...
- Importing... (< 1 sec)
In Adapter.php line 160:

[XF\Db\Exception]
No such file or directory


For some reason I just can't get the importer to work. I setup everything via the admin-panel, and when it tells me to I try to use the cmd.php. Unfortunately without success.

It seems like it just can't pickup the db-config (the array is empty) but during the import wizard it never asks me for details. The forum itself is working though.

Quite disappointed to have purchased a license.
 
Quite disappointed to have purchased a license.
Don’t be disappointed yet. You appear to be having an unexpected issue and unfortunately these things sometimes happen.

I doubt very much this is a bug though as we haven’t had any other reports of this. It should “just work” and generally that is what happens.

So we just need to try and figure out why it isn’t in your case.

Sometimes the “no such file” error relates to MySQL attempting a socket connection rather than a straight TCP/IP connection. One workaround might be to specify the IP address of the source DB rather than the hostname e.g. if it is localhost try 127.0.0.1 instead.

To do this you will likely need to go back to the import page and start the process again.

Generally though if the web UI gets you as far as giving you the instruction to start the command then we have already successfully made a connection to the source database so there’s no reason it should fail when doing it from the CLI.

Other causes could include the php command on the CLI not actually being the same version as the PHP being used by the web server process. Sometimes you can verify this by running php -v and making sure the PHP version matches that listed on your Admin home page.
 
Thanks @Chris D

Sometimes the “no such file” error relates to MySQL attempting a socket connection rather than a straight TCP/IP connection. One workaround might be to specify the IP address of the source DB rather than the hostname e.g. if it is localhost try 127.0.0.1 instead.

That is exactly what is happening. For some reason the db-config array at that point is empty. Meaning: I understand the error, just not why it is happening.

Generally though if the web UI gets you as far as giving you the instruction to start the command then we have already successfully made a connection to the source database so there’s no reason it should fail when doing it from the CLI.

Exactly my frustration. During the wizard there is zero possibility for me to enter any DB connection info. My assumption (after flying through the code) is exactly that, that it will try to autodetect those (by including the old config.php or using the current db-connection).
So you are correct, if the wizard goes forward up to the web/cli instructions, it should be all fine. Except it isn't :)

Other causes could include the php command on the CLI not actually being the same version as the PHP being used by the web server process. Sometimes you can verify this by running php -v and making sure the PHP version matches that listed on your Admin home page.

The error happens with both variants, the web import or the cli import.
 
So I just made a fresh installation with xenforo 2.0.12 + importer 1.0.2:

  • right off the start its asking me more questions and not just skipping through the wizard
  • so far importer via CLI is doing stuff - will wait for it to finish still though
195290

So to me this looks like a regression. Maybe its my PHP settings (PHP 7.1). It would be great if there were automated tests for such things as it would greatly improve UX...
 
Exactly my frustration. During the wizard there is zero possibility for me to enter any DB connection info. My assumption (after flying through the code) is exactly that, that it will try to autodetect those (by including the old config.php or using the current db-connection).
So you are correct, if the wizard goes forward up to the web/cli instructions, it should be all fine. Except it isn't :)
It isn’t possible to complete the set up of the importer without entering the source database details. It’s the first thing it asks you to do. We do not have any ability to automatically find and read a vB config file.

So I just made a fresh installation with xenforo 2.0.12 + importer 1.0.2:

  • right off the start its asking me more questions and not just skipping through the wizard
  • so far importer via CLI is doing stuff - will wait for it to finish still though
View attachment 195290

So to me this looks like a regression. Maybe its my PHP settings (PHP 7.1). It would be great if there were automated tests for such things as it would greatly improve UX...
I have been recently developing additional importers. I have been using XF 2.1 and Importers 1.1. These imports have required me to do some VB imports. I haven’t (nor has anyone else) experienced what you have mentioned so although I am not sure how you’ve been in this situation, I can assure you that it isn’t any sort of regression and the situation seems unique to you, unfortunately.

Hopefully if you were to try again it will work as expected. If it does not, then we’ll need you to submit a ticket so we can reproduce the issue and troubleshoot it in your specific environment.
 
It isn’t possible to complete the set up of the importer without entering the source database details. It’s the first thing it asks you to do. We do not have any ability to automatically find and read a vB config file.

Thats not true (and I am quite surprised as you should be xenforo developer??) - this is the code snippet of the importer:

PHP:
$configPath = getcwd() . '/includes/config.php';
            if (file_exists($configPath) && is_readable($configPath))
            {
                $config = [];
                include($configPath);

                $vars['db'] = [
                    'host'        => $config['MasterServer']['servername'],
                    'port'        => $config['MasterServer']['port'],
                    'username'    => $config['MasterServer']['username'],
                    'password'    => $config['MasterServer']['password'],
                    'dbname'      => $config['Database']['dbname'],
                    'prefix'      => $config['Database']['tableprefix'],
                    'charset'     => $config['Mysqli']['charset']
                ];
                $vars['super_admins'] = $config['SpecialUsers']['superadministrators'];

As you can see, it has the possibility to read out the old vb-config and autofill certain settings. Thats what definitely happened with xenforo 2.0.x + Importer 1.0.x...

I have been recently developing additional importers. I have been using XF 2.1 and Importers 1.1. These imports have required me to do some VB imports. I haven’t (nor has anyone else) experienced what you have mentioned so although I am not sure how you’ve been in this situation, I can assure you that it isn’t any sort of regression and the situation seems unique to you, unfortunately.

Thats strange. Not sure though why with the same setup everything works perfect with XF2.0 though - hence my conclusion of a regression. It does not mean that its a regression across all systems, but at least one for my setup/system.
 
We would need to check the code in question, but the code you've pointed to is specifically related to rendering the page related to setting up the "source database configuration". Those values should be rendered back to you and you can confirm them.

Of course, the simplest way to avoid triggering that code would be to remove the includes/config.php file and then you would enter the details directly.

After that step, we do a test connection as we need to validate some things and then setup other configuration options, so I can't see any reason for there to be an issue with that (and that has certainly been something we have been testing recently).
 
Thats not true (and I am quite surprised as you should be xenforo developer??) - this is the code snippet of the importer:
I am very well aware of that code but that still does not automatically configure the database for you. It also requires the config file to be accessible from the root of your XF files, which we do mention in the manual but I'm not sure if that actually applies here? Not sure because you didn't mention it.

Those values should be rendered back to you and you can confirm them.
This is what happens.

So the config reading is generally irrelevant to what I said.

As you can see, it has the possibility to read out the old vb-config and autofill certain settings.
Yes, auto fill, not execute, connect, test and render any necessary individual step configuration. All of that needs to be explicitly confirmed.

It does not mean that its a regression across all systems, but at least one for my setup/system.
That is why I said the following. More than happy to help, but we need to be in a position to reproduce the environment first. If you're in that situation again, we would be happy to take a look for you. If you have an opportunity or the time to attempt to reproduce the same situation again, we would be interested in hearing if this is reproducible and exactly what the steps were.
Hopefully if you were to try again it will work as expected. If it does not, then we’ll need you to submit a ticket so we can reproduce the issue and troubleshoot it in your specific environment.
 
@Chris D

Sorry, I am confused right now.

Me: "My assumption (after flying through the code) is exactly that, that it will try to autodetect those (by including the old config.php or using the current db-connection)."

You: "We do not have any ability to automatically find and read a vB config file."

You (later): "does not automatically configure the database for you"

You (later later): "Yes, auto fill,"

So, does that code now autofill by trying to autodetect my vb-legacy db settings or not? Because thats at least what I saw on xenforo 2.0 - not sure if it changed with xenforo 2.1 but giving that another shot now :)
 
@Slavik: yes

So I did a fresh 2.1 installation - now things look better:

  • removed memcached settings for now
  • restarted memcached (as I am using it internally for php-sessions as well) - just to make sure there was not any polluted session data from previous installation
  • did NOT install a paid theme
  • so basically vanilla xenforo 2.1 + importer 1.1 + s3 addon

Will see how it goes now. Thanks all for the comments :)
 
@Chris D

Sorry, I am confused right now.

Me: "My assumption (after flying through the code) is exactly that, that it will try to autodetect those (by including the old config.php or using the current db-connection)."

You: "We do not have any ability to automatically find and read a vB config file."

You (later): "does not automatically configure the database for you"

You (later later): "Yes, auto fill,"

So, does that code now autofill by trying to autodetect my vb-legacy db settings or not? Because thats at least what I saw on xenforo 2.0 - not sure if it changed with xenforo 2.1 but giving that another shot now :)
The very first step of configuring the importer in all cases regardless is it will ask you for the database connection details for the source database.

195337

If a config file is located in a specific path, the above fields will be pre-populated with those values.

However, this form will still be displayed, therefore:
It isn’t possible to complete the set up of the importer without entering the source database details. It’s the first thing it asks you to do. We do not have any ability to automatically find and read a vB config file.
This is poorly worded, but is still true. Ideally I'd have said "find and use".

So while it may automatically fill in those fields if possible, the values are simply echoed back to you for you to verify they are correct. The subsequent steps then attempt to make a connection to the database using the values you confirm.

Hopefully that clarifies how that works more clearly.

The whole point I was trying to make initially is that the following is not impossible:
During the wizard there is zero possibility for me to enter any DB connection info.

But, thankfully, it seems as though whatever you ran into before you haven't run into since so I'll keep my fingers crossed that it was just a one-off 🤞
 
Top Bottom