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.

How can i change it to solved? The grey button, Topic Tools under the first post and at the bottom of each thread. It's actually a menu and there's Mark as solved inside. The green menu item.

Oh, and thanks for reporting this.

I think I've found (and fixed) this. It's a harmless error message, one can safely ignore it. https://github.com/thirtybees/thirtybees/commit/3774d272bdc629c30e689b47eaf434e86da2ffa6

Is there a green box instead of the red box if you change quantity, then not clicking Save and Stay, but into some other field? Then I can confirm this issue.

I much prefer PS1.6 but it seems like all the PS Addons Developers are being forced onto PS1.7 - it’s a sad state of affairs It's understandable that one trusts a long term relationship. And that's why thirty bees exists. It allows to continue with this relationship, just under a different brand name. Like MySQL evolved into MariaDB, like OpenOffice evolved into LibreOffice.

IMHO, the theme should match the shop topic. A shop for motorcyclist spare parts needs a different theme than one for swimming suits or toddler toys.

Blank page means there's some fundamental problem, like a PHP syntax error. Such errors get reported to the Apache/Nginx log (/var/log/apache2/error.log or similar). If you have an idea which module causes this, remove it from the modules folder and try again. Like none mkdir modules.off mv modules/dirtymodule modules.off/ Modules in modules/ still get partially executed when listing modules, even if they're neither installed nor enabled. And we'd be interested in which module caused the trouble, of course. The migrator is about to get a feature automatically moving some known-to-be-troublesome modules aside.

Instead of adding HTML comment signs, like @colorful-ant did, one can also simply remove this code section. Also make sure to delete the cache or set Smarty cache to Recompile templates if the files have been updated after doing so. Both can be done on back office -> Advanced Preferences -> Performance.

Well, having no ID in the URL can lead to duplicate URLs. That's pretty obvious. One solution is the one @dosbiner mentioned: detect and fix them. The other solution is to add the ID to the URL, like PrestaShop did. This still works, it's just no longer the default.

@baarssen said in migration from Prestashop 1.4.6.2 to Thurty Bees ?: @lesley said in migration from Prestashop 1.4.6.2 to Thurty Bees ?: It will not from 1.4. It only works with 1.6 versions of PrestaShop. No thats not true. I migrated several webshops from 1.5 to 1.6 and 1.7 with this module. Is it possible you two are talking about different things here? I think @lesley talks about the thirty bees migration module (https://store.thirtybees.com/shop-modules/administration/thirty-bees-updater) and about upgrading to thirty bees. @Baarssen apparently talks about a third party module (https://addons.prestashop.com/en/data-migration-backup/8934-migrationpro-prestashop-upgrade-and-migrate-tool.html), which can update from earlier PS versions, but does so not to thirty bees, but to PS 1.7.

Software world is full of pitfalls :-/ See what @datakick found: https://github.com/thirtybees/thirtybees/issues/619 Surprise, surprise! It turned out that PHP's array_merge() doesn't work as one would intuitively expect. A fix is probably found already, yet another updater release will happen before too long. tl;dr: merchants wanting to upgrade from 1.0.5 or earlier, please wait for the next updater release (later than 1.3.3).

Hmm. thirty bees code doesn't use HTTP_RAW_POST_DATA.

I thought the vagrant+virtualbox method was supposed to be pretty robust Then it's no longer a server running on Windows, but a Linux running on (for the virtual machine and during these updates) crippled hardware. One solution is to make this PC dual booting with Ubuntu. This gives the most from the hardware and also gets rid of these slow update processes. The other one is to go to dinner during these updates, as you had the plan to do.

Please don't evaluate thirty bees on a web server running on Windows. This is known to be troublesome.

NASA budget? I've installed a working shop on a $5/month hosting. Not sure whether NASA could live with such a budget. For teaching, one better installs thirty bees on the local PC, without any hosting. Given this PC runs a proper OS, like Debian or Ubuntu or CentOS.

Do I need to install any earlier versions before installing this one? The updater module should work for any version between 1.0.1 and 1.0.6.

The module provided by thirty bees is this one: https://github.com/thirtybees/vatnumber. It never had a version 2.0.4. Looks like there's a module name collision. You got a custom made module and it got kind of reverted to the official one, probably because they share the same name. I'll look into the custom one later today to see what the distinction is.

I just see that I forgot to mention that the migration module now migrating to thirty bees 1.0.7 is a contribution by @datakick, thank you to him!

@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.

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.

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.

Here I have to admit that my testing yesterday was wrong. To see prices without tax, one has to be logged in as customer and an address with a VAT number, of course. Or Allow manual verification on the module configuration page enabled and Yes, I qualify for VAT Relief! in the customer address checked. Or both. Today's testing showed the module to work just fine and as expected.

when I go to the module in the backend at Customers>VAT module There's also no such menu entry coming with the default installation:

index.php?controller=AdminVatNumbers There is no such controller. The module's configuration page is at admin-XXX/index.php?controller=AdminModules&configure=vatnumber. There is also a class VatNumber, without the s. It comes with the module and some areas of core code use it, after testing that the module is actually installed. Accordingly the question is, how or where did you get this link?