Traumflug

Is this possible when i already have a test site on another domain with the latest version of TB and when my live site is running TB 1.0.3 ? Yes. Putting a copy into another folder is an entirely separate installation.

Maybe a stupid question, but how do I run the upgrade again when the updater settings says I’m running the latest version Version number gets updated as (almost) the last step. Which means, if there is some failure in the update process, one is still on the old version number and can restart the process. This also means that being on the new version number is an indication that the update process was completed successfully. Just ignore that error message from the last step.

... and now everybody is invited to guess what this "some tutorial" exactly is ... :-)

back office -> Catalog -> Products, click on a product, click on Images. Then you see a list of images for the product. The icon for each image is a link directly to the image. Show it by hovering over it or copy the link and paste it elsewhere to see it.

Yes, that's still pretty much PS code.

Each product image goes into a separate folder. Image no. 629 goes into img/p/6/2/9/, for example. Image numbers are not to be confused with product numbers.

I'd ask the hosting provider to turn the error log on. I mean, it's understandable why hosters turn it off. One client of mine (client, because he wants to upgrade to thirty bees) runs PS 1.6.1.5 on PHP 7.0 and this combination produces no less than 140 MB of error logs every single day. Most hosting clients couldn't care less about error logs as long as their site appears to work. They only chime in if the error log gets big enough to eat away all available disk space. A properly running site should be free of PHP errors in the logs, only listing those unavoidable intrusion trials (requests for wp_admin/ or whatever). Having the last error log entry from three weeks ago is a very good sign.

[Ajax / Server Error for action upgradeDb] textStatus: “error " errorThrown:” " jqXHR: " " These are surprisingly hard to avoid, the occurrences I've seen so far were simple timeouts of the Ajax script ... in this case for an operation which should be done in 0.1 seconds. Do we now have a broken database somewhere? No. Database either got upgraded or it did not, but nothing in between. It should work to simply run the upgrade again. Replacing files and upgrading the database twice doesn't harm.

There's a Catalog Mode. Back office -> Preferences -> Products. This should give a fully working shop, without all the carts, addresses and payment fluff.

I’ve tried to figure it out but I can’t find any error logs anywhere on the site There are at least three locations where errors get logged: You server's (Apache's) log. On plain Debian/Ubuntu systems that's /var/log/apache2/error.log. On a web hosting it depends on where the hoster provides it. Usually right next to access logs, but I've seen hosting where it's simply turned off (ouch!). thirty bees' log. In log/ in the root of each shop installation. In a properly working shop, nothing appears there. On errors, log files appear. Using Firefox, hit F12 to open a developer console, choose the Network analysis tab, reload the page, and you see each request listed as it get sent and the answer comes in. There should be one with a violet 500 badge. Click on it and see what was requested and what the answer was. Even if you don't understand the voodoo provided there, you can at least see which request went wrong. In some cases it helps to turn off debug mode. Code not PHP 7.2 safe can respond to Ajax requests not with JSON, but with an error message instead. Applies when running PHP 7.2, only.

One last question. How do I know if 1.6 addons are compatible with 1.6 themes? A module being a PS 1.6 addon means it's also thirty bees compatible.

In img/p/.

But the developer said the module (...) won’t work with TB, but he hasn’t tested it. Yet another stubborn developer. Didn't even try, but trumpets "it doesn't work" out to the world. Any module working on PS 1.6 should work on thirty bees as well (with only few exceptions, like "friendly URL" modules). But it's a 80-Euro-gamble, right?

Because I had the same issue with the tb captcha module on 2 stores using warehouse theme and I don’t have time to switch back to the official theme and test if it’s theme related issue I have. Well, it can't be a theme related problem, because a (malicious) user can change the theme to what he thinks is needed. Especially CSS and JavaScript. A secure login can get handled on the PHP side, only. That's what the No Captcha ReCaptcha module does, well, tries to do. However, so far I could not find any step-by-step instructions to get around the Captcha. Maybe it's obvious once one found this way, for me it's not.

@haylau Their reply “We did not tested, and we do not officialy support thirty bees. [...] Simply don't mention thirty bees. [...] The core isn’t the same as PrestaShop, and it would be hard to make a lot of conditionals regarding this solution.” That's clearly wrong. There are no conditionals needed, because all changes to core are either extensions or backwards compatible.

A Link to this bug report with solution would be certainly helpful.

Syntax errors usually appear in the server's (Apache's) error log.

Did you look into back office -> Price Rules? These two features there are usually used to give discounts, but I'd bet they can be used to raise the total as well. Like adding a negative discount.

Yes.

You should have a closer look. Missing files can get extracted from the distribution package. Changed files can get listed for changes as simple as a space character added.

If possible, look up your server's error log. Look for messages in log/.

It works in a pretty trivial way: marking this checkbox enters the magic word "vatExemption" as VAT number. Magic of this word is, it gets filtered away when creating invoices. Other than that it works like a valid VAT ID. One can see this word when looking up the customer's address in back office. If the VAT number field there is empty, the module is likely not the problem. That said, Swiss customers often know they get VAT relief when ordering something in Germany. Switzerland isn't in the European Community, so taxes get calculated the same way as when shipping to e.g. the U.S.: no VAT. They're expected to pay Swiss VAT at their customs office, though.

I thought it might be something to do with the cache but the captcha isn’t even displayed. If a page without Captcha is cached, nothing on the planet will ask for loading the Captcha.

PageCache turned on, perhaps?

The controller needs to be in the right place: <module folder>/controllers/admin/. Else the PHP autoloader doesn't find it. And one has to delete cache/class_index.php in the shop installation after placing it. This file will get recreated on the next page request. If there's something missing in the description, don't hesitate to edit this wiki. Subscription is free and unrestricted, of course.