Raymond

Hello Surely not all merchants want the same, but that's how it goes with every feature, module or else..., one thing is sure, to comply with GDPR all the data must be deleted when the user request it. The userdel module actually offer just 3 options in the admin panel there is a slider button to set the test mode or live mode, that to simulate and check if there are problems in general a second slider button allows to set the module to process or not process orders the third slider button if the second button is set to process orders allows to set the module to either keep the orders in the database in an anonymized form or delete the data That's all, actually this module does not offer other options On the front side the user in the account page has a button to see a resume of all the data (that is handled by the module, it could be enhanced to retrieve also other sensible data, e.g. newsletter subscription or else). In that page there is another button with which the user can delete the data and the whole account, if clicked the data will be erased and the orders will be either erased or anonymized accordingly to what the admin settled in the back office There are no other functions or options, at the moment, but I hope that this module could be developed to cover more aspects and possibilities. The module is very simple, seems that the most is done in one file named userdel.php which counts about just 421 lines, even not being a coder I can see more less what does It was working on previous versions of TB, since TB1.3 does not, as I wrote does not throw errors, pretty simply do not delete the account any more. I attached it, I guess is not hard to fix it. I also guess that could be used to enhance the TB GDPR compliance module (which by the way to be completed should also do more things), or something similar could be included in the core of TB. As I wrote in more posts according to me an e-commerce platform today should natively include these functionalities. Thank you userdel-module.zip

Hello I agree with both, deleting might cause problems, but must be possible to delete things if done right, furthermore, definitely (being able to and) keeping the DB lean does not sound at all a bad idea, on the contrary I guess it is a good practice. I checked again the "free userdel module by Metacreo", it was given out for free on prestashop forum, then disappeared, the files inside are all marked with a GPL3 license, so Think there is no problem to share it here. IS it OK if I upload it here? Will anyone of you experts fix it or at least help me to fix it (I am no coder btw, but I can follow instructions) and share it back so everyone can use it? Maybe could also become a thirty bees free module once is fixed for good... Thank you Best regards

Hello I noticed that switching theme a warning is given about non-theme related hooks being ignored. What is meant exactly by "non-theme related"? I have seen in the list that some of the modules are from the theme, why then are considered "non-theme related"? What does imply to have all those hooks not registered? At the end of the list there is a more serious warning about modules from the theme for which hooks where not defined in the theme's xml file, I will contact the developer as suggest, however, what kind of inconsistencies will be caused by this? The warning output is below Thank you Some warnings were encountered during theme installation. Following non-theme related hooks were ignored Theme instructs thirty bees core to register hooks that are not theme related. These requests were ignored Hook actionCartListOverride from module blockcart_mod Hook actionAdminLanguagesControllerStatusBefore from module blockcategories Hook actionAdminMetaControllerUpdate_optionsBefore from module blockcategories Hook actionCategoryAdd from module blockcategories Hook actionCategoryDelete from module blockcategories Hook actionCategoryUpdate from module blockcategories Hook displayBackOfficeCategory from module blockcategories Hook actionAttributeDelete from module blocklayered Hook actionAttributeGroupDelete from module blocklayered Hook actionAttributeGroupSave from module blocklayered Hook actionAttributePostProcess from module blocklayered Hook actionAttributeSave from module blocklayered Hook actionCategoryAdd from module blocklayered Hook actionCategoryDelete from module blocklayered Hook actionCategoryUpdate from module blocklayered Hook actionFeatureDelete from module blocklayered Hook actionFeatureSave from module blocklayered Hook actionFeatureValueDelete from module blocklayered Hook actionFeatureValueSave from module blocklayered Hook actionProductListOverride from module blocklayered Hook actionProductSave from module blocklayered Hook actionObjectCategoryDeleteAfter from module stbanner Hook actionObjectManufacturerDeleteAfter from module stbanner Hook actionShopDataDuplication from module stbanner Hook actionProductAdd from module stbestsellers Hook actionProductDelete from module stbestsellers Hook actionProductUpdate from module stbestsellers Hook GSitemapAppendUrls from module stblog Hook actionShopDataDuplication from module stblog Hook displayAdminHomeQuickLinks from module stblog Hook displayBackOfficeHeader from module stblog Hook moduleRoutes from module stblog Hook GSitemapAppendUrls from module stblogarchives Hook moduleRoutes from module stblogarchives Hook moduleRoutes from module stblogsearch Hook actionObjectManufacturerDeleteAfter from module stbrandsslider Hook displayAdminProductPriceFormFooter from module stcountdown Hook actionShopDataDuplication from module steasycontent Hook actionCategoryDelete from module steasytabs Hook actionProductAdd from module steasytabs Hook actionProductDelete from module steasytabs Hook actionProductUpdate from module steasytabs Hook displayAdminProductsExtra from module steasytabs Hook actionCategoryAdd from module stfeaturedcategories Hook actionCategoryDelete from module stfeaturedcategories Hook actionCategoryUpdate from module stfeaturedcategories Hook actionProductAdd from module stfeaturedslider Hook actionProductDelete from module stfeaturedslider Hook actionProductUpdate from module stfeaturedslider Hook actionProductAdd from module sthomenew Hook actionProductDelete from module sthomenew Hook actionProductUpdate from module sthomenew Hook displayBackOfficeHeader from module sthoverimage Hook actionObjectCategoryDeleteAfter from module stiosslider Hook actionShopDataDuplication from module stiosslider Hook actionCategoryAdd from module stmegamenu Hook actionCategoryDelete from module stmegamenu Hook actionCategoryUpdate from module stmegamenu Hook actionObjectCategoryDeleteAfter from module stmegamenu Hook actionObjectCategoryUpdateAfter from module stmegamenu Hook actionObjectCmsDeleteAfter from module stmegamenu Hook actionObjectCmsUpdateAfter from module stmegamenu Hook actionObjectManufacturerDeleteAfter from module stmegamenu Hook actionObjectProductUpdateAfter from module stmegamenu Hook actionObjectSupplierDeleteAfter from module stmegamenu Hook actionProductAdd from module stmegamenu Hook actionProductDelete from module stmegamenu Hook actionProductUpdate from module stmegamenu Hook actionShopDataDuplication from module stmegamenu Hook hookActionObjectProductDeleteAfter from module stmegamenu Hook actionObjectCategoryDeleteAfter from module stmultilink Hook actionObjectCategoryUpdateAfter from module stmultilink Hook actionObjectCmsDeleteAfter from module stmultilink Hook actionObjectCmsUpdateAfter from module stmultilink Hook actionObjectManufacturerDeleteAfter from module stmultilink Hook actionObjectManufacturerUpdateAfter from module stmultilink Hook actionObjectSupplierDeleteAfter from module stmultilink Hook actionObjectSupplierUpdateAfter from module stmultilink Hook actionShopDataDuplication from module stmultilink Hook actionCustomerAccountAdd from module stnewsletter Hook actionDeleteGDPRCustomer from module stnewsletter Hook actionExportGDPRData from module stnewsletter Hook registerGDPRConsent from module stnewsletter Hook actionObjectCategoryDeleteAfter from module stowlcarousel Hook actionObjectManufacturerDeleteAfter from module stowlcarousel Hook actionShopDataDuplication from module stowlcarousel Hook actionObjectCategoryDeleteAfter from module stpagebanner Hook actionObjectCmsDeleteAfter from module stpagebanner Hook actionObjectManufacturerDeleteAfter from module stpagebanner Hook actionObjectSupplierDeleteAfter from module stpagebanner Hook actionShopDataDuplication from module stpagebanner Hook actionShopDataDuplication from module stparallax Hook actionCategoryDelete from module stproductcategoriesslider Hook actionObjectCategoryDeleteAfter from module stproductcategoriesslider Hook actionProductAdd from module stproductcategoriesslider Hook actionProductDelete from module stproductcategoriesslider Hook actionProductUpdate from module stproductcategoriesslider Hook actionProductDelete from module strelatedproducts Hook actionProductUpdate from module strelatedproducts Hook displayAdminProductsExtra from module strelatedproducts Hook actionProductAdd from module stspecialslider Hook actionProductDelete from module stspecialslider Hook actionProductUpdate from module stspecialslider Hook displayAdminProductPriceFormFooter from module stspecialslider Hook actionShopDataDuplication from module stthemeeditor No hooks defined for following modules Theme installed or enabled following modules but didn't provide hook list for them. Theme should always provide hook list in order to achieve consistent results. If no hooks are specified in config.xml file, module hook list will remain unchanged. If this is wanted behaviour, theme developer should make it explicit by adding manageHooks="false" into module entry No hooks are defined for module stfblikebox in theme config.xml file No hooks are defined for module stblogcomments in theme config.xml file No hooks are defined for module stblogrelatedarticles in theme config.xml file No hooks are defined for module beesblogpopularposts in theme config.xml file Please contact theme developer and request correction of theme config.xml file

Hello Yes I double checked, does not work, This is the manual of the module, all what in the manual is said that should be shown in the configuration panel of the module is not showing up, only the other panel reachable via the tab menu is showing up probably correctly, ut I ma not sure that works well, I cannot test the rest and I have no idea where to get the error log, nothing is show despite the debug mode is active. I will ask them, but i guess they will simply answer that is not for TB, that I bought it years ago and so on... who knows... maybe not... The question that rose from that is: if existing, which logs one can check in TB to find problems that do not throw an error while debug mode is on? However It is a bit of a long frustrating story overall... I bought that module in 2017, did work fine, then I stopped using it when upgraded to PS 1.6as the fields I needed could be covered recycling the SIRET, APE and DNI fields, this was even an advantage since GDPR started because all the GDPR modules surely do collect all data from those fields, while it is not sure that can collect data form new fields one add by hand or with modules (and of course one tends to not choose the complicate way, what works out of the box generally is better, does not seem a good idea to fiddle everywhere every time isn't it?). When I switched to TB I could use the same arrangement. Until TB 1.2 all went fine, with some workaround I could cover all basic aspects of registration, GDPR, including the possibility for the clients to delete their own account without having to ask for, having to delete the data upon request is just extra work for the merchant (the result is exactly the same, if the client want to delete data one has to delete it , that's it) Now with TB 1.3 I can't understand why the SIRET, APE DNI and also the other fields that can be added in the address format in the country do not show up in the registration form... Are those SIRET DNI APE OTHER fields definitely disabled? Is there a way to use it still? So I thought to get back to that custom registration fields module and see if I could put it in use again but seems that I am out of luck at this point Needless to say that just as it happened with many other modules, also expensive ones, I did not like this custom registration fields ting very much, it had its own issues too at the time, but at least worked for a while... and this point is quite important to be noted to better understand what is the final feeling I had using PS and that I do not want to get again... The reason for which I threw PS under the bus is that I constantly had to fiddle with the very basic things to no avail, it had been somehow a continuos loss of time for relatively "simple" basic things that should be as solid as the foundations of a system... The real trouble is that the world changed, while TB, PS and practically also all the others did not not change as much, today IMHO an e-commerce platform must have built in as basic core all these features required by GDPR and similar laws around the world. It is not just a matter of paying some money and time to get these features, the major problem is about reliability and security, it is all about to be reasonably sure that at least all these feature required by law in a growing amount of countries will work fine in the time also after updates and upgrades of the core. To get a clearer vision of what is happening I found this article: https://www.endpointprotector.com/blog/data-protection-legislation-around-the-world/ On the other side how many e-commerce platform do come out of the box with the features required built in and secured to be maintained in the time along with the ongoing core development? Maybe 0, nul , zero... Let's suppose that all these laws never existed or that will be ceased, so, let's go beyond the fact that these laws do exist, what's wrong in having a system that can be settled in such a way to build a transparent fair relation between services/goods' suppliers and the customers? Having easy way to clear pretty well forehand what the agreements are, get the clear consent of the users, let the users review, modify, retrieve and delete their own data/consents and/or delete their own account does not sound strange at all to me... this at least, I do not want to comment all the rest about these rules, but that part is quite understandable and shareable I think... just my 5 cents on this topic... Thank you for the help

Hello I did what you said on the registration fields module, it could be installed, but entering it to configure it do shows only a line to add a registration field and a save button, and nothing else as it should. Trying to save the new registration field output that the field was saved and shows nothing else again but the same line to add a new registration field, seems that cannot work on TB.1.3 as it is done now. TB in this case does not output debug information tough, what should I do to get information from the system when does not throw error reports with debug mode on? Thank you

I recalled that the GDPR module had the same problem since start with TB, and I already got help here back then, at that time you suggested to do the following found in this post, I did the same, seems that works again: I now try to install the module for the registration fields, thank you.

Hi Data Bummer, yes, that is a bad new. However until the version 2.1.18 worked. I reverted to the last functional version I have... Too bad 😞 Which module for the GDPR would you suggest that is surely compatible with TB and that hopefully will keep being so? Thank you

Thank you Data I will do it By the way, I uninstalled that module and did something else in the meanwhile, i updated another module, for GDPR... apparently worked, but then browsing in the configuration pages of the module I got this new error, which made the website throw the same error whatever menu item I click now Thank you ThirtyBeesException Cannot make static method ObjectModelCore::createDatabase() non static in class CustomObjectModel in file modules/gdprpro/src/CustomObjectModel.php at line 201 Source file: modules/gdprpro/src/CustomObjectModel.php 182: } 183: $sql .= $field_name . ' ' . $field['db_type']; 184: if (isset($field['required']) && $field['required']) { 185: $sql .= ' NOT NULL'; 186: } 187: if (isset($field['default'])) { 188: $sql .= ' DEFAULT "' . pSQL($field['default']) . '"'; 189: } 190: $sql .= ','; 191: } 192: $sql = trim($sql, ','); 193: $sql .= ')'; 194: Db::getInstance()->execute($sql); 195: //create multilang tables 196: if ($multilang) { 197: $sql = 'CREATE TABLE IF NOT EXISTS ' . _DB_PREFIX_ . $muchTableMuchProtected . '_lang ('; 198: $sql .= pSQL($definition['primary']) . ' INTEGER UNSIGNED NOT NULL,'; 199: $sql .= 'id_lang INTEGER UNSIGNED NOT NULL,'; 200: if ($definition['multilang_shop']) { 201: $sql .= 'id_shop INTEGER UNSIGNED NOT NULL,'; 202: } 203: foreach ($definition['fields'] as $field_name => $field) { 204: $field = $this->sanitizeColumnDefinition($field); 205: if ($field_name === $definition['primary']) { 206: continue; 207: } 208: if (!$field['lang']) { 209: continue; 210: } 211: $sql .= pSQL($field_name) . ' ' . pSQL($field['db_type']); Stack trace 1. modules/gdprpro/src/CustomObjectModel.php source Fatal error() 1:<?php 2:/** 3: * PrestaChamps 4: * 5: * NOTICE OF LICENSE 6: * 7: * This source file is subject to the Commercial License 8: * you can't distribute, modify or sell this code 9: * 10: * DISCLAIMER 11: * 12: * Do not edit or add to this file 13: * If you need help please contact [email protected] 14: * 15: * @author PrestaChamps <[email protected]> 16: * @copyright PrestaChamps 17: * @license commercial 18: */ 19: 20:/** 21: * Class CustomObjectModel 22: */ 23:abstract class CustomObjectModel extends ObjectModel 24:{ 25: /** 26: * Return informations of the columns that exists in the 27: * table relative to the ObjectModel. If the Model has multilang enabled, 28: * this method also returns information about the multilang table. 29: */ 30: public function getDatabaseColumns()

Hello I tried to install a module to add new fields to the registration form, I got an internal server error, switched on debug and got this below... What should I do to solve it? Thank you ThirtyBeesException Cannot use string offset as an array in file modules/registrationfields/registrationfields.php at line 302 Source file: modules/registrationfields/registrationfields.php 283: $helper->allow_employee_form_lang = Configuration::get('PS_BO_ALLOW_EMPLOYEE_FORM_LANG') ? Configuration::get('PS_BO_ALLOW_EMPLOYEE_FORM_LANG') : 0; 284: $this->fields_form = array(); 285: 286: $helper->identifier = $this->identifier; 287: $helper->submit_action = 'submitConfiguration'; 288: $helper->currentIndex = $this->context->link->getAdminLink('AdminModules', false).'&configure='.$this->name.'&tab_module='.$this->tab.'&module_name='.$this->name; 289: $helper->token = Tools::getAdminTokenLite('AdminModules'); 290: $helper->tpl_vars = array( 291: 'fields_value' => $this->getConfigFieldsValues(), 292: 'languages' => $this->context->controller->getLanguages(), 293: 'id_language' => $this->context->language->id 294: ); 295: return $helper->generateForm(array($fields_form)); 296: } 297: 298: public function getConfigFieldsValues() 299: { 300: $return = ''; 301: foreach (Language::getLanguages(false) as $lang) { 302: $return['REGISTRATION_FIELDS_HEADING'][(int)$lang['id_lang']] = Tools::getValue('REGISTRATION_FIELDS_HEADING_'.(int)$lang['id_lang'], Configuration::get('REGISTRATION_FIELDS_HEADING', (int)$lang['id_lang'])); 303: } 304: return $return; 305: } 306: 307: public function hookActionCustomerAccountAdd($params) 308: { 309: $id_customer = (int)$this->context->cookie->id_customer; 310: $objModel = new Fields(); 311: $objModel->saveFieldValues(Tools::getValue('fields'), $id_customer); 312: } Stack trace 1. modules/registrationfields/registrationfields.php:291 source RegistrationFields->getConfigFieldsValues() 272: 'submit' => array( 273: 'title' => $this->l('Save'), 274: ) 275: ), 276: ); 277: 278: $helper = new HelperForm(); 279: $helper->show_toolbar = false; 280: $helper->table = $this->table; 281: $lang = new Language((int)Configuration::get('PS_LANG_DEFAULT')); 282: $helper->default_form_language = $lang->id; 283: $helper->allow_employee_form_lang = Configuration::get('PS_BO_ALLOW_EMPLOYEE_FORM_LANG') ? Configuration::get('PS_BO_ALLOW_EMPLOYEE_FORM_LANG') : 0; 284: $this->fields_form = array(); 285: 286: $helper->identifier = $this->identifier; 287: $helper->submit_action = 'submitConfiguration'; 288: $helper->currentIndex = $this->context->link->getAdminLink('AdminModules', false).'&configure='.$this->name.'&tab_module='.$this->tab.'&module_name='.$this->name; 289: $helper->token = Tools::getAdminTokenLite('AdminModules'); 290: $helper->tpl_vars = array( 291: 'fields_value' => $this->getConfigFieldsValues(), 292: 'languages' => $this->context->controller->getLanguages(), 293: 'id_language' => $this->context->language->id 294: ); 295: return $helper->generateForm(array($fields_form)); 296: } 297: 298: public function getConfigFieldsValues() 299: { 300: $return = ''; 301: foreach (Language::getLanguages(false) as $lang) { 2. modules/registrationfields/registrationfields.php:252 source RegistrationFields->renderForm() 233: Db::getInstance()->Execute('DROP TABLE IF EXISTS '._DB_PREFIX_.'fmm_registration_fields_shop'); 234: 235: return true; 236: } 237: 238: public function getContent() 239: { 240: $output = ''; 241: if (Tools::isSubmit('submitConfiguration')) { 242: $message_trads = array(); 243: foreach ($_POST as $key => $value) { 244: if (preg_match('/REGISTRATION_FIELDS_HEADING_/i', $key)) { 245: $id_lang = preg_split('/REGISTRATION_FIELDS_HEADING_/i', $key); 246: $message_trads[(int)$id_lang[1]] = $value; 247: } 248: } 249: Configuration::updateValue('REGISTRATION_FIELDS_HEADING', $message_trads, true); 250: $output .= $this->displayConfirmation($this->l('Configuration updated')); 251: } 252: return $output.$this->renderForm(); 253: } 254: 255: public function renderForm() 256: { 257: $fields_form = array( 258: 'form' => array( 259: 'legend' => array( 260: 'title' => $this->l('Configuration'), 261: 'icon' => 'icon-cogs' 262: ),

Hello I used the " Module Delete User own Account v1.0 - by Metacreo " with success on Tb1, works fine, it allows to see the data, delete the data only or delete data and the entire user account, exactly what is needed to fully comply with part of the GDPR rules, best of all does not require the admin to intervene, which is a great thing (at least for my case and point of view, and btw, on the gdpr directive it is specified that the user should be able to operate without admin help). Now I am trying to use it on TB 1.3 and noticed that do not work any more. The module behaviour on TB 1.3 is the following: apparently does work, does not throw errors, the procedures are carried out, but data and account are NOT deleted, so in fact the user even after deleting the entire account keeps logged in, can see own account and data and even logging out then can login again and see all his data intact, repeating the operation does output same result. I tried it also on a fresh TB 1.3 installation with no other modules or themes installed but the original ones only. what did change in Tb1.3 that prevents the old method to delete data and account to work? I have no idea of where I should look at By the way, apart fixing this one that to my knowledge is the only one being simple and perfectly doing those 3 simple things right and without any hassle, does anyone know a module that can cover all the GDPR requirements that is known to work just fine with TB1.3? BTW, I agree with Slick 303, such a function should be built in and ready out of the box, so there would be no need to fiddle with modules and stuff to have this simple functionality, furthermore according to me all of the cookies and GDPR directives should be covered with built in tools, this is not only a way to meet those requirements, but also a way to allow dealers to setup more transparent and user friendly e-commerce websites in general, also in countries where all these rules are not mandatory (btw, there are over 20 major countries in EU, it comprises a population of hundreds of millions, it is not a marginal little market) Thank you for the help.

Hello Since some time when I try to visit the download page on https://thirtybees.com/download/ for very odd reasons I cannot achieve to understand I do wait forever and I cannot see the page, while the whole rest of your website and the forum do work just as normally should. I tried to visit the page using a proxy and it works, using a vpn and it works, I thus suppose that must be something on my PC or the network between me and your server. But what? Can maybe be something on your website preventing right my IP to see your donwload page on the website? I do not think so, seems absurd to be blocked only on a specific page Thus what should I check to discover the reason for which I cannot visit just that page of your website? Tracert does not allow to check a specific folder as far as I know, which other instrument I could use to check what/where the access to the specific download page is blocked? Thank you for any help ... Bye ============ Ok, sorry, I discovered it, was the ad blocker ABP strange behaviour tough ^^ Bye

Bonjour J'ai visité votre site web, le formulaire n'est pas gratuit comme vous l'écrivez ici. Est-ce une erreur ? Ou en fait, ce module n'est pas gratuit ? Merci. Cordialement

Hello The problem of too many combinations coming out from automatic generation can be solved with modules done for this purpose, but are costly and the one that tried is also not really a big solution according to my tastes, I decided to not use it any more, it costed me over 200$, do ravage in the core, is hard to style, lots of mangles and work to be done to have it working I found out another module that for my case is even more useful, but does work on a different principle and do not do the same, just similar thus, do cost much less and do not require any core modd. It is very useful to create "solutions", e.g., let's make the example of a customized PC. I do create all the products that can be used with a barebone base PC, the module allow to associate all those products in the product page of the barebone PC, with possibility to add some rules, eg. required, optional, single item, more items and so on. So the client open the page of the barebone PC, can also find some basic combinations done with the built in combination system (or as many as needed, that falls back to the combination system, is independent, eg. colour of the case, power supply, format etcetera...), then in the the lower part of the page find a section created by the module where there are menus to add items, eg. memory, hard disks, cables, cards, fans, whatever one want to propose to the client. The client choose some combination, then choose the additional items and build up its own custom PC, the module create a list of the "solution" so created and calculates the price, then in the cart everything is added as usual. Works pretty well, is not heavy, does not slow down the system. What I really miss, and have seen no one module doing that in the many e-commerce platforms around, are the logic conditions, e.g: - if you do use component A then show components D, G, H - if then component H is chosen do show components T, X, W and so on... - if at a certain point the client do choose a Component Z prompt the client to add the component B as a useful option, or, if the client choose components Z AND component W, force the client to add the component J as mandatory, and so on... It would be wonderful to see some kind of product builder using logic conditions into TB In the past I tried to get more information in such systems and discovered that do exist what are called "rules engines" to be used in such systems.... https://martinfowler.com/bliki/RulesEngine.html Thank you Best regards

Hello As far as I understood the point is to mitigate what I think that can be called the "third man in the middle attack", I think that Datakick's examples are pretty much pertinent and self explanatory, using these headers and in particular CSP makes it more difficult. From a non expert point of view as mine is it appears anyway quite clear and logical that when the server and the browser are instructed to not accept "things" coming from sources that are not expressly declared as legit can sensibly reduce the possibility for anyone to inject on the fly instructions to deviate the client toward a malicious server and receive deceptive data or vice versa. I understand that the use of these headers makes the whole work of the developer/implementer/merchant all more difficult and also costly, however, while of course as a principle is always good to try to patch everything in the software used it is also as well always good as a principle to try to patch everything else that gets in relation with the software used, thus I think that hardening the methods with which the client server communication happens is just logic and a better practice. As a matter of fact 100% security is maybe never achievable, but the harder is to get around security protocols the better are the chances that an attacker fails, so why not at least try to implement all what is reasonably possible to do? The CSP rule I did set is extra permissive, I also use the mod_security using WAF rules from Comodo, at the moment almost everything seems to work well, I need to study more on this and I will report here my findings, anyone interested please participate to this initiative, it would be very good to find out the proper "recipe" to have a good CSP policy that works fine with TB. Thank you Best regards

Hello Everybody Doing searches in order to have my SSL and then the Headers set right I had to begin to reason about one specific header, the Content Security Policy header aka CSP. This header must be set in specific ways depending on the software used in the domain, CSP rules must be set specific for a given software or groups of software used on the domain, e.g if a person do use TB must have the proper rules in the CSP header in order to have it working right and at the same time harden the security of the website. While searching I stumbled upon an interesting module done for wordpress, it analyses all the broken requests after implementing a CSP rule and output the formatted string to be added to the CSP rules set in order to have wordpress work fine. So I thought to express this wish, would be very nice to have a native TB module doing this task, the principle is very simple, the user build the website installing all the modules needed and so on, when done do install the module to check the broken requests, thus do implement a simple restrictive CSP header in the httpd.conf file, then uses the website, the module record the broken requests and output the formatted rules to be added to the CSP header, with a few cycles of this routine should be able to figure out the "perfect CSP rule" for this specific TB installation.... Btw, I also found this post on prestashop forum where people do talk of this problem, seems that is a complex thing due to lots of inline stuff from within PS and from outside PS, I guess that for TB is the same. https://www.prestashop.com/forums/topic/614928-prestashop-is-not-compatible-with-content-security-policy-csp/ I tried to implement a very very permissive CSP policy to start with, everything seems work fine so far: Header always set Content-Security-Policy "default-src 'self'; font-src *; frame-src *; img-src * data:; media-src * data:; object-src *; script-src * 'unsafe-inline' 'unsafe-eval'; style-src * 'unsafe-inline';" However, with this rules the CSP header is there just for formal reasons, that according to the principle expressed by some allegedly security experts that having a very permissive CSP header is anyway better than having none. In conclusion according to me would be nice to have a decent CSP header to rely on for TB. So I launched a "quest"in another thread, whoever is interested in creating the "perfect CSP rule" for TB please read it: Thank you Best regards R.

Hello I am working on my server to get a high rate for what is concerning SSL and Headers, so far I managed to get TLS v1.2 and 1.3, disabled v1 and v1.1, added an amount of headers to avoid low security grade, so I did implement the following headers: X-Frame-Options, X-Content-Type-Options, Content-Security-Policy, Referrer-Policy, Permissions-Policy, Strict-Transport-Security For this header Content-Security-Policy aka CSP I did set a very permissive rules set, which allows practically almost everything, so it is not really effective, however having it is anyway better than not having it at all: Header always set Content-Security-Policy "default-src 'self'; font-src *; frame-src *; img-src * data:; media-src * data:; object-src *; script-src * 'unsafe-inline' 'unsafe-eval'; style-src * 'unsafe-inline';" Now using this CSP rule almost everything works fine, but I would like to begin to build a proper rule set to be used with Thirty Bees so to be able not only to score a higher mark for security policies from crawlers and engines but also effectively harden the security of the shop. For what is concerning TB itself, which would be the minimum rules set to be used to not have troubles? E.g. in a TB 1.2 installation I am testing on using the rules set posted above if I try to use the core updater there is a problem: ================== Version to compare to: request failed, see JavaScript console The dropdown menu does not work, so it is not possible to choose a version, in the Java console I read this: Content Security Policy: a resource on https://api.thirtybees.com/coreupdater/master.php was blocked by the configuration of the page (“default-src”). jquery-1.11.0.min.js:4:25949 Request to https://api.thirtybees.com/coreupdater/master.php failed with status 'rejected'. controller.js:102:15 ================== So even using such a very liberal rule set some functionalities are broken, of course for emergency cases it is always possible to remove this CSP string from httpd.conf, restart the Apache service, do the update, put back the string in httpd.conf, restart Apache and is done, but how much better would be to know which is the magic string that do allow TB to work fine and at the same time have an extra protection layer on the website? I thought that is a common interest for every merchant/developer to define a CSP for TB core and native modules at least, I am not expert and fond enough to do it all by myself, but I am pretty confident that can be done together here in the forum. My idea is to remove the unsafe rules one at a time, check what happens in the debug console and add the appropriate rules to have it working right. E.g. the request rejected above does not fall into any of the rules, so fall back to default-src 'self'; I imagine that adding the domain api.thirtybees.com will solve the problem, but with which correct syntax should be added? Should be added to the default-src rule? Or it is better to add another specific rule for this kind of requests? Anyone who is interested in creating "the perfect CSP" string for TB please do participate to this "quest". The main gola is to have a CSP string that allow TB core and native modules to work without problems and that do prevent other operations, so to harden the shop installation, if then people want to add more rules to have third parties modules and other stuff working that can listed as extra. By the way, searching how to solve this task I stumbled upon a Wordpress module that automatically report the blocked requests after introducing a basic restrictive CSP header in the server, then automatically output the formatted CSP string to have everything working right, I think that it is interesting for TB a native module of this kind, I add this proposal also in the "feature request time" topic. P.S.: the website I used to check the headers is this one https://securityheaders.com I tried to check what the biggies do and surprisingly not many do implement all the suggested headers and also some do not implement the CSP header. I do not really know how much this is going to affect a website for non security related matters, e.g. ranking, obviously biggies are a case a apart and are favoured not matter what, however, I thought that in general having these headers set up is maybe better than not have it. I used this website to check SSL: https://www.ssllabs.com/ssltest/analyze.html While on a website one can get even a A or A+ mark for what is concerning SSL if no proper headers are adopted too there are still many ways to perform exploits on the website, I read some comments telling that are important and that the SSL test alone is incomplete, giving a false reassurance of not carried out together with a headers test. I would like to know more about, what is your opinion in this respect? Thank you Best regards R.

Hello I installed this module GDPR PRO now version v2.1.15 with TB1.2 + Panda theme v 1.5.5, presented same errors as described above, solved the issue in the same manner, the complete list of substitutions to be done is here below: createDatabaseCustom instead of createDatabase dropDatabaseCustom instead of dropDatabase createMissingColumnsCustom instead of createMissingColumns createColumnCustom instead of createColumn getDatabaseColumnsCustom instead of getDatabaseColumns After substituting all these words will be available for installation After installation as ALM wrote above in fact seems that the acceptation of the policy is not saved, each time the visitor refresh the page or visit any other page the popup appears back. This however is not a bug, after installation it is necessary to configure the module, in the configuration panel on the right top corner click on the "GDPR enabled modules" button, there set up at least one module to be shown to the client in the warning popup in the front office, save and go to the front office to check, the popup will appear, click on "more info" button, see how now the module you did setup is shown, then click accept, try to refresh the page or navigate in other pages, the popup should not appear any more. Thank you

Hi Slick Yes, it is where I looked, found no errors logged concerning the issue I got. So I got no info about. Ok, now I do concentrate to conclude more important tasks, will get back on this afterwards. Thank you so far

Hi Datakick Thank you I found a log folder in the root, the latest error reported is not about the issue I got, I did search in the folders and found only few log folders/files and none is related to this issue Where do I find the error log?

Hi I am sorry, as you asked where it comes from I recalled that is not a built in feature, you are right, these two modules custom tabs and related products do come from sunnytoo transformer and panda themes... Thank you for the answer, helped me making up my mind about, I was thinking that were a couple of built in features... ^^ (being a merchant and having to deal also with all this techy stuff can be very distressing, sorry..) This TB1.1 installation is transplanted from another server, so when I transferred the installation I expected some problems with the PHP version if not using the same one, and in fact it did not work on latest PHP 7.4. However switching it downwards from version to version i noticed that with 7.1 begun to work and I left it there as seemed fine, so at the moment this vhost is setup to work as follow: Distro Name: CentOS Linux release 7.9.2009 (Core) PHP: php-fpm Php Version: 7.1 Apache: Yes Apache Version: 2.4 Nginx: Yes Nginx Version: 1.6 Now that I understood my mistakes and confusion I tried to reset the module custom extra tab, apart the fact I lost some data which I need to retrieve, I noticed that anyway does not work as expected, in fact form within the product edit page does not work the same way, meanwhile the tabs created within the module do work, same faulty behaviour. On the other server worked fine, in this new one not. Can maybe depend on the php version used or some missing php module/extension? I know that his is not an issue of TB itself only at this point, however if anyone knows about such a problem any tip is welcome. Does anyone know which is the higher PHP version in which the transformer theme modded by the sunnytoo guys do work well with tb1.1? Thank you.

Hello On a TB 1.1 installation I have created a time ago the extra tab in a product, and all worked pretty fine. I cloned that same product and noticed that the extra tab was not created. So I begun to try to create same tab in in those cloned products and I noticed that when I click save it does not work, the message "saved" does not appear, when I get back in the panel to check I see that nothing was saved in fact. i tried to modify the content of the tab in the same product from which I cloned those new ones, the same happens, there is no way to save anything. Then I tried to create a new product and create the extra tab in it, same results, does not save anything. The debug mode is active, but I see no error message. What should I check to discover what is causing this? Update, trying to add related products I got the same error, does not save, no error messages, nor the message saved appears, getting back to the tab to settle it nothing of what I selected appears...

Hi This is my opinion, it is not about keeping on the 1.6 version, but about getting rid f the amazing amount of troubles and lacks in prestashop + getting rid of a company that did a good job creating/developing prestashop but also kept in it a lot of nonsense and caused many troubles in the time. One of the things they did that the more kept punching in the eyes is how version after version same bugs and inconsistencies where left there and how bad was their update system. Personally I always had a double feeling about prestashop, good on a side and a nightmare on the other. When then they did 1.7 and tried it I deemed it terribly bad and soon understood that could not become any better for me in the time, that because the languages translation system, which just horrible, rigid, lengthy, slow, absurd I would say. In PS 1.7 I saw no special improvements, on the contrary I saw a regression to worst standards, I just could not understand the choice to cripple the translation system in such a bad way. I do not know about the other users' experience in this respect, but for myself I learnt to not trust at all the prestashop company and their marketplace, I had many frustrating experiences, became allergic to them. That's my 5 cents about. Happy that TB was done and that is kept alive.

Hi Lesley I understand, and yes, much care about how to create and manage the catalogue and all the rules would be needed if those features are used. Sure is that if a seller do not pay enough attention and do not keep up a rigorous logic would end up with some messy situations or worst even quite a mess. However, that would be up to the seller, if does setup a logical clear scheme would take the advantages, if begin to mess up the catalogue would surely end up with many products that cannot be bought. That said, I still think that would be good to have the opportunity to use these features, not all e-commerce shops do sell "simple" products in which it is sufficient to have same carriers and same payment methods for all products. Personally as a seller I would be more than happy to have the features I mentioned, I know that some extra care should be taken, but this is part of our job as sellers. As an example, in some shops a few core products do the big part of sales, for the seller is much more important to have those specific groups of products fixed in a very precise and proper way according to the case, if a client want to buy also other side products which cannot fit in the same cart due to restrictions it is not a great problem, the important thing is that they can proceed with the core product, the problem of the side products can be very easily solved explaining to the client that must do another separate order with all the side products, that can be included in the core product info as an example, or communicated at the sign up time e.g. " welcome Mr X, thank you ....etc..., If you want to buy other products other than CORE PRODUCT; please do a separate order, or just contact us and we will help you ...." With that I just want to underline the fact that clients can be very happy to deal with unusual shops as long as they can concentrate on the core interests that they have, in a way it can even be positive to stimulate a direct contact or in general to keep the attention focused on the core reason for which the client landed on the shop. According to me there is no strict need to keep the e-commerce platform "dummy proof", the special features can be there, who do not need it do not use it, who do play with it and fail can reset and try again in better ways, who need it and know what is doing can take advantage of it, on the contrary no special features=less chances, it is that simple IMHO. Thank you for the information given so far, was pretty useful, I already fixed a few things. Thank you Best regards

Hi Lesley If the seller do create a payment method and assign it to a special carrier, and assigns certain products to be shipped with that carrier do not enable clients to use other payment methods for those specific products, that, although a sort of reverse logic is used, do work and and solve the problem, this kind of compromise solution is fine enough even though according to me would be much more logically linear the possibility to assign a payment method directly to products, however, it is a workaround and there is nothing wrong in using it. Now let's say that the seller for all other products decide that clients can chose which payment method they prefer, and can also chose which carrier they prefer, for all these other products how can the seller let the client have a discount only if decide to pay with bankwire transfer and not let the client have the discount if decide to pay with credit card, but, at the same time let the client chose one of the several carriers available? The only idea that comes to my mind is to create a double for each carrier, one telling to the client e.g. "Pay with bank wire and ship with DHL, you get a discount X%" and the other one "ship with DHL", this would work, but is not an easy going workaround and does not look good in several respects. To look good he client should be just prompted to chose a carrier and chose a payment method, if do chose a payment method that impose a surcharge or allow a discount should be settled within the payment configuration itself, that is what I think every client expects to see, easy, clear, two clicks and done. In my opinion forcing the clients to read a lot of extra not needed options and the seller e.g. to deal with a double amount of carriers' configurations, e.g. update the shipping fares in more carriers and so on.... is not a good thing, nor very attractive for those who do not know yet thirty bees and are evaluating which software to adopt for own shop or a client shop. Even though in fact somehow is possible to solve these issues with workarounds I still insist that would be a very nice thing to have it settled in a more straight and simple way, so ability to assign a payment method directly to products and in the customized payment module add the possibility to directly add a discount or a surcharge (eg. for COD payment) without the need to create a cart rule. In my opinion that would be greatly appreciated. Thank you Best regards

Hi Haylau thank you, will check it out next month