datakick

Looks like your tb installation is broken. Maybe some override, or changes to core files, are getting in the way. I would suggest you to disable all overrides (in Performance menu) manually install core updater module - https://github.com/thirtybees/coreupdater/releases/download/1.4.5/coreupdater-v1.4.5.zip update your store to latest stable or bleeding edge install tbupdater module

You will have some third party module (not tbupdater) installed that comes with its own version of GuzzleHttp library, and that causes conflicts. You need to figure out what module it is, and disable it/fix it somehow. Look into /modules/<module>/vendor/ directory to see if there is something named *guzzle*

It applies to all absolute url generated by thirty bees core. Links to controllers, modules, images, css and javascript assets,... what have you

Should be fixed on bleeding edge. Thank you for reporting the issue.

Indeed, there is an regression in bleeding edge. I have found the culprit and will fix it soon. Thanks for testing the edge, very much appreciated.

@bomas Please try to update your store to thirty bees bleeding edge using core updater. There is a fix / improvement in the area of image type resolution. This might help you

did you look upgrade from 1.2.0, or from some older version? Please PM me your store url - to some problematic product

What *.jpg files are present in directory /img/p/4/9/0/8/ ??? is there file 4908-home_default.jpg ???

The prices are calculated by method Product::getPriceStatic(), so classes/Product.php should be the first to check. Look also for override. I quickly looked into the code, and there is no recent change in this area

This does not look like bug in 1.3.0, since it works fine on your dev site. More likely you have some module or override that interfere

Well, then what you are asking for is not possible. Thirty bees estabilish connection with mysql server directly, it does not use any third party program to communicate through.

try to regenerate image thumbnails. If that does not help, you will need to check the url of the image, and verify that the used image-type exists

You have probably uploaded some huge product image. Thirtybees is trying to generate image thumbnail, but because of the source image size it take too kuch time, and pho script time out. You can either increase script running time (in your cpanel look for max_execution_time settings). If that is not possible, then delete the file you have uploaded. To do that, you first need to know image ID. This can be deducted from exception stacktrace, look for function parameter value, there will be some id_image somewhere). Once you know the ID, for example 1234, then delete file /img/p/1/2/3/4/1234.jpg

I don't understand at all. What is MariaDB_client on server #1? Do you have two instances of mariadb servers installed in master->slave mode? Or are you talking about mysql/mariadb client program?

One of the reasons the pdf can be so huge is the used font. You can tweak used fonts in file classes/pdf/PDFGenerator.php, property $font_by_lang. For example, deleting line 'en' => 'dejavusans' Can reduce pdf size from 461K to 15k. Of course, the resulting pdf might look different. Or completely broken, if your language contains weird characters such as 'příliš žluťoučký kůň'

I'm not sure what protection are you talking about. The only kind of image protection that tb has is watermark module. It can generate .htaccess rules to block access to images without watermark. Of course, this only works on apache, on nginx+php-fpm such .htaccess protection is useless.

This looks like a very simple module. It simply allows you to link several products together, and display these linked products on product page, under the name 'Variants' It works quite like build-in Accessories feature. Accessories are just rendered in their own tab, and as a product miniature. With a little bit of theme modification you could actually use the Accessories feature to accomplish this module's functionality.

In your phpmyadmin you need to select database before you run the query. Anyway, from your last screenshot it looks like something entirely else is wrong. Do you have any local changes to php/tpl files? Do you have any overrides installed? You can use 'coreupdater' module to check your installation, and fix it its corrupted

Do not use build in SQL manager in thirty bees. Connect to your database directly, I'm sure your hosting comes with phpmyadmin

First of all, enable debug mode in Advanced Parameters > Performance. Then try again. Maybe some errors will be shown. If no error occurs, then click on 'Show SQL Query' button in upper right corner of the list, copy it to phpmyadmin, and execute it there. See what it returns. If it returns empty set (most likely), have a look at the query conditions and figure out which one is filtering your data out.

Red herring. Ignore this.

@Naldinho please post your store url

Intermittent issues like this are most likely caused by some caching mechanism. Do you, by any chance, have some Full Page Cache enabled (tb native or third party module)? Anyway, there is a small bug in /js/tools.js. Edit this file, and change line 105 from if (typeof window.currencyFormatters[currency] !== 'undefined' && window.currencyFormatters[currency]) to if (typeof window['currencyFormatters'] !== 'undefined' && window.currencyFormatters[currency]) This bug should not cause any issues, because front controller always generates the 'currencyFormatters' global variable. In you case, it does not -- this could be caused by FPC, or maybe some override.

The fact that the database is located on different server connected by stunnel is unrelated. This is just a red herring. Let me reiterate what we know: during installation, database is created from scratch as is empty the theme is installed when index.php?installTheme=true request is processed by php server. This is the only place in install process that calls the theme install method the error is throws only if theme is already installed -- the record in database exists The only explanation for this error to occur is that the index.php?installTheme=true request was processed twice by your php server. If you browser does not send the request twice, then there must be some other component in your infrastructure that duplicates / repeat this ajax call. For example, there could be a load balancer or proxy server. Maybe proxy server is misconfigured, and re-send the request to your php server if the response is not received promptly (this might actually explain why it works when db and php are on the same server. Communication via stunnel is bound to have higher latency) Look into your php server access_log to verify how many times the installTheme request was received.

Not possible. Just... no. The only way this could happen is if your browser sent two ajax requests to install theme. That's very unlikely. Very, very unlikely. Unfortunately it's possible, but only if you have some very weird caching browser extension, adblocker, etc. Or maybe some server redirection.... who knows. Look into browser console, Network tab, and see what requests are send during installation. There should be only one request with installTheme=true