datakick

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); } }

My 2 cents: Overrides should always be the last resort. They are quite brittle, and it might prevent future updates of your store. In this case, you can use hook actionGetIDZoneByAddressID instead of override. That would require to implement very simple module that registers this hook and implements handler function. Overall, it would not be more complex than your override. If you insist on using override, you should at least implement it in a way that utilize the parent method. Instead of public function someMethod() { // my custom code ... // copied and pasted code from core class ... } you should use public function someMethod() { // my custom code ... // call parent someMethod implementation return parent::someMethod(); } That way, it's more likely that the override will work if method 'someMethod' is changed in core in the future

Both. Database schema is different in thirty bees. In this case, what causes problems is column passwd in table tb_customer - it should be of type varchar(60), in ps16 this is varchar(32), I believe. You need to alter the database column, otherwise thirty bees won't be able to properly store hashed passwords into the database. I recommend you use 'core updater' module for this. There is 'Database Schema' comparator/corrector tool. It should display all discrepancies, and allows you to fix it as well. Once you have fixed the database schema, you should be able to change customer passwords from back office, and then be able to log in using these passwords. In order to recover ps16 passwords, you will have to use the same _COOKIE_KEY_ you used in ps16 installation. Edit config/settings.inc.php, and change value of define('_COOKIE_KEY_', 'value copied from your ps16 installation'); That should do the trick.

Yes, core updater does not report extra columns as problems -- that's because a lot of modules actually extends core tables with their own columns. It's next to impossible for core updater to distinguish between valid and invalid columns. So extra columns are not automatically fixed. In the next version of core updater, these extra column will at least be displayed None that I know about

Did you, by any chance, update to bleeding edge and then back to stable? I bet you have an extra column named 'active' in table 'tb_category_shop'. You can check using core updater

registerJavascript method was introduced into FrontController in ps17 https://github.com/PrestaShop/PrestaShop/blob/develop/classes/controller/FrontController.php#L1043 There is no such method in ps16 https://github.com/PrestaShop/PrestaShop-1.6/blob/master/classes/controller/FrontController.php Therefore, the module you purchased is not compatible with ps16 (and in extension with thirtybees)