datakick

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)

My module sometimes calls ajaxCart.updateCart() method (if it exists). ajaxCart is an object created by BlockCart module, but its javascript code is quite often overwritten by themes. It is this module javascript that is responsible for retrieving current content of cart, and updating html in the page. There seems to be some bug in this code that (sometimes) creates duplicate entries. I don't consider this to be bug in the chex, as calling ajaxCart.updateCart() method multiple times should be perfectly fine and acceptable use case.

Try to update to bleeding edge, and try again. I believe this bug was fixed already

I hope you mean 40 euro per hour, because there's no way there could be a flat rate to 'fix theme'. Note that there is not much you can do in one hour. More often than not, it will just take an hour to set up working ftp/mysql/back office access, and to describe/explain your issues with the theme. Then there needs to be an investigation, developer have to figure out what is the source of the issue. It's quite likely it will not be a theme issue, but rather some module problem (a lot of modules come with templates that does not work with all themes). And then, the fix itself needs to be designed and developed. All this can take considerate amount of time. Depending on number of issues, it can vary from couple of hours to few days. And yes, merchants can contact and purchase this kind of support project from thirty bees directly. Or they can, of course, enlist any other freelancers. There are a lot of experienced prestashop developers that can tackle theme modification easily.

Yep, when you install this module, saving 'Debug mode' from AdminPerformance no longer works. That's because this module overrides the mechanism completely. Unfortunately, there is no simple way to do that in tb core, so I had to do that 'by force'

All ps16 themes should be compatible. I have seen thirty bees running on a lot of different themes (although usually those stores were migrated) Some features, like webp or lazy loading, will not be supported on these ps16 themes, of course. And there can be some problems caused by newer smarty library used by thirty bees -- for example issue "Cannot use object of type Carrier as array" -- but that's usually easily fixable.

Wouldn't it be better to have 'displayable' name for feature values instead of some prefix/suffix? So, the Feature name would be 'Awards', feature value name 'Oscar', feature value displayable name would be 'Oscar (1997)' ? The free-text is more free then suffix

yes

go for it, all enhancements are welcome

Thankfully, this being open source, you can easily edit htmlpurifier configuration and adjust it to your needs. See Tools::purifyHTML

You can use media server even without CCC enabled Anyway... I have seen couple of issues with CCC, but it always boiled down to incorrect source/asset files. Not really problem with CCC algorithm, although it could definitely be improved to prevent (or at least report) these issues For example, in css file the last rule might not be closed properly: .rule-1 { font-size: 10px; } .rule-2 { font-size: 20px; } .rule-3 { color: black; // note that this rule is missing ending parenthesis When this css file in used directly, browser will be lenient, and parse and use the first two rules, but ignore the third one. The page will be displayed somewhat properly (only one rule will not be applied, which might not be a big issue) However, the situation will be much worse when this css is combined with other. The missing } at the end of file will break all rules from all css files that might be appended after this invalid css file. The situation will be even worse for javascript files. In these cases, the input to CCC algorithm is invalid. Even if we used better / newer library, the result could not be valid -- no algorithm can 'fix' invalid inputs.