Download error on local MAMP migration

[marcosig]

Hi, I’m trying to migrate from Prestashop 1.6.1.18 to Thirty Bees 1.0.7 on a local MAMP server website but I'm getting an 'Error during download' message.

Can anyone help? Thanks

[Traumflug]

Could you give a few more details?

Did the module install?

Does the migration process start (panels change, a text view appears) ?

What are the last messages in this text log?

[marcosig]

Hi Traumflug, thanks for the reply.

The modules installed correctly and the migration process starts, but after a few seconds I receive the following message in the Activity Log

[Peter]

Isn't it better to migrate from PS to Tb 1.0.6 and after that upgrade to 1.0.7?

[marcosig]

Hi Peter.

it seems to me that the thirty bees migration module allows only the upgrade to the latest version (1.0.7)

[datakick]

Since the download took only 1 second, I assume the problem is in misconfiguration of your server. You probably do not have curl installed, or you might have some firewall that prevents the operation.

I just tested it, and it works. Download took 93 seconds though, so I had to extend timeout limit on my nginx.

[Traumflug]

Isn’t it better to migrate from PS to Tb 1.0.6 and after that upgrade to 1.0.7?

No longer possible. Since about yesterday, the migration module migrates straight to 1.0.7.

[Traumflug]

Download took 93 seconds though

Github is so slow :-/ Even at off times I get only some 10 Mbit, which means a ~30 seconds download for just 40 MiB.

[Traumflug]

@marcosig said in Download error on local MAMP migration:

The modules installed correctly and the migration process starts, but after a few seconds I receive the following message in the Activity Log

Thanks, the picture is very helpful.

Do you see this Archives will come from ... message? One can try to download these two links with a browser or with command line curl/wget as well. This should work, it's a plain HTTP file download.

If you manage to get these two files another way, you can place these two ZIP archives manually in the location given in the message starting with Files will be saved to .... The module will find them there and use them without trying to download them again (that's a new feature of the most recent module version).

It also doesn't hurt to try more than once, until the archives are there and get unpacked, the PrestaShop installation isn't changed. Perhaps Github had an outage just the moment you tried to migrate.

[marcosig]

Many thanks Traumflug, I'll try asap

[marcosig]

I've tried (more the once) to place manually the 2 ZIP archives in the target folder and also tried to migrate a clean Prestashop installation but the error always occurs.

[lesley]

When you push the button, can you time how long it takes until the error happens.

[marcosig]

Less than 5 seconds

[lesley]

Hmm, is it giving an ajax error?

[marcosig]

Sorry, I'm not so techie. The only error message I can see is the one I sent above to Traumflug. Where can I look for any ajax error?

[lesley]

Oh, I missed that error. Is there anything in the local error logs?

[marcosig]

No, it seems all ok

[marcosig]

Checking once again I found that every time I launch the migration process I get this error message in php_error.log:

PHP Deprecated: Automatically populating $HTTPRAWPOSTDATA is deprecated and will be removed in a future version. To avoid this warning set 'alwayspopulaterawpost_data' to '-1' in php.ini and use the php://input stream instead. in Unknown on line 0

[Traumflug]

Hmm. thirty bees code doesn't use HTTP_RAW_POST_DATA.

[marcosig]

The error seems to occur during the download of thirtybees-v1.0.7.zip to the autoupgrade/download folder. The archive thirtybees-extra-v1.0.7.zip is correctly downloaded (together with thirtybees-file-actions-v1.0.7.json). Since the migration process seems to delete the contents of the autoupgrade/download folder before attempting to download the archives, it's useless to manually place them before launching the migration.

[Traumflug]

Since the migration process seems to delete the contents of the autoupgrade/download folder

True. Forgot to remove this when picking this feature from module tbupdater.

Here's the patch (just find and delete these four lines): ```diff // regex optimization pregmatch('#([0-9]+.[0-9]+)(?:.[0-9]+){1,2}#', _PSVERSION_, $matches);

         $this->nextQuickInfo[] = sprintf($this->l('Downloading from %s and %s'), $this->upgrader->coreLink, $this->upgrader->extraLink);
         $this->nextQuickInfo[] = sprintf($this->l('Files will be saved to %s and %s'), $this->getCoreFilePath(), $this->getExtraFilePath());

- if (fileexists($this->tools->downloadPath)) { - Tools::deleteDirectory($this->tools->downloadPath, false); - $this->nextQuickInfo[] = $this->l('Download directory has been cleared'); - } + $report = ''; $relativeDownloadPath = strreplace(PSROOTDIR, '', $this->tools->downloadPath); if (ConfigurationTest::test_dir($relativeDownloadPath, false, $report)) { $timestamp = time(); $res = $this->upgrader->downloadLast($this->tools->downloadPath); ```

This will also go into the next release, of course.

[marcosig]

Got it! Removing the 4 lines and manually adding the archives worked out. Now we can roll up our sleeves and seriously plan our migration. Thank you so much.

[lesley]

Should we add a condition to disable those lines and a local archive option?

[Traumflug]

No need for making this optional. On the first try this directory doesn't exist. If it exists and some ZIPs are inside, they still get MD5-summed to make sure they're complete. Module tbupdater works this way since a year already.