Traumflug

Should be fixed with https://github.com/thirtybees/thirtybees/commit/9950d07902532788d019d680f87d8b5813b0b265?diff=unified&w=1 and go into the next release. Should be not too hard to apply manually. This bug was exactly 5 years old, introduced December 2nd, 2013 :-)

Please make a full screenshot (Firefox is helpful here) of this page. It's back office -> Shipping -> Carriers, then click on the carrier and select the third tab.

Confirmed: https://github.com/thirtybees/thirtybees/issues/789

Picked this to branch 1.0.x, together with a typo of mine: https://github.com/thirtybees/thirtybees/commit/965a66cded7a821e938eb6ac61b63d4e6dd4efc8 Thank you very much for the contribution!

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