datakick

I'm sorry, but if you don't know such *basic* info, you shouldn't do this task at all.

This was always the way to go. Ever since the first version of prestashop, this is how you move from one domain to another. There are thousands of tutorials on the interned describing the process. In short: backup database copy all files from source to target server extract db dump adjust configuration (db connection, cache servers, server urls) This will, of course, keep the original table prefix. But who cares if tables starts with ps_ or tb_ or ps_db_34fslj, it's just prefix to allow multi-tenancy.

Thank you. Yeah, it sounds like this should not be in the *core*. It's a typical material for a module 🙂

I've seen the remnants of this feature in the code, but I've never seen what it does. Could you share some screenshots / explanations what it is good for?

Thanks for the nice endorsement, I really appreciate it. My module is indeed very flexible, unfortunately that also make it intimidating to new users.

Not really. Country active status should not prevent merchants from setting up payment modules. For example, some merchants want to prepare multiple payment modules for some disabled country. Only after everything is set up then will enable the country, and this will actually show these new payment options in checkout page. Your first suggestions - to handle this on front end via some javascript - is much better. Also, AdminPaymentController does not contains $active property. So, $this->active always returns null, and !$this->active always return true. So your change should look like this: 'items' => Country::getCountries($this->context->language->id, true),

This is obviously a bug. Let's track this in https://github.com/thirtybees/thirtybees/issues/1171

@DRMasterChief can you share your site url, so we can check this on actual site?

Not a bug. You just need to fix your installation. In this post thread: you wrote that consistency check found extra file: /classes/db/DbMySQLi.php. Now look what file is this exception complaining about. If you have removed this file as suggested, you wouldn't have this issue. A little explanation: translation tools load all php files in /classes directory in order to find translatable strings. They load even extra files that are not part of official thirtybees release. In your case, it loads ancient remnant from ps16 - DbMySQLi.php was part of prestashop 16, but is no longer supported by thirtybees. You should delete it.

see my previous note -- your screenshots shows loading of *.woff, not *.woff2 -- these are different formats, with different content types

I don't think this has anything to do with tb, but it's misconfiguration of server. I really believe that if you fix content-type it will work correctly. Content type tells browser how to interpret file. If server send invalid, or unknow, type then browser just don't know what to do with the file. Note: in your last screenshot you are displaying content type for woff file type, not for woff2 Note2: specification is very clear about mime type: https://www.w3.org/TR/WOFF2/#IMT According to specification, woff2 mime type is font/woff2. Your server sends application/font-woff2

This explanation message is probably a red herring. What thirtybees does is it tries to find all available carriers for delivery address associated with cart. At different stages of checkout process, this address is different. For example, guests don't have any address associated yet (in that case, tb will try to find available carriers for default country + visitor group) List of available carries for address is then filtered by carrier conditions (max weight, price, etc...). If condition is not satisfied, carrier is removed from list, and the 'reason flag' is saved. If all carriers are filtered out, then theme will display error message depending on collected 'reason flags'. Most themes (based on default theme) will display only the first reason in the list. This is the reason associated with the first carrier that was filtered out. Of course, other carriers might have been filtered out for different reasons, but theme does not show this info. Let me show some simple example: A B C D E F | | <-- 1) list is filtered by address (its delivery zone) + group + product restriction | A B C D | | <-- 2) list is filtered by carrier conditions | A C In this example we have 6 carriers. Filter #1) for *guests*, the list is filtered using country associated with visitor. This is usually default shop country, but it can be an actual country, if you have some geoip module installed. Also, this initial filter takes into account current customer group (VISITORS) and filters out any carriers that are not applicable to this group. Also, product carrier restriction is considered. Or Warehouse association in case of advanced stock management. This first filter can reduce the list significantly. And what's more important, we don't track the reasons why were these carriers filtered out Filter #2) carriers are evaluated according their conditions, for example max weight. If conditions are not met, then the carrier is removed from list + reason is saved. In our example, reason for 'B' could be 'max package weight', and reason for D could be 'out of price range' If, after the filter #2 the list is empty, thirtybees will explain this using the very first collected reason information. In our example, this reason would be 'max package weight', even tough there were many reasons why the carriers were filtered out. My only recommendation for you is to edit the theme template, and replace this 'max weight explanation' with generic 'No carriers were found' explanation.

Surely this could be implemented without core files modification. - The changes to ProductController are fine (from backwards compatibility point of view), as it's just addition. However, I think it's not necessary, as there is already a functionality that saves the customization -- we could simply call this existing one using ajax. - The change to tools.js is more severe, as it might impact other themes that does not implement this 'auto save' functionality. I'm sure we could maintain the original tools.js, and add some more preparation inside theme-specific ajax-cart.js If we could do that, than this would be theme-only change, with no side effects or compatibility problems

@AndyC can you please send me the nochex module in zip file to petr@getdatakick.com ? I'd like to investigate what's wrong, and to see if there's anything we could do on core side to prevent this kind of issue

Do you have module Data Mining for Statistics installed and enabled?

Well, the problem was that you enabled Advanced stock management, but didn't associate your products with warehouses. After I disabled this feature checkout works just fine. If you want to use this feature, you need to create warehouses associate warehouses with carriers associate products with warehouses (and locations)

From your screenshot above it looks like you don't have associated any delivery zones to your carrier.

Content type should be font/woff2. You should adjust your nginx configuration accordingly.

I still don't see the what is inside Content-Type header 🙂

You wrote you are using nginx --> .htaccess is therefore irrelevant (unless you have apache behind nginx, which would be kinda weird) You didn't respond to my question -- what content type is the font resource served with? Look into network tab

What content-type is returned for these font resources? Browser might not load fonts if the resourse is served with invalid or incorrect content type.

:) thirtybees is prestashop 1.6 on steroids. Most 1.6 modules are therefore compatible. The problem is that some of them are gettion outdated... Just stay clear of 1.7 modules

What does javascript error console says?

I use free plan + native thirtybees webp support. Cloudflare has no problems with caching .webp.

Yes, it does. No modules are necessary. Just theme support is required