datakick

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.

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 🙂