datakick

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.

1.1.0 contains some fixes in this area. For example, this one might fix the problem for you. You can either apply this commit manually, or use core updater to upgrade to 1.1.0

I do have graphs in statistics. Best Vouchers shows list of best vouchers as well... What version of tb are you using? Maybe this is issue with your tb instance (override, modules that interfere,...).

Looks like these modules weren't uninstalled properly. They were probably just deleted from modules directory, so thirtybees still thinks it's installed. You can either delete them from tb_module table, or upload them to modules directory and perform regular uninstall. I guess core updater could be modified as well, it should check that the modules are installed and present

I guess the error message is not self-explanatory enough, and it can probably cause unnecessary alarm. It should include more information about what it means and why it is there. Especially if you have already set up your external cron service. In that case, it should tell you to remain calm and check back in a few hours -- it should be fixed by then Sorry for the trouble 🙂

I've filed enhancement request for this: https://github.com/thirtybees/thirtybees/issues/1002 Until this is implemented, I've at least changed version control parameter on these javascript assets from _PS_VERSION_ to _TB_VERSION_

I totally agree. There should be some generic assets version control in place. It should be based on either thirtybees version, or even better on git commit as you suggest (it could be any unique identifier associated with release. But git hash seems to be best option). That way, browser cache for all javascript (or css/font/...) assets would be invalidated when merchants upgrades or downgrades thirtybees core. Let's create an issue to track this enhancement

It means that the cron url was not triggered by external web service (in the last 24 hours). Once your cron service opens the url, this warning message will change to something like this:

@AndyC this looks like browser cache issue. Your browser uses cached version of /js/admin.js file that doesn't contain function displayPriceValue. I believe that your problem disappears if you clear your browser cache (or use different browser)

This is probably related to new version of smarty. Similar problem was in community theme / niara, and it was fixed by simply moving the block of code to the proper place. If you send me the module, I can fix it for you

Did you have latest version of core updater installed?

Core updater

Generally speaking, all templates that work on 1.6.1.23 should work on thirtybees. If you find any template that doesn't work correctly on thirtybees, it would be a great help if you could check whether they work on 1.6.1.23. If they don't work there either, it's definitely template problem, and only template author can fix that. But if the template works on ps16, but not on thirtybees, then there is some compatibility issue. And that needs to be addressed and fixed. So please report such problems here on forum, or on github.

There's a bug in captcha module that allows contact form submission when Login attempts settings is set to non-zero value. So this should be the first thing you should check.

I can't reproduce it. Does it happen on all orders, or just this particular one?

@yaniv14 was right, this bug was already fixed in January, but we forgot to release new version. I've just packed and release new version of this module

Yes, it is production ready. Of course, you should test all the flows yourself to be sure. Like with every other module 🙂

I've just released new version 0.3.0. This version adds some new functionality, but more importantly it fixes serious login-related bug introduced in 0.2.0. I strongly suggest you to update to this new version NEW FUNCTIONALITY Support for manual exemption in VAT module. Your customers can now click I qualify for VAT relief checkbox Added password reset functionality Added floating UI notification snackbar to inform user about various events (invalid password, wrong discount coupon code,...) BUGFIXES Fixed serious bug regarding login user Fixed bug with not showing all customers addresses

I can't believe I forgot to implement password recovery. I'll implement it right away and release new version soon I've added this to my backlog, but with low priority. I won't implement this anytime soon. But thanks for feature request I'm not sure this should be part of checkout module. This looks like an ideal job for tbhtmlblock module Yes, it should be. You might want to do some minor css tweaks to better integrate checkout page, but in general it should work out of the box This is not implemented. I've added this to my backlog and it will be added soon. But it will probably be hidden behind some settings option, because not everyone needs this You can test this module on my demo account

No, I haven't heard any such complaint. Also, I've just made a test checkout on my iPad without any problems or errors.

Regular expression is invalid, it should be enclosed in start/end delimiters, ie '/^*gold|gold|GOLD.*/' where / is a delimiter. Also, drop the escape:'html':'UTF-8' part. It should look like this: {if (preg_match('/^.*gold|gold|GOLD.*/', $product->name))} ... {/if}