datakick

That's a lot of errors. I think that all of those are from browser plugins, though, not from your website. Try to use different browser, or disable all extensions in your firefox

look into browser console for errors

I don't see it that way, as the company would be hundreds of thousands in debt.

My module does not handle payments. When you click on Buy button, it simply redirects to url that payment module provided via hookDisplayPaymentEU Note that this url can be external url (paypal checkout page), or some module controller on your server. Either way, if it doesn't work, it's not fault of an OPC module

To make things clear - by "not being interested" @lesley means I turned down his offered to sell me the tb company. The asking price was 30x more than I could (or would) ever pay for it. And frankly, even if the offer was 30x lower, I'd still have to think very very hard about it.

Upgrade your tb to bleeding edge. This issue is already fixed there

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.