datakick

It's a actually a bug that you don't have these images 🙂 Compare result (with and without) After installation, these images actually exists. But over the time they are lost, which is a bug https://github.com/thirtybees/thirtybees/issues/1503

Most select queries should work. If not, please file issue on github. Recently, we have fixed some issues in this area, so it's best if you could update to bleeding edge and test there.

This curl command fails: curl -H"Accept-Encoding: gzip" "https://instruments.co.za/attachment?id_attachment=155" --output file.zip Which means your server has some input/output compressing issues. Check mod_deflate configuration

This does not look like an application issue, most likely server configuration issue. It's quite funny, actually. The attachment can be downloaded using 'curl' command without problem: curl https://instruments.co.za/attachment\?id_attachment\=155 --output file.zip However, when opened in browser, 500 error code is returned. There must be some very clever and useful and idiotic security settings enabled on your server. Ask your hosting provider.

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