datakick

I meant that modules should not use hardcoded string 'home' or 'cart' like this <img src="{$link->getImageLink($rewrite, $imageId, 'home')}"> Because 'home' image type does not have to exists. Modules should allow user to select image type they want to use in configuration page, and pass this selection to template. <img src="{$link->getImageLink($rewrite, $imageId, $selectedImageType)}"> Unfortunately, a lot of module developers don't do that (some of my own modules are using hardcoded image types as well), and that can cause troubles. And the need for this 'guessing' type detection.

You can edit specific prices in 1.4

Compatibility reasons. Image type name should always be provided without theme prefixes, for example 'home' or 'cart'. However, sometimes module developers used 'home_default' instead of 'home', where 'default' is name of ps16 default theme 🙂 Such module worked correctly on default theme only. Then some theme developer copied default theme, but kept the image type names 'home_default', which ultimately lead to formatted name like 'Niara_home_default'. So yeah, there is a lot of fixing and adjusting, otherwise most module would stop working. This test summarize this mess quite nicely: https://github.com/thirtybees/thirtybees/blob/main/tests/Unit/ImageTypeTest.php I don't think that module developers need specific sizes that often. What they want is their module to integrate seamlessly into the theme design. To do that, they should not make any assumptions about image sizes in the first place. For example, there can be a theme that displays very large product images on home page. Instead of standard 250x250, this theme renders only few products on home page with 500x500. Any module that want to display on home page some additional products should probably render it in the same size, otherwise it would look bad. If module developer used here getImageTypeBySize(250, 250) the result would not be nice. I think that image type abstraction is not a bad thing. What is wrong is hardcoding image types into templates. These should be configurable. Nowhere in the templates we should see strings constants. I agree that it would be very nice addition to have a method to choose image type by size. Sometimes it is indeed needed.

I've just released new version 0.9.2 that fixes the problem with delivery option saving. Everyone, please update module !!!!

Oh, that's a huge bug. Thanks for reporting it, I will fix it ASAP.

Module now keeps images in /img/homeslider directory. The default module template displays the image properly. However, if you theme has override for the template, it may be looking into wrong place for images. Edit file /themes/<theme>/modules/homeslider/homeslider.tpl and replace src="{$link->getMediaLink("`$smarty.const._MODULE_DIR_`homeslider/images/`$slide.image|escape:'htmlall':'UTF-8'`")}" with src="{$link->getMediaLink($slide.imageUrl)|escape:'htmlall':'UTF-8'}" As you can see, original implementation used hardcoded path to module directory. That's just wrong. New implementation simply displays the url that module provides.

That is the case. Module use the same configuration keys as core used before, so the configuration is reused as it is. Yes, we will reintroduce this. I'm not sure where to implement this, though. It can be either in the core (then new email template would be required), or in individual transport libraries.

This is actually just bad text (and link) in back office. Thirty bees is using APCu, not ACP. I will tidy this up.

Since 1.4, Db::executeS() will raise warning if used for non-select sql statements. That might be the reason why you are seeing this problem. For sql statements like INSERT or UPDATE, you should use Db::execute(), and executeS() should be used for SELECT queries only. However, for those there are better alternatives, as Db::executeS() does not guarantee return type to be an array (it can be false, or null). You should use Db::getArray() / Db::getRow() / Db::getValue() instead. I have fixed the error collection in core, you can look here: https://github.com/thirtybees/thirtybees/commit/3fa91183536ebac1454f3641d429d7c193beac25

What comes to mind is error handling. If you do a lot of work in cycles then this might be caused by some repeating php warning. All php messages are collected in one array (unlimited, which is not good, we should definitely limit this). And if you have installed collectlogs module, there will also be overhead related to this module.

This .htaccess rule might work. Didn't test it, thought RewriteRule ^da/(.*)$ /$1 [R=301,L]

Look for SimpleXML section. Looks like this one: If it's not there, you don't have this php extension enabled.

It's possible that your php configuration for CLI and http server are different. You can create simple php file phpinfo.php inside root directory with this content: <?php phpinfo(); to see your server php configuration

Delete the code if (!$dbInstance instanceof DbPDO) { throw new DBException( sprintf('DB Instance should be instance of DbPDO, we get %s', get_class($dbInstance)) ); } from file /modules/prestabay/library/PSR4/Involic/Repository/AbstractRepository.php

There were very few breaking changes in php7.3 and php7.4 releases. It is very likely you can safely update. It's not like updating to php8. You will probably see a lot more warnings in your logs after. But that's a good thing. You should fix those before you move forward to php8.

Code in bleeding edge is NOT compatible with PHP7.2. The lowest supported php version is 7.4. Core updater will not allow you to update to latest commits, as it would break your store. It offers you the last commit that was PHP7.2 compatible -- fcf3987d011c85bb59dd7b75c9c75ef91b715036. I suggest you update your server to PHH7.4. If your store runs on 7.2, it should run without issues on 7.4 as well. Then run core updater, and update to bleeding edge.

Technically, it is a bug in the module. Module is calling Link::getImageLink method with wrong parameter. It passes array instead of string as image name. That is a bug - you should report this to module developer and ask them to fix it. This is most likely caused by loading Product instance in all-language context: $product = new Product(1); print_r($product->link_rewrite); This will display array of all link_rewrites in all languages. Module probably pass this link_rewrite to $link object If module loaded objet in single language context, it would work. Following code displays string $product = new Product(1, false, 1); print_r($product->link_rewrite); In 1.3.0, this invalid parameter was silently converted to string, and system returned image url like this: https://domain.com/111-Niara_home/Array.jpg Since image name is not important, it worked, and nobody probably reported this. In 1.4.0, there is new function in the pipeline that expects and accepts only string, and that now throws exception. While this is a bug in module, I think it's a good idea to support the old behaviour for some time as well. I have committed fix into bleeding edge that will convert input Array to string if needed, and it will also raise warning: https://github.com/thirtybees/thirtybees/commit/809f16c2fa318a981685ad20d5498b4971676ba1 You should: update to bleeding edge using core updater install collectlogs module use module, and then copy error messages from collectlogs and send them to module developer. That will help them to fix this faster

If you use cloudflare, you can also use my cloudflare-geoip module: https://store.getdatakick.com/en/modules/cloudflare-geoip Then you will not have to update your local version of maxmind database every now and then. And their db is probably more precise then free version from maxmind

Themes should not be responsible for constructing paths to assets. That creates dependency, and only leads to issues like this - it is very to change asset location without breaking themes. Please use this instead: src="{$link->getMediaLink($slide.imageUrl)|escape:'htmlall':'UTF-8'}"

Works properly on my local environment, with both normal 5 step checkout and OPC. Tested on 1.3.0, 1.4.0, bleeding edge. Same behaviour.

Heads up for those of you who are running on bleeding edge. We just committed a big change -- removed swiftmailer library from the core. This php library for sending was quite outdated and is no longer supported. In new versions of php it raises a lot of warnings. It just had to go. Instead of deciding on another library to put as a dependency, we simply removed email sending functionality from core completely 🙂 To send emails, you will have to install some module that implements MailTransport interface. For backwards compatibility, we have released a brand new module tbswiftmailer that does exactly this, using that outdated library we have just ripped from the core. So, if you update to bleeding edge, and install the tbswiftmailer module, you should be in the same situation you are now. In the future, we will release a new mail transport library, that will implement sending emails using different third party library, probably symfony/mailer

You can add this to your theme css (or using back office Custom Code) .chex-edit { opacity: 1 !important; }

Tax calculator needs specific address, it is not based only on countries. For example in US sales tax can be different in different states/counties/cities/postcode ranges. Thirty bees actually displays price for selected delivery address. The problem is that in most cases the address is not selected before you go to checkout page. You can test it: go to checkout page, create new address for example in the US, and then go back to your catalog. You should see your prices displayed without tax. If you choose address in different EU country you should see prices for that country. We could make a module that would create 'dummy' addresses on the fly based on your geolocation (by default) allowed you to select your country in some select box on front office (explicit selection) and make sure that the dummy address is actually deleted before you go to checkout page I do something similar in chex module to determine final price.

In my opinion there have to be some sort of 'complete' button, otherwise different issues would occur. For example, removing product from cart by mistake. I can add some prominent 'Save changes' button that appears only when there are some modifications, but is has to be there.

gridhtml module is not compatible with thirty bees since version 1.0.4 - its functionality was merged into core. This module was probably uninstalled in the past, but was still present on filesystem in /modules/ directory. Unfortunately, thirty bees sometimes have to load and instantiate even non-installed modules. For example, when module's config.xml file is missing, or if language-specific version of this xml file is missing (config_cs.xml, config_nl.xml,....). This config.xml file is sort of a cache that contains basic information about module (name, description, author). When you open Modules page in admin, system opens all these config.xml files in order to display information about modules that are available on your system. If config file is missing in module directory, system have to instantiate the module and extract info from module instance properties. This is very stupid approach, and also very dangerous. Because it actually loads module main php file, and executes any executable code. The code may be malicious. In this case, the main module file contains class that can no longer be instantiated. Thus the exception. And it's also explains why store owner didn't encounter the issue -- they may use different language than you do. We know and track this issue. However, it's very hard to fix. The alternative is static analysis of module main php file during runtime. That is very, very complicated.