datakick

edit override file, and change signature of Cart::getDeliveryOptionList method from current public function getDeliveryOptionList() { $carriers = parent::getDeliveryOptionList(); to public function getDeliveryOptionList(Country $defaultCountry = null, $flush = false) { $carriers = parent::getDeliveryOptionList($defaultCountry, $flush); The signature (and parent::getDeliveryOptionList) must match the signature in CartCore class

It's not -- the format is hardcoded in smarty template. I managed to reproduce the display tax problem, and hopefully fixed it. Please download new version 0.6.1 and let me know if it works for you

I both agree and disagree 🙂 . I will probably add some settings for individual merchants to decide Thirtybees only have printable format, and that's not the same as entry form format. I don't think it's a good idea to have different form layouts for different countries. It would be very confusing. Moreover, there can be custom fields that needs to be displayed in entry form. My idea, and end goal, is entry form layout designer in the back office. This way, everyone can design the layout they want to use. No

Hi everyone, I just wanted to disclose that I'm in the process of creating a new theme for thirtybees. And I would like to hear what features would you like to see there. Note that it will be paid theme. At the moment I'm not focusing on design. This theme is based on niara/community theme, so it will have the same look and feel. What I'm focusing on is functionality. Here's a list of things that my theme/module will offer. I'm not sure how important these features are for you, so I'd like to hear your opinions Page content editor This is the core functionality - it's a drag and drop editor that you will be able to use to build your page templates. It will use basic blocks specific to each page, and you will be able to arrange them as you like. It will allow you to do things like this: (on product page) drag price block and move it just below product name add another column between product images and product basic info add new section with product video right below main product description create custom tab containing static html content reorder tabs add widget / specific module hook / anywhere you want. For example review list ...etc Of course, you can do all this even now. But you need to have knowledge how smarty, html, and css works Different page versions for different entities You will be able to use different page templates for different products, categories, etc. This is similar to native thirtybees Template Manager module, but for every record types there is. It will also be based on rules, so you will be able to say 'Every product which contains Gift in the title will be displayed using gift-product template' This will allow you to have different layouts for different types of products. Different / customizable layouts You will be able to design different layouts (2-columns, 3-columns, full-width, with menu, without menu,...) and use them with different pages/entities. For example, you you can use layout without top menu and with custom footer content on checkout page, so there are less distraction. ... So, my question is -- is this something you guys actually want and need?

I have just officially released new version 0.6.0: New functionality Added option to choose shipping address even from not selected country We can now create new address in different county / state than currently selected one New settings option to select product image type New Leave a message entry field in confirmation section allows your customers to leave a message associated with order New settings option to choose whether country selector should display all countries, or active only Entry fields now have html IDs so you can more easily target them in your CSS rules Bugfixes Fixed problem with displaying wrong total when cart rule with free shipping was applied

I would also love to see this. I was very surprised that I can't do that

@AndyC / @dynambee Here's a (pre-release) version that should somehow fix this address selection / creation issues. Could you please test and let me know if it works for you: chex-0_5_1.zip I must say I'm not 100% happy about the possibility to change delivery country/state in the address section(s). It can impact shipping cost, and even available payment options. And that can surprise customers -- they will need to go back to step 1 to ensure everything is still OK. It can disrupt the unidirectional flow I'm trying to achieve by this module. But, hopefully, not many customers will change country/state here

No difference, it's the same hook. hookDisplayHeader is an alias for hookHeader.

In smarty use $content_dir variable Regarding CMS pages, or links in RTE in general -- I'm afraid there's not any easy solution here. There are no dynamic placeholders you can use here that would be automatically replaced during runtime. You can enter only static urls. Most people do this by using relative links like /en/blog/100-my-blog-page.html -- but that doesn't really work if your local installation is in subfolder. Alternative is to use relative urls like ../../blog/100-my-blog-page.html - this would survive even in subfolder, but it's just plain ugly

This is quite complicated area. Basically, the ideal solution would be to request only those information that actually participate on shipping costs. In standard thirtybees, this is country+state. But some of my clients have custom modules that modifies this -- for example, one of them has different shipping rates per postcode. And as you noticed, you can configure your thirtybees as you wish - some merchants might have flat rate for the whole country, and some even offer flat rate worldwide. In these case we don't really need to ask for shipping country / state at all... My module can't decide this automatically. So, the ultimate solution will be to allow merchants decide which info are necessary to be entered upfront in order to calculate shipping. I have this in my backlog. But due to the complexity of this task don't expect it anytime soon Again, this is already in my backlog. It's not particularly hard to implement, I just need to figure out a proper way to do this. My initial plan for this module was to show the final price as soon as possible (in the first step of the checkout), and this price would not change in subsequent form filling. But this ability to enter country/state will change that. But it's probably not a big deal -- if the country/state will be prepopulated, most customers will not change it.

Another version of this module released for those that use multistore feature. You can now update values for all stores at once

You can use solution outlined in this stackoverflow answer To make it work in tb, edit file /js/admin/tinymce.inc.js and paste the code snippet into default_config:

Thanks. I assumed that new forum redirect original links to the new url schema. Obviously that's not the case... @lesley you might want to implement home .htaccess rule for this, as this means loss of existing links

You are correct, it's not the right solution. Ask your programmer to fix the database schema for the table, including auto-increment settings.

Then this issue was most likely introduced during SQL import - script probably dropped and recreated the table with incorrect columns. If there is no custom code (modules) that depends on these additional columns, I suggest your drop them from the table structure. Alternative, you can modify the OrderState.php file and change the order by statement, as @musicmaster suggested above. However, there is a strong possibility that there will be similar issues all over the codebase that would need to be fixed as well. Thirtybees simply does not expect these columns to exist, and that can cause many problems. For example, if these columns don't have default database value, it would not be possible to create new Order Statuses from the back office.

This is not governed by chex module. I can refer you to this article about mobile zoom Could you send me this module so I could investigate? module uses cart image type. This is quite standard, but maybe your theme doesn't have it. You can create it manually in your back office. Or you can modify chex/classes/manager.php file and change the image type to something your theme provide. Anyway, your suggestion to allow user to select image type is a good one. I will probably implement it differently, though -- because the layout expects specific image dimensions, I can go through all image types in the system and choose the best one automatically. Good idea, I've added this to the backlog I'll think about this. It might be possible, but maybe not. I'm sure there are some dependencies on states in the chex code You can use standard translation tool to change displayed text. I guess it would be nice feature to automatically detect the reason why no carriers are shown (there can be many) and display different message for every reason. I have actually thought about this functionality for a long time now, just not in the context of chex module. Merchants often struggle to figure out why some carriers aren't display in checkout, so I thought some 'explain it to me' module would be beneficial to the community.

How did you import the statuses? Did you use some sql script?

I didn't forget about that. This is actually the reason why I deduced there is extra name column in order_state table, as that's the only possible reason for db to throw this ambiguous column error. I don't think so. I've just tested fresh install of both 1.0.8 and 1.1.0, and both created proper order_state table, according to installation script. I really think the problem here is related either to some third party module, or to some sql-based import error

I'm running on 10.3.12-MariaDB without any issues

Did you check if tb_order_state indeed contains the 'name' column? it will not. And if the module is written badly, then even module uninstallation won't help.

No. TB core does not modify database schema

Looks like your tb_order_state database table contains column named `name`. Thirtybees does not contains such column SHOW CREATE TABLE tb_order_state; CREATE TABLE `tb_order_state` ( `id_order_state` int(11) unsigned NOT NULL AUTO_INCREMENT, `invoice` tinyint(1) unsigned DEFAULT '0', `send_email` tinyint(1) unsigned NOT NULL DEFAULT '0', `module_name` varchar(64) COLLATE utf8mb4_unicode_ci DEFAULT NULL, `color` varchar(32) COLLATE utf8mb4_unicode_ci DEFAULT NULL, `unremovable` tinyint(1) unsigned NOT NULL, `hidden` tinyint(1) unsigned NOT NULL DEFAULT '0', `logable` tinyint(1) NOT NULL DEFAULT '0', `delivery` tinyint(1) unsigned NOT NULL DEFAULT '0', `shipped` tinyint(1) unsigned NOT NULL DEFAULT '0', `paid` tinyint(1) unsigned NOT NULL DEFAULT '0', `pdf_invoice` tinyint(1) unsigned NOT NULL DEFAULT '0', `pdf_delivery` tinyint(1) unsigned NOT NULL DEFAULT '0', `deleted` tinyint(1) unsigned NOT NULL DEFAULT '0', `active` tinyint(1) unsigned NOT NULL DEFAULT '1', PRIMARY KEY (`id_order_state`), KEY `module_name` (`module_name`) ) ENGINE=InnoDB DEFAULT CHARSET=utf8mb4 COLLATE=utf8mb4_unicode_ci If this is the case, then you need to figure out why this extra column exists, and if you need it (this column was probably created by some module)

Thanks @Kleijn36 for reporting this bug and giving me access to your test server. I was able to reproduce the issue locally, and device a fix. It will be part of the next version

json-ld module only supports 2 review modules - native productcomments and yotpo. If you are using other review module (revws or other) you are out of luck. If you are using productcomments module and google is complaining about missing review-related metadata, then you can safely ignore it. It's just google being stupid. You can read more about this topic here

Hard to tell what's wrong. Can you please share the cart rule settings, so I can try to reproduce it on my localhost?