datakick

did you clear server and browser cache? Also, if you use cloudflare or similar service, clear that cache as well

I remember a joke about intel processor FDIV bug. It was something like A: Hey Pentium, could you calculate 5.0 / 2.0 for me please? P: Sure, it's 2.51 A: But that's not correct... P: Yeah, but look how fast I get the result With FPC you can pretty easily get to the same state. You should test your site extensively, and check how modifications propagates across different areas of your site. For example, if product becomes unavailable, look if it's marked correctly both on product page, and on category page... I'm afraid you will find plenty of inconsistencies soon

Link to github repo?

Thirtybees contains ASM (Advanced Stock Management) -- this should allow you to track purchase price of different lots.

Well, this whole thread is an evidence that you can't, actually Me and the others have tried to help you with this task. Well, not me personally, as I've come to the conversation quite late. But others spent a lot of time and effort to help you. You just don't want to listen. Migration from one server to another *is not* a standard functionality. It's has nothing to do with the purpose of the software -- to sell the stuff online. Just like with the car simile. Its purpose is to drive you around, and it does this job just fine. But it will not replace oil filter itself. You wouldn't expect it to, would you? Thirtybees company earns a lot of money. But it's kind of you to worry about that.

I have a car. I know how to drive it. I know how to turn on the radio or how to use navigation. But I don't know how to change the break master cylinder, or what kind of oil filter it uses. Nor should I ever ever have to. There are car mechanics that know this stuff, and can fix this for me much faster. The result will be better, and probably much cheaper, then if I did it myself. With thirtybees (or any other ecommerce platform) its the same. It's designed to help you sell stuff online. And it's pretty good at it. But it will not magically migrate itself from one domain to another. You need more than a user level experience with the system to do this. It's not a shame if you can't do it yourself. Just hire somebody who can. Like I hire car mechanics to replace oil for me.

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 [email protected] ? 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 🙂