datakick

I have tried on my local installation running 1.1.0 to create many features: 356 features 201332 default feature values 604002 feature value lang This is much more features than you have (according your first post). The product page is indeed sluggish -- the readystatechange event handler run for 3 seconds, and the page is non-responsive until this finishes. Moreover, switching to Features tab takes 4 seconds, even after the page loads. This was on chrome. When I tested on Firefox, I got worse measurements - it took 8 seconds to open features tab. The same results are in 1.0.8. So (unfortunately), this is nothing new. It's indeed inherited limits of thirtybees platform. When I tried with the less features (180 features, 4800 default feature values) it worked quite fast, thought. There was some performance degradation, but it wasn't really noticeable. My initial investigation shows that the problem is in huge amount of DOM nodes. Basically, for every feature and every feature value, DOM nodes are created and inserted into the page. Browser can't handle so many of them on one page. There is no quick fix -- the product page needs to be reworked to use some data lazy-loading (Instead of displaying 200k DOM nodes upfront, we would only display 356 features and load feature value only when necessary via ajax). But, unfortunately, this is a big change. It's not realistic to expect it anytime soon. Sorry for the bad news

Which one?

If you are on a test/dev account, use core updater to downgrade back to 1.0.8. Then test if the product page works ok, or not. This will tell if your problems are related to 1.1.0 version, or if you've hit limits of thirtybees platform.

The issue is very well understood, and it was explained few times already. The problem is that the ps16 default theme (and most of the themes that derives from it, including Transformer, Panda, Community Theme, and Niara) contains a bug. This bug seems to be present in the code from the very beginning, and it looks something like this (pseudocode) {foreach $list as $item} ... // work with $item variable inside the loop is ok, as we are in the scope ... {/foreach} .... // access $item variable should not work, because we are outside the loop scope $item->doSomething(); Basically, original theme developer accessed variable after the loop ended, even though this variable *should't* exists anymore. It was declared in foreach loop, and the loop should be its scope. Unfortunately, older version of smarty allowed this operation -- the variable pointed to the last item in the $list. I believe that this should be considered bug in smarty engine (and that's probably why they fixed it). Because of this, the theme somewhat worked, even though it didn't displayed data correctly (in our case it displayed delivery time for the last carrier only, other carriers were displayed without delivery delay information) Thirtybees 1.1.0 upgraded smarty from version 3.1.19 to 3.1.31. This move was really necessary. The 3.1.19 version was already 5 years old, and it was reporting deprecation warnings on php 7.1/7.2. It would stopped working on future php versions. The upgrade was long due, and should have been made much sooner. The side effect of this upgrade is that this bug that our themes depends on is has been fixed. Now, it's hard to fix this issue from the core, mainly because there is nothing wrong in the core itself. The problem is, and always was, in the themes. Thirtybees team localized, and fixed this problem in the themes they own (niara and community-default). But it's not possible (well, it's possible, but very hard) to fix it in the third party code. This is the first *big* compatibility issue I've seen in this project. These are bound to happen sometimes, and it hurts. But rest assured that thirtybees team is trying hard to prevent this, unless absolutely necessary.

It is possible there was a bug in previous versions of tb regarding this 'Never recompile template files' option. If it's true, it only emphasise the uselessness of this option. While it can save few nanoseconds on every request, it can cause plenty of headaches

That's what CSS is for. My module comes with default light theme. But you can, of course, change it to match your requirements.

New version 0.5.0 released: FEATURES: New trigger: After conseqs rule - executed immediately after another rule. This allows you to chain your rules and create more sophisticated flows New trigger: Product purchased - this trigger is executed when your customer purchase specific product Recognise id_cart_rule columns as CartRule objects Added baseDir to context variables BUGFIXES: fixed annoying bug with saving 0 value inside number parameter fixed problems with loading / displaying rules with invalid settings

New version 0.3.1 released. This version fixes a bug that prevented selection of those payment options whose action url changed over time (for example because it contained timestamp or random number) This should resolve problems with mollie module

Here's the fixed template file: supercheckout.tpl -- but it might be for different version of supercheckout module. @AndyC promised he will talk to supercheckout module developer and pass the modification to them. So hopefully they will integrate it and release a new version. Note that this is actually the bug in the module. Its just the older version of smarty library from previous versions of thirtybees didn't throw the error here. But the bug was there

How does PayPay virtual terminal works together with 3D secure cards? Or with upcoming SCA?

I've just released new version that allows editing CMS pages as well

I'm curious, when you create order from back office, how do you handle payments?

It really depends on on the use case. If @Mark wants to implement multi-seller marketplace, then there are definitely modules for that. But if he wants to manage his employees access in back office (employee 'A' can view and edit all products, employee B can edit products in category Cars only,...) then it's totally different problem. And this one's very hard to implement.

Yeah, that should be possible

Every page takes many seconds to load, regardless if I enter it into address bar directly, or if I click on it

There is no record ownership in thirtybees, so it's not possible to implement record-level restrictions. Everything would have to be custom. Now, what records would you need to manage? Is it only products, or do you need this ownership on other records as well?

Hi guys, one community member suggested interesting idea for a module to edit products or categories directly on front office. This way, you can do quick adjustment when you are browsing your site, without the need to constantly switch between back and front office. I have implemented first version of this module with basic functionality only. You can test it on my demo server -- click on the Enable content editor button on homepage. I would like to ask you about your opinions about the module, or the idea itself. Is this module interesting enough for you to consider purchase? What other functionality should be implemented? Would you need editing support for other entities, like manufacturers, suppliers, or blog articles? I'd love to hear your thoughts

@smarterweb, I've just tested the functionality (Preferences > Custom Code > Add CSS) on 1.1.0 and it works correctly even for your code snippet. This is either problem in your Theme Editor module, or in some override in your system.

Good idea, that would nicely allow rules chaining. Thanks for the suggestions

Right, this would work as long as there are data in the table. Unfortunately mysql won't return column information for empty datasets

Yes, we need to look at database structure. SHOW COLUMNS would work, but I guess it would be easier to query INFORMATION_SCHEMA.COLUMNS view directly. It's probably not worth the effort to fix this, though -- this code will be removed completely once the schema comparison functionality is merged into core updater.

Core Updater allows to easily switch between two versions of thirty bees. But at the moment it handles code only -- php and javascript files gets updated. The problem is with database changes. If the new code depends on some new database column or database table, it doesn't help. These new database objects are not automatically created. Historically, this kind of problem was solved by migration scripts. Every release come up with some sql file that was executed during update. This sql script contained DDL statements to alter database schema. This approach has many drawbacks, the most important are these two: these scripts aren't usually idempotent - which means you can't run them multiple times to achieve the same result. The second execution often ends up with error (because the database object was already created) there is no reverse operation - you can only upgrade, but there's no way to do downgrade. The only way to revert changes was to create whole database backup These issues are the reason why thirty bees developers decided to drop this approach and come up with new one. The proposed way to handle database migration is based on different principle. Php code will contain metadata that describes complete database structure it requires. When you upgrade (or downgrade) your thirty bees to different version, these metadata will change together with code. And core updater will use them to find all differences to your current database structure and fix them. So, for example, if you want new database column, you will just need to add new item into php file. No muss no fuss. Unfortunately, this mechanism is not released yet (but it's implemented and under testing, so you'll see it soon). Now, back to the issue at hand. There are two database structure changes between 1.0.8 and 1.1.0 - tables tb_order_state and tb_order_return_state received new column named active. Because the metadata-based comparison is not released yet, and because there is no support for legacy sql migration script, there had to be implemented nasty workaround to create these new columns. Basically, whenever the OrderState object is created, thirty bees checks that the active column exists. And if not, it creates it. This adds some performance drag. And, unfortunately, it also contains a bug. The check uses following sql query: SELECT `active` FROM `tb_order_state` LIMIT 1 But, obviously, this sql query fails terribly when active column haven't been created yet. In normal mode, thirtybees swallows database errors, so this check somewhat *works*. But if you have debug mode enabled, this invalid sql query is converted into php exception like the one @musicmaster reported. The workaround around this issue is simple: go to Advanced Parameters > Performance disable Debug mode go to Orders > Statuses And that's all. Both columns should be created now, and you can re-enable debug mode

To be honest I couldn't find it either. I had to look into the code 🙂

Theme Configurator module

cronjobs module offers api to integrate with other modules -- third party modules (like revws) can request periodic cron action. Cronjobs module will then create cronjobs entries for all these requests, and trigger third party modules hook periodically. The question is, why do you need it to be disabled? If you don't want the emails to be sent, then simply disable the sending email functionality in revws settings. In that case, cron event will be a no-op.