datakick

The principal of least surprise, one of the building blocks of UX. Everyone expects language selector in upper right corner. If you place it anywhere else, you will surprise your visitors. Most will never look into the footer when searching for this functionality.

There you go. There you go. Looks like you have copied AdminProductsController.php to override/controllers/admin directory sometimes in the past, modified it slightly, and forgot about it. I suggest you delete this file. You should also investigate what it was that you modified, but I don't see many changes in the file.

I agree that regular hotfix releases should exists. When I say hotfix, I don't really mean bugfix release. I mean release that fixes those issues that were introduced in the last release only. And only those issues, for which fix is very well understood and the confidence level is very high. There is not many such issues. Since 1.3.0, there were exactly 3 commits like that: https://github.com/thirtybees/thirtybees/compare/1.3.0...1.3.x , four lines in total. Why not include other bugfixes into such release as well? Well, because it comes with potential of creating more problems, mostly because of the non-linearity of the codebase. Even if the fix/commit seems safe, it might not be safe for cherry-picking to different branch. For example, imagine this one line fix in main branch $price = (float)Tools::getValue('price'); to $price = Tools::getNumberValue('price'); On the first glance, it looks quite safe to cherry pick and transfer this commit from main to bugfix branch. After all, it's but single line. But it is never so simple. In this case, the getNumberValue method was introduced only recently into main branch. If we transfer this code without the commit that introduced the 'getNumberValue' method, it would break. Problem with official releases is that it takes a lot of time. Like 8 hours of mundane manual work. Of course, we could automate this. But to automate this we would need a lot of time as well. But until this is automated, there will be just a few releases. As a workaround for the time being, I plan to introduce third channel into 'core updater'. Currently we have 'Stable' and 'Bleeding Edge', but soon we will have 'Stable', 'Stable with hotfixes', and 'Bleeding edge'. Please suggest better name for the new channel 🙂

this table is created by 'statsmodule' module, it's not part of the core

Also, get rid of step #3, and call the hook directly from the theme. Never update the core files. <div class="tab-content"> {hook h='displayHomeStaticHTML'} </div> If you need the conditional, then you can do that with capture {capture name='homeStaticContent'}{hook h='displayHomeStaticHTML'}{/capture} {if !empty($smarty.capture.homeStaticContent)} <div class="tab-content"> {$smarty.capture.homeStaticContent} </div> {/if}

Did you reset the tbhtmlblock module after you added the hook?

Overrides?

Fixed in bleeding edge, hopefully.

This is a bug in core: https://github.com/thirtybees/thirtybees/issues/1368

What checkout page are you using? Standard checkout do not need displayPaymentEU hook, displayPayment is enough. If you use advanced EU OPC, or some third party OPC, then this might be a requirement

Manually 🙂 You will need to manually merge both codes, and make sure it works properly. I suggest you to remove your original override completely, and use different approach to block outgoing email. You can use my Consequences module to block this particular email from being send, for example.

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?