datakick

migration module does not replace any module, unless it's one of the few known incompatible. It's up to merchant to decide if he wants to upgrade to Thirtybees native module, or keep prestashop version

@Séane it's possible to override module's primary file, so you are in luck. Just create file overrides/modules/blocktopmenu/blocktopmenu.php with content like this: class BlocktopmenuOverride extends Blocktopmenu { protected function generateCategoriesMenu($categories, $isChildren = 0) { // your custom implementation } }

Yes, this is already in 1.0.8. Please keep the issue opened, as traumflug wants to use it to track the original performance problem

I'm just wondering what this has to do with gdpr module...? Anyway, the code is pretty much ok. I would drop $this->need_instance = 1; because it's tells thirtybees to instantiate this module every time it renders Modules page in back office, which can slow it down a bit. But other than that, there's nothing wrong with it. And if you have your skroutz javascript on your order confirmation page, then the module must be installed properly.

The easiest way is to edit Module.php file, and just before the line where it failed add this code: die((new ReflectionClass('Validate'))->getFileName()); Then refresh your front page. Instead of your beautiful thirtybees shop you will see file path to the Validate class. Don't forget to remove this line after 🙂

Also, you can use Override Check module to quickly find all orphaned overrides. This module is available to install in your backoffice

Looks like it is indeed obsolete, and you should be able to remove it. These overrides remnants are, unfortunately, common problem with module upgrades. Another question is why is there an override for sendChangedNotification method. This method only triggers actionOrderEdited hook. By overriding this method this hook is not executed, which might cause problems with other modules integration.

https://github.com/thirtybees/thirtybees/commit/8e89acf9061e88bc106658891c8bd5abb83eeb9c

There's a bug in 1.0.8 regarding saving Conifguration, that's probably it. Since you are using gitupdater, you can try to forward your shop to bleeding edge. It's fixed there

I've tested mollie's ps module version 3.3.5. Klarna payment method in test mode seems to be working correctly for me. Question is, if the webhook is triggered in production mode at all. Those of you who are having issues with Klarna -- please go to Mollie module, and set LogLevel to Everything. With this option enabled, there should eventually appear some Mollie entry in your Advanced Parameters > Logs Can somebody confirm such entry recently?

I believe you can expect next version very soon. Maybe even in two weeks time. And after the new @Traumflug's core updater is released, you will be able to deploy latest changes almost immediately

This is definitely a good idea. The implementation is tricky, though. The best way would be to have dedicated task queue running in separate process. But that would require your own server, and it would not be trivial to configure. Alternative is cron-based task queue. There are always some problems with crons, timeouts, etc. But it's definitely a good thing to think about. Especially if we combine this with task scheduler to run maintenance tasks

As others said -- full page cache has few problems in 1.0.8. These are fixed in upcoming version. But back to your question - when you enable debug mode in FPC, then there will be special http header in response with information if cache was hit or missed. That's all it does.

Since you have upgraded from 1.0.3, you need to delete old stats modules, as described here: Go to your modules directory and DELETE all of your stats module except statsdata and statsmodule. Also delete the modules graphnvd3, gridhtml, pagesnotfound, and sekeywords.

I'd be happy to help. I just need someone to explain how can I reproduce the problem on test environment. Or, alternatively, give me access to ftp/back office

It seems to me that the main culprit is the stmegamenu module. Try to disable it and try again. Also, enable smarty cache (that might help with stmegamenu module as well, because it's result will be cached. The menu will have to regenerate only every once in a while)

turn on debug mode and profiling. You will see timings info on the bottom of the page. If you are unsure how to interpret the results, paste it here

Error reporting, as originally implemented in php language, is one of the worst design they could choose. It worked somewhat at the time they invented it, but 20 years later it just doesn't fit well into modern stack. When this error_reporting *feature* is turned on, then any error or warning will be printed into the standard output -- into the currently rendering document. Why is this bad? It breaks the document. Note that php can generate different types of responses, and this feature can break all of them html output -- error message text, which can include html special characters like </>, will be part of the response. Depending on the place in the code where the error happened, the error message can be at the very beginning of the response (before the <html> tag), anywhere inside it, or after. If it's before, then the response is not valid html page, and browsers react accordingly. If it's inside the page, than it still can break the layout, resulting in javascript not working correctly,... Also, we can never be sure that we actually see the error message on the page. It is very common that the error message is hidden somewhere (inside display:none divs, in overflow areas, etc...) json -- many ajax requests expects json response. When there is error message mixed into the response, then the javascript will not be able to parse the response, which breaks the basic interaction functionality. css - if php generates css, than any error message inside it will break design images - yes, php can mix these error messages into binary streams These problems makes debug mode very hard to work with. Because responses generated in debug mode are different than the response generated in production mode. That's just stupid. The new thirtybeees error reporting feature suppress error outputting, but collects the message anyway. When the page is rendered, then these errors are (in debug mode), emitted as javascript objects into the page, and displayed into javascript console. So you don't need to download error log each time you make a change, you can simply open javascript console in your browser. Also, there will be modules (I personally work on one) that will display these collected errors in more user friendly way -- for example in some debug bar. Note that this feature has nothing to do with php72 compatibility, or with smarty. It's a generic problem that was part of the prestashop/thirtybees from the beginning. Thirtybees core is fully compatible with php7.2, but it is NOT compatible with php7.3 and higher. When we run thirtybees on php72 in debug mode, then deprecation warnings are displayed. These warnings are harmless, they just inform developers that something will have to be changed in the future. And we know about it, there are definitely plans to make thirtybees fully php7.3 compatible. But because of the error_reporting described above, these warnings breaks about everything in your store. With the error reporting redesign, your store will work as expected, even in debug mode on php72. While php73 compatibility is definitely a high priority task, it's not the most pressing at the moment. There's no need to rush into any decisions regarding smarty. Current version of smarty, as the rest of thirtybees, is fully php72 compatible. Any decision needs to be carefully evaluated, because y'all will have to live with that.

Unfortunately there is no technical solution for this. Thirtybees just can't force any third party to support it. It's also not possible to build some sort of facade on top of the tb codebase in order to make ps17 modules work with it. I understand your fears, I really do. After all, it's your livelihood we are talking about. You need to decide what platform is best for you and your business, now and in the future. Let me just remind you that going with prestashop is risky as well. What will happen when they start working on ps18, dropping the compatibility once again? Maybe your theme will stop working, modules you bought will be useless, all the customization work lost. All because prestashop company doesn't care about compatibility, stability, or merchants themselves. You will be left high and dry. Trust me, they did this many times already, and they will do it again. Thirtybees, on the other hand, was based on a pledge of stability and compatibility. But of course, because the user base is much smaller, third parties don't have such incentive to support it. But I believe there is still great amount of ps16 merchants that appreciate the stability this platform offers and will migrate here. And with our user base increasing, there's a hope third parties will be more inclined to support it. Especially since they already have ps16 modules they invested great effort into. And thirtybees is a way for them to continue monetizing them. Now, it's up to you to decide what way is better for you.

It's sad that Mollie does not support thirtybees natively. But I'm also pretty sure they do not intentionally block thirtybees. In fact, there is nothing in the api request that would provide information about used platform. Mollie is an api-based solution, and anybody can integrate with them. It doesn't matter if it's open-source, or custom made proprietary solution. They don't really care. This whole flame is based on a fact that some part of the official mollie module does not work on thirtybees. This can, of course, happen. You all know that there are some modules that need some modification, attention, and love. I guess the problem here is in webhook implementation. It either fails with some 500 error page, or maybe short-circuit the processing due to some condition. Because webhooks are triggered by Mollie automated service, nobody notices these errors. We observe them only indirectly by the fact that the order status does not change automatically. But that does not mean that Mollie is blocking thirtybees, now does it? Let's calm down and work together to troubleshoot this problem.

Have you cleared caches? (server, browser, cloudflare,...)? It's a change in js file and it can be cached anywhere... But it's definitely there

Sorry, that is not a best solution. It is just a cover-up of a bigger problem: there is something in your system that is trying to set Blowfish object inside your Cookie. There used to be a _cipherTool property inside Cookie class. This protected property used to hold cookie encryptor instance. I bet you have some Cookie override that tries to set this (now not existing) property, which in turn causes the fatal error. You can try this: revert your fix edit class Cookie.php at the very beginning, add this line: protected $_cipherTool; That should fix your problem. Anyway, this is a core compatibility issue, and it should be handled in the core.

this is error messages encrypted using your server's private key. So only you can decrypt this message. Go to Advanced Parameters > Logs, you will find decryption tool there.

Unfortunately it wasn't fixed properly. Although beesblog implements hook GSitemapAppendUrls, it does not register it inside its install method. I'll fix this for the next version of this module. Meanwhile, if you are in hurry, you can edit beesblog.php file, find method getContent, and add this line inside it: $this->registerHook('GSitemapAppendUrls'); Then save, and open beesblog configuration page. That will register the hook. Now you can delete the line again -- module has been successfully paired with sitemap

Oh, you are right. This commit is not in release 1.0.22. It will be in the next version. Sorry for the confusion. I have some work in progress, so I don't want to release it yet. But you can use this pre-release revision: revws-1_0_23-pre.zip