datakick

I may be a good developer, and I could surely lead the technical side of the project. But I don't think I could do the business part -- and without it, we would end in the same mess we are now. Let's not jump to any conclusions, or spread unfounded rumors. The supporters money goes to tb company for sure. As far as I know, @lesley regularly sent them (and then some more) to @Traumflug while he was still working on code, as his monthly stipend. I truly believe there was no 'fund misappropriation' here.

change lines 1256-1257 from $output = array(); $output = array('skins' => '', 'layouts' => ''); to $output = array('skins' => array(), 'layouts' => '');

This Vary problem would occur when your page contains image url like http://www.domain.com/my-image, and this url returns different content for different user agents. That's not the case with thirtybees. We have different urls like http://www.domain.com/my-image.webp and http://www.domain.com/my-image.jpg so there's no ambiguity for cloudflare at all.

Let make something clear - my decision to leave this project was never about money. I was never an employee (or owner) of thirtybees. While my contribution was mainly for free, it was not selfless. It brought me a lot of recognition in the community, and subsequently a lot of job offers and modules sales (and I'm grateful for all of you for that). I was also occasionally hired and paid by @lesley for particular jobs (like stripe module overhaul), so I did earn some money out of this. My decision to leave was based on my longtime frustration with the current status. I know Lesley is/was seriously ill, and it's probably one of the reasons why this project is now drifting without any direction. What this project need most is an active leadership, and I'm afraid Lesley just can't provided that at the moment. I was trying to keep this project afloat for a long time now, maintaining good spirit, and faith in the project. But I just can't do that anymore, because I don't believe that the things will change anytime soon.

I have no idea. I was never part of tb company. Just a volunteer with github access 🙂 I guess it's just @lesley

No, I'll still maintain and extend my existing modules, or even create a new one. I'll just stop fixing bugs in core, implementing new features. And probably limit my presence on the forum

Hi everyone, I just wanted to say good bye to all of you. I decided that I will no longer participate on thirtybees project development, as it takes too much time and effort on my part. Lately I was feeling like I was the only one pushing this project forward. And I'm not even affiliated with the tb company, I was just a volunteer doing this for free. It's been a fun journey, but I think it's time to move on. I wish you all good luck with your stores Petr

I don't really care that cloudflare doesn't support this header, as it's not used in decision process at all. If browser send information that it can handle webp format, it will receive webp images, otherwise it will receive jpeg. For older browser this means they will always receive jpeg. If tb webp feature is used (and fixed), it will work regardless if you use cloudflare or not. I

Oh, I take this back. There's a bug in thirtybees core that actually does not do the check correctly -- so you are right, this config can fail for some old browsers.

There's no need for any of this. Thirtybees generates different html content for different browsers. If browser supports webp, the image links in the page will have .webp extension, otherwise image links will have .jpg extension. Since dynamic html is not cached by cloudflare, there's no issue at all. Works like a charm

Innodb engine is a must. You should ask your hosting provider to enable this on youd db server... Or switch hosting

The problem is that order is created "after" payment is already processed. And it's just not possible to NOT create it at this time. The money are already on the way, so we need to track it against some order / customer. If the stock meanwhile decreased to zero between the product was added to cart and order was paid, the result will be order on backorder. It's not possible to fix this problem completely, not without fundamental change to ordering process.There will always be some timespan when this can happen, we can only limit it to the minimum. For example by checking the availability just before the customer is redirected to payment gateway. But with 3DSecure / SCA / SMS confirmations the payment can take a long time, so this issue can still occur. Regarding your question -- no, you can't use this with chex. But I'll add this 'last second' availability check to limit this to the minimum. Will be in the next version

that sounds like a browser cache issue to me

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),