datakick

@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

Yes, cron is one possible implementation for Work Queue Executor. Not the only one, though 🙂 There should be some implementations that does not need any additional configuration, implementation that works right out of the box after the installation. This will be true for Immediate and Deferred executors. Then we can have advanced executors (standalone, cron-based,...), but for them to work properly additional infrastructure will need to be implemented. For cron-based implementation there will have to be cron endpoint. For standalone, there will need to be redis + requirement for VPS to run dedicated php cli application...

The link does not work, because MaxMind no longer offers download to unregistered users. You can sign up here, and then download the database for free: https://www.maxmind.com/en/geolite2/signup?lang=en

Sorry about the delay, I totally forgot about this one 🙂 This new tracking feature in 1.3.0 is basically a mechanism to send anonymous usage data to thirty bees api server. We made very sure that no personal or even domain information are being shared with using this mechanism, so it's aligned with GDPR requirements. At the moment we track only the very basic info about the installation: php version, installed php extensions, database version, and basic server settings (max exec time, memory limit, etc). In the future, this mechanism will be extended to track other informations like feature usage. Why do we need this information? There are couple of reasons, of course. First of all, we are investing a lot of effort and money into this thirty bees enterprise. And we need to have some way to actually measure the adoption of the software. When we were considering purchasing thirty bees we discovered that nobody actually knew how many stores are using this software in the wild. That's not good really. Without this information, it's quite hard to prepare business plan, monetization strategy, or whatnot. Merchants are using google analytics, matomo, or other tracking software to gather this information about their visitors. We are using this new feature to do the same. This first reason behind this feature is not something that merchants benefits from, thats for us. But there are other reasons that have (or will have) direct impact on merchants. With the collected statistics we can much better plan the development. For example, we are considering dropping support for some php versions - one of the reasons being that it makes it very hard to update dependencies / third party libraries might not support older version of php. But we don't want to just drop the support out of the blue, and leave merchants in the bind. Before we do such drastic thing, we want to be sure that the impact will be minimal. Another example: feature usage, that we currently do not track, but we want to - if we knew how many merchants are actually using some feature (ASM, multistore, theme, module), we can much better plan our efforts. If we knew that only 5% of merchants are using ASM, then probably it's not a good idea to spend a lot of effort in fixing the bugs, but maybe it's time to consider dropping this feature from the core (moving to module) instead. Php extensions are another interesting info to have, as it can answer the questions about potential features that might depend on some extension. Regarding consents. As I already wrote, the collected data are anonymised, there's no law or regulation that requires for us to obtain a consent. Regardless, we want to have the merchants the ability to decide if they want to help us collect this info or not. Unfortunately there wasn't enough time to implement all aspects of this consent mechanism. Currently, there is only a database table that governs consents. If you do not want to allow sending the info to api server, you can update table `tb_tracking_consent` and nothing will be sent to us. Of course, changing the consent in DB is not very user friendly 🙂 In the next major release there will be UI for this. There were other, more imporant tasks, to implement for 1.3.0. These consents will gain more importance once there are more 'personal' type of data to be collected. Work queue is a mechanism to run tasks outside of the main execution thread 🙂 Yeah, I know. That didn't help much. During execution of php script there might be some tasks that do not need to be executed immediately. For example, when you change order status, an email might be send. Sending email can actually take a lot of time, and that impacts the page response time. Employees have to wait couple of seconds just to see the result of this simple operation. Also, what happens if the smtp server is currently down? Yeah, the process will fail, back office page will display error message, and employee do not know what happened. With work queue we do not send emails. Instead, we just describe the 'Send email' operation as a task, and submit it to work queue executor, and immediately continue. Work queue executor will ensure that the task is executed as soon as possible. The task description can be serialized and stored somewhere. This allows us to actually run work queue executors on different servers, or in different process on the same server. It also allows us to try to recover from errors -- for example, if sending email fails, we can retry it later after some delay. There are a lot of operations that can be converted to work queue tasks. Clearing cache, generating images, webservice calls, cleanup tasks, and more. By converting these operations to work queue tasks, we can also trigger them differently. We can have a cli tool to actually run these tasks -- so you can ssh to your server and run command to clear cache, or regenerate the images. These tasks can also be scheduled using build-in scheduler. In 1.3.0, we only introduced the basic mechanisms for work queue, mostly because of scheduler that we needed. There is still a lot of work on this functionality. For example, we need to actually implement different types of work queue executors. Currently, we only have 'Immediate executor', that runs submitted tasks immediately in the context of the current thread. But in the next release, we will introduce new type of executors. There will be immediate executor -- currently available, executed tasks immediately in the context of the thread. Does not support retrying. There is not really a benefit, apart from error handling. deferred executor -- the tasks will be executed in the context of the php thread, but only **after** the response is send to the user (not all servers supports this feature, though). This will increase page response time. standalone executor -- standalone php application that can run on the same server or on other server as well. Will receive the work queue tasks via some queue (redis, kafka, memcache...). This is solution for serious merchants that want to run high performant stores I'm happy to answer any questions.

It should be safe to use this mechanism as long as you are in control of this external site.

That's correct, this is very sensitive information. This mechanism not only recover and associate the cart with your session, but also authenticate the user -- if the cart belongs to some customer, you would be logged in as this customer. This could be quite dangerous -- anyone who knows cookie key can log in as anybody.