datakick

what do you mean by disconnect and reconnect to the frontoffice ?

@30knees this issue was already fixed in 1.0.21 / 2.0.3 release, please install latest version and test again

Main page is generated by index controller, so just enable left column for it:

FPC does not really work. I suggest you to disable it completely for the time being.

I've tested it and it works on my 1.0.7 as expected. Verify that you have themeconfigurator module enabled. You can also check that this module is in list of hooks called for left/right columns:

@daokakao said in [Free Module]Revws - Product Reviews: I meant the [6]...[6] tag - both parts are opening, no closing tag Ohh, that's indeed a small bug. I'll fix it, thanks for reporting it

@daokakao said in [Free Module]Revws - Product Reviews: Is this part correct: [5][/5]You can read our [6]privacy policy[6] here ? yes, it is correct. It's a placeholder for inserting a line-break. Also i wrote earlier that not all string resources could be translated because are palced in the .js file. So the question is - do you plan to sort out this? sure, but it's really not a pressing matter. I didn't translate these strings originally because I didn't have mechanism to inject html element into translated string. I do now, so there's no reason not to do it (other than that it's extremely boring task)

Ensure that the customer is 1. not deleted 2. is not guest account

@30knees said in [Free Module]Revws - Product Reviews: I changed the status settings, but the old orders on the status don’t update to reflect this. Is there a way to update them? You can - edit all those orders manually and re-set the status - mass update all those orders using datakick module, and set deliveryDate to some proper value (for example to order's last modified date) - or simply set Delivery delay in revws module to 0, and wait until all review request for those old orders are sent. Then set Delivery delay back to your desired value

@lesley said in Back to PrestaShop or stay with Thirty Bees ?: We do not want to track as much as other platforms I really think you should, though. Of course, make it optional, like 'Allow sending anonymous statistics'. I'm pretty sure many people would allow this, especially when you are frank about what type of data is collected. As an example of what could be tracked is installed overrides. Thirtybees developers would actually know what classes/methods are overridden, and there could be automated test that would prevent breaking changes to be released (or at least notify developer that this change will break something somewhere). There are many other things that could be collected. Of course, it would need to be implemented carefully, so the performance of the store is not affected. But that's totally doable.

re #1) missing 'Theme configurator' button -- this button is available only for theme with name 'community-theme-default'. It does make sense to display this button for themes that are derived from this theme, though. If you want to show this button for all themes, you can edit file classes/Theme.php and change lines if ($themeArr['theme_name'] == 'community-theme-default') { $themeArr['tc'] = Module::isEnabled('themeconfigurator'); } to simple $themeArr['tc'] = Module::isEnabled('themeconfigurator'); Thirtybees should however come up with some better way to associate themes with their respective configuration module(s). re #2) turn on your left/right column on individual pages as well, then your content should display on those pages

@cdwebman was really migrationpro module disabled when this error occurred? I can't find the code that would actually load-in the classes of disabled modules....

Are you using smtp or php mail?

@cdwebman one of your modules declares class with name Logger. This causes collision with built-in PrestaShopLogger. Even if you disable the module, this class gets loaded to to classpath, and causes the issue. Basically there are two things wrong in tb core: 1) including files from disabled modules 2) core using Logger alias instead of PrestaShopLogger class

You should definitely delete all overrides from modules that you no longer use. I recommend you backup /override directory first, just in case something goes wrong.

This is very strange. There's absolutely no reason why AdminInformationController should take so much time to load, as there's no business logic inside initContent method at all. Missing files list is generated after the page is loaded using ajax call. @cprats - is it possible that you have override installed for this controller? If you have migrated from ps16, it's possible. To check, you can install thirtybees Override check module to see what overrides are installed on your server.

The override system in thirtybees / prestashop would really need some attention. It's very brittle, yet there are many things that can be done to mitigate these kind of errors and warnings

Php is just complaining that overloading function does not have same signature as overloaded function in parent class. To fix this, simply edit file modules/auctions/classes/model/object_model/productauctionobjectmodel.php, and on line 156 change signature of function __get from something like this public function __get($key) to public function &__get($key) Note the extra &

@cdwebman Here's my thoughts about your original question. First, let me say that I too think ps17 platform is getting better and better. As a developer, I really like what they are doing there, the system architecture is shaping nicely. It's becoming easier to develop modules and themes for that platform. Some things that are really hard or impossible to do in ps16/tb can be done quite easily there. But the only reason why this is happening is thanks to Prestashop's decision to break compatibility. And this is the biggest issue I have with them. They screwed hundreds of thousands of their own customers running on ps16 - most modules merchants already bought for ps16 will not work on ps17, so they will need to purchase a new ones. There is also no automated upgrade system from ps16 to ps17, so it requires paid service to even stay updated. They also screwed module and theme developers -- sales of ps16 modules dropped significantly as merchants don't wants to invest into dying platform. Developers are forced to re-implement their modules for ps17 platform, which can take huge amount of resources. Note that it may take years for module to break even, or become profitable. That's one of the reasons why so many third party developers are jumping ships lately. The only one who benefits from this decision is Prestashop itself -- they will have better platform, and influx of sales from ps17 modules. They don't care that everyone else got hurt. I believe everyone needs some stability, both merchants and developers. And I don't trust ps17 platform on this point. Thirtybees, on the other hand, has backwards compatibility as one of their core pillars. And I hope it will remain the same, even with thirtybees 2.0

@piet thanks for confirmation, I'll include this change to the 1.0.8. So don't worry, you will be able to upgrade without any fears you will loose this change

That's awesome @Jonny. Can I ask what needed to be done to make your theme compatible with tb 1.0.7? I'm interested because there shouldn't be any changes necessary, in theory :) If there's some breaking change between tb1.0.3 and tb1.0.7 we'd love to know, so we could fix it

@piet could you please modify config/smarty.config.inc.php, and change function register inside SmartyLazyRegister class to this (including function signature!): ```php public function register($name, $type='function', $callable=null) { if (isnull($callable)) { if (isarray($name) && count($name) === 2) { $callable = $name; $name = $name[1]; } else { throw new PrestaShopException("Invalid usage of SmartyLazyRegister::register"); } } $this->registry[$name] = [ 'callable' => $callable, 'type' => $type ]; } ```

@piet, please show the code from /modules/prestapassionsmartcodes/prestapassionsmartcodes.php around line 258 (+/- 10 lines)

There is indeed very inefficient piece of code in classes/Product.php, function cleanPositions. When you remove product from a category, all products that are associated with that category and have higher position gets updated. In your case this leads to thousands of sql updates. They are very fast, but it adds up. That's also the reason why you experience this problem only with olded products -- they have lower positions inside categories. New products have higher position, so the total number of updates is much lower. I'll prepare a fix and push it to thirtybees 1.0.8. Meanwhile, this is what you can do to avoid this problem: edit file classes/Product.php, find function cleanPositions, and remove these lines.

@cprats we are getting closer. There are over 9000 sql queries -- that's way too many. Normally you shouldn't see more than 300. I bet there's some very inefficient loop that's executing some query over and over. Please look at the bottom part of the profile stats, and search for section with sql statements named Doubles. It looks something like this (the red number says how many time was this sql executed)