datakick

https://github.com/thirtybees/niara/blob/15e5338e628fca184a339d6cde66c961bfeb8169/modules/homefeatured/homefeatured.tpl#L4

Very nice, thank you. I believe the reason why this functionality was disabled was because it's not possible to have downloadable products per combination, which is something that a lot of people would expect. For example, if you sell modules, it is reasonable to expect that there could be different zip files for attribute platform (values thirtybees / prestashop 1.6 / prestashop 1.7). But even with this limit, it's definitely useful to have combinations for virtual products. With that, you can sell modules with different level of support, for example. I'll test your changes and merge them shortly

It make sense in B2B mode. Not so much in B2C

Actually, when you generate invoice, and no payments are recorded yet, system will create new payment record. https://github.com/thirtybees/thirtybees/blob/8b522e19ccaadd1ba6570d5d853628bd7f471ed8/classes/order/Order.php#L1590 There is a comment in code: Since an invoice always requires an existing order payment, we are going to add one Looks like thirty bees does not support unpaid invoices??? Anyway, if you modify the order after the payment is recorded, you should record additional payment (possibly negative) All payments will be displayed on invoice, making it match

I can't reproduce this behaviour. The system defaults to reduced price, but still accepts custom unit price. Even if I then change quantity, it works as expected. Do you have override for AdminCartController SpecificPrice Cart ??

I don't really know what you are talking about. Could you please describe your set up, what is expected and what is actual behaviour of the system?

That's a strange condition. I believe we should remove this, there's no reason to not support 'free gifts' from back office

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