datakick

Ability to have custom code per store is added in bleeding edge

Very nice. I've tested it, and found only a small issues. For example, escaping for separator value (I can't use separator >) Otherwise, very nice addition. Addition: for 'schema' -- it would be nice to also have {count_values} -- displays number of values {first_value} -- first value according to 'Sorting settings {last_value} -- last value according to 'Sorting' settings

Oh my, what a stupid directive. For example, if I reduce price for a single day (black friday) by 50%, I will not be allowed to announce any reduction for another 30 day, unless it's more than 50 %. Because the reduced black friday becomes prior price. Also, technically very hard to implement.

Fixed in latest bleeding edge, thanks for reporting this issue. https://github.com/thirtybees/thirtybees/commit/c024695e15c5a7f0f8c3b6fdf7859d150a577154

Of course, if the browser visited the page before you fixed the cache-control header, it will keep using cached version of the page for the next 30 days. There's no reason for browser not to do so

I have created an issue for this 'bug': https://github.com/thirtybees/thirtybees/issues/1434 In my opinion, the change to save translations per section was very bad decision, and should be fixed. Of course, the fix should ensure that the original problem with max_input_vars is addressed as well.

this will affect new orders only

Your server returns cache-control header with max-age=2592000 seconds (30 days), which instruct browsers to cache the content for 30 days. curl -I https://torchsa.com/pl-pewpew-lights/739-olight-pl-pro-valkyrie-black-or-tan-1500lumen.html HTTP/2 200 date: Wed, 11 May 2022 09:29:27 GMT content-type: text/html; charset=utf-8 set-cookie: MyCookieName-d6e7f0883bc4d518a8b11c4d02613039=hgBy4hbJ6rg3YiQ4lqfHtqUz7xUB2K4xv6bzziD6bXuC771g2miisGwjYwQHnGwbBnAg_D5HHDwR6CZYyV1-10MvsiSUcI4J-5i90ToqaKHDIRwJ2eiRQqj3LSgBVYyyOLInFKxRWPCpWFFjb5PXiobwfCi67x3w4Bg6ttbDyRt7enR4kaBZUkJn5-MgCgmoDwVquJVIztOIx9Jdo-LmkfOD7evM7An-ZUOtHeHLvVg; expires=Tue, 31-May-2022 09:29:26 GMT; Max-Age=1728000; path=/; domain=torchsa.com; secure; HttpOnly cache-control: max-age=2592000 expires: Fri, 10 Jun 2022 09:29:26 GMT You need to figure out what component in your stack is emitting this header. It can be your http server (apache / php-fpm), or it can be some proxy server you might be using. Once you figure out which one is responsible for this issue, reconfigure it. This is not thirtybees related, the same behaviour would exists if you installed any php app on your stack.

basically, increment each value by 1

update value column in configiration table. For PS_OS_PAYMENT it should be 2, for PS_OS_PAYPAL it should map to 11, etc...

Look into tb_configuration table for 'PS_OS_????' entries. Update value to valid order statuses. You can use this sql query to find out to what order statuses are config keys currently mapped -- in your case, it will be wrong: SELECT c.name, c.value, l.name FROM tb_configuration c INNER JOIN tb_order_state_lang l ON (c.value = l.id_order_state AND l.id_lang = 1) WHERE c.name LIKE 'PS_OS_%';

the wp plugin uses this code to construct image src: $src_img_product = $url_service.'/' .$result['alternate_data']['product']->product->id_default_image.'-' .$current_atts['size_img']."/".$slug.".jpg"; where $result and $slug comes from webservice response, but $current_atts['size_img'] comes from plugin configuration: 'size_img' => get_option('didpd_default_size_img') There is probably some UI element to set this config key, or maybe now. I don't know wordpress. Anyway, this is not tb webservice issue

It's not. What is needed is for end user to be able to request deletion of PII, and that's not customer account. In fact, deletion of customer account can prohibited by other laws that have precedence over GDPR directive. To be GDPR compliant, all that is needed is a notice somewhere on your website, where you inform you customers that they can request account deletion by sending email. You can then perform action manually. Note that such request will most likely never happen, as people are too lazy to actually put any effort into anything. If it happens, you can go to customer account, and delete it (if there are no orders / invoices associated). If there are invoices, you have to decide according to your country laws if it's ok to delete such account. It's quite likely you are obliged by law to keep the records of sales for few years, so the deletion can't be allowed at this point. Also -- GDPR says that you have to delete only PII information. That means, you don't have to actually delete the account itself, but you can simply mangle personal information (name, email, phone,...). Such account can no longer identify natural person, and therefore is not under GDPR directive. But it can still be very useful for analytics, trends investigation, etc.

Go to your back office, to Advanced Parameters > Logs, and use decrypt exception functionality to find out actual error message.

You need a module for that. You can test my datakick module, it has xml export functionality: https://store.getdatakick.com/en/modules/datakick-data-export-and-import. There is 14 days trial period.

It's doable, but not very friendly. Look what static methods are available in Meta class. You could you getMetaByPage, or getCategoryMetas or getCmsMetas {assign var='contactMeta' value=Meta::getMetaByPage('contact', $lang_id)} {assign var='categoryMeta' value=Meta::getCategoryMetas(4, $lang_id, 'category')} {assign var='cmsMeta' value=Meta::getCmsMetas(9, $lang_id, 'cms')} <pre> contact title = {$contactMeta.title} category title = {$categoryMeta.meta_title} cms title = {$cmsMeta.meta_title} </pre>

Are you sure that it does not work? From the code excerpt you posted, it looks like that's exactly what module configuration page should do. The module installs Menu item so you should look there for more functionality. If unsure, ask module author

Bummer. This gdprpro module is not compatible with thirtybees.

file modules/registrationfields/registrationfields.php, line 300 change to $return = []; Also, you could email module author and ask them to incorporate this fix

We really need some better way to extend object model definition. Currently there are few methods do to it, but none of them is good enough, or work in all use cases. I have seen full override (the one you have used) -- since this is not an extension of parent definition, it is very brittle. Another way to do this is to 'adjust' object model definition in constructor. That method works in some cases only, though.

Did you redefine the object model definition in your override? public static $definition = [...] If so, what were your reasons to do it?

@PeterPan These are two issues. 1) Dashboard not visible after update -- I can't confirm. I just updated my test and production env to bleeding edge, and have no problem. You will need to look into your server error logs to see what is there. Also, what php version are you using? 2) Regarding DB schema problem with auto-increment column migration -- as @wakabayashi, this is known issue, and will be fixed in upcoming version of the core updater

Looks like the problem is in the method ajaxCart.hideOldProducts (file ajax-cart.js, can be located in your theme -- themes/niara/js/modules/blockcart/ajax-cart.js, or directly in blockcart module directory) . This method is responsible for removing products that are no longer in cart. But it does not work properly. You can try to modify this method and change it to this one (always delete all products). This is not a proper fix, as it can result in some weird reordering and/or blinking of products in cart, but it should help a little: hideOldProducts: function(jsonData) { $('.cart_block_list:first dl.products dt').remove(); }, I've created issue to track this problem, hopefully it will be fixed properly sometimes in the future https://github.com/thirtybees/blockcart/issues/1

Personally, I would create new database table `tb_postcode_zone_map` with two columns `postcode` and `id_zone`, and use this db table to map from postcode to zone id. The override would then look like this <?php class Address extends AddressCore { // New function to get the postcode from the given address public static function getZoneIdByAddressPostcode($idAddress) { $idAddress = (int)$idAddress; if (!$idAddress) { return null; } return (int)Db::getInstance(_PS_USE_SQL_SLAVE_)->getValue( (new DbQuery()) ->select('pzm.id_zone') ->from('address', 'a') ->innerJoin('postcode_zone_map', 'pzm', 'pzm.postcode = a.postcode') ->where('a.`id_address` = ' . $idAddress) ); } public static function getZoneById($idAddress) { // CUSTOMIZATION $zoneId = static::getZoneIdByAddressPostcode($idAddress); if ($zoneId) { return $zoneId; } // fallback to original implementation return parent::getZoneById($idAddress); } } Again, better to do with module

Something like this: <?php class Address extends AddressCore { // New function to get the postcode from the given address public static function getPostcodeByAddress($idAddress) { $idAddress = (int)$idAddress; if (!$idAddress) { return null; } return Db::getInstance(_PS_USE_SQL_SLAVE_)->getValue( (new DbQuery()) ->select('postcode') ->from('address', 'a') ->where('a.`id_address` = ' . $idAddress) ); } public static function getZoneById($idAddress) { // CUSTOMIZATION // Use the new function $postcode = static::getPostcodeByAddress($idAddress); // Minor islands and Venice if (in_array($postcode, array( "04027", // Ponza "80073", // Capri "09014", // Carloforte "98000", // Eolie, Salina "91023", // Favignana "58012", // Giglio "80070", // Ischia "07024", // La Maddalena "92010", // Lampedusa, Linosa "98055", // Lipari "91017", // Pantelleria "80079", // Procida "71040", // Tremiti "90010", // Ustica // Venezia begin "30121", "30122", "30123", "30124", "30125", "30126", "30127", "30128", "30129", "30130", "30131", "30132", "30133", "30134", "30135", "30136", "30137", "30138", "30139", "30140", "30141", "30142", "30143", "30144", "30145", "30146", "30147", "30148", "30149", "30150", "30151", "30152", "30153", "30154", "30155", "30156", "30157", "30158", "30159", "30160", "30161", "30162", "30163", "30164", "30165", "30166", "30167", "30168", "30169", "30170", "30171", "30172", "30173", "30174", "30175", "30176", // Venezia end "57031", "57032", "57033", "57036", "57037", "57038", "57039" // Elba ))) { return 10; // ID of the zone for these zip codes } // Livigno is even more expensive if (in_array($postcode, array("23030"))) { // Array because maybe more zip codes will be added in the future return 11; // ID of the zone for these zip codes } // fallback to original implementation return parent::getZoneById($idAddress); } }