datakick

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.

Other solution is to edit email template and make it send static text only. As a confirmation that message was received.

Yep, this would work for simple urls without any parameters. For urls with parameters (https://www.domain.com/admin2389/index.php?controller=AdminDashboard&param1=something&param2=other&token=tokenvalue) you would have to include token into the url. Tokens are employee specific, so you would have to know upfront which employee will be opening this url.

You can disable sending emails globally in Advanced Parameters > Emails. Alternatively, you can install my Consequences module, and set up rule that would block sending specific email only

What kind of backup? Anyway, it would be quite hard to recover / merge with your current reviews. You would need to do some surgical sql queries

You have probably deleted review criterion that these old reviews used.

This problem is caused by new column active in table 'tb_category_shop'. This column exits in bleeding edge only, so if you are back on 1.3.0 all you need to do is drop it: ALTER TABLE tbp5_category_shop DROP active; But obviously, this module will no longer work on bleeding edge (or future versions of thirty bees). As @wakabayashi wrote, the module author did not specify from which table active column should come -- that's not really their fault, as at the time they wrote the module only one active column existed in context of this query. If you want to keep using this module, you will have to modify it, and fully specify table name / alias.

It's good only for you, as only you have the private key needed for decryption. You can decrypt the error message in your back office > Advanced Parameters > Logs. Or enable debug mode and you will see the error message directly

That's just it -- it matters. In 1.3.0, there is sql query, something like this: SELECT active FROM tb_category c LEFT JOIN tb_category_shop cs This query does not fully specify from which table return active column. Because in 1.3.0 this column exists in tb_category table only, it does not really matter. DB server will return the only column available. But, if you add column with the same name into table tb_category_shop (as bleeding edge did), this query stops working -- now there are two columns, and DB does not know which should be returned. Extra columns in core tables matter. It should be forbidden to modules to extend standard tables

I am using bleeding edge on my store, and I know about a lot of people that are using it as well. Works properly for all of us, as far as I know. Every store is unique, of course, considering how flexible the module/override system is. If @Mark has 500 error on bleeding edge, then it's most likely some customization issue. Of course, it can be bug in core, that manifests only in some specific use cases. However, without any error message from debug page or php server log file there is no way to tell what's wrong. Note that currently it's not possible to roll back from bleeding edge back to 1.3.0. The reason is that bleeding edge introduces new database column 'active' in 'tb_category_shop' table. This extra column produces 'ambiguous column' database error on 1.3.0. The fix is to drop this column from db table manually when downgrading from bleeding edge to 1.3.0. Core updater does not do this automatically. Actually, it can't do this, because a lot of third party modules extend core database tables with their own columns. If core updater dropped all of these columns on update... well you can imagine what would happen.

This is generic mechanism that is utilised across multiple areas. It can be used in back office forms, or even by some front office features (modules). Even in back office use, it's always good idea to be cautious. Shop owner could copy and paste some html code, a code that could contain javascript or css. This javascript would make it to shop front office, and that's quite severe security issue. Even if the js is not an attack, it can easily break your pages by throwing javascript errors, and thus preventing your own javascript code to work properly. Similarly, any css inline code can very easily make your pages unusable. While WYSIWYG editors are useful, the backend php should never trust the input. Sanitization of input can help you very much. If you need to enter special html markup into your 'texts', then it's a very good indication that you are doing something wrong. You should modify your theme templates instead, and keep your content clean - just text with some basic formatting options.