datakick

I reviewed this pull request. I must say, I was (and I still am) thrilled about it. This is exactly how I imagine new features to look like - it adds value, yet is fully backwards compatible. If you don't use these new conditions, your carriers will continue to work without any change. Even new database column don't pose any compatibility problems, as it has default value 0. If you, on the other hand, use these new conditions, you can much more easily manage your shipping options. It's a really great feature, if you ask me. The reason why I didn't merge it is not the feature itself, it's existing bug in tb that should be fixed first. And once it's fixed, this proposed feature will have to be refactored as well. Let me explain: Not many people know that thirtybees supports multiple packages by default. Actually, it's often reported as a bug 🙂 This 'multiple package' feature can split your order into multiple one with the *same* reference. Every order can have different carriers, and/or different destination. This can happen, for example: if you use ASM, and have your products stored in different warehouses (this is obvious) if you have incompatible carrier restriction set on individual products if you use multiple destination feature (you can send one order to multiple addresses). This is just theoretical, I've never seen any theme that actually supports this. But backend does if you set 'Delayed shipping' option --> this would split your cart to two orders, one with product on stock (that can be immediately sent to customer), and other with products on backorder and maybe more, I'm not sure... Most merchants don't use these options, and so they will get 1 order for one cart. But thirtybees can generates multiple orders for one cart, and we must continue to support this functionality. Now, the bug I mentioned earlier is that the carrier Maximum package weight is evaluated using weight of all products in the cart. But it should be using package content only -- calculate the weight of the specific package. The feature in the PR does the same, but with min/max price. Let me give some example when this might be a problem. Let's also have two carriers Carrier A that can handle high value packages Carrier B that can transport heavy objects Let's have two products: very pricey Golden bracelet. You will associate this product with carrier A only. 50kg of dog food. You will associate this product with carrier B only. If user adds both products to one cart, the result will be two orders with same reference. One order will contain Golden braclet and will be send using carrier A. Other order will contain Dog food and will be sent using carrier B. This is correct. Now, let's edit Carrier A, and set Max package weight to 1kg. And try to order these two products again. Now, you will get 'No carrier available'. That's because thirtybees will calculate total weight of the 'cart', which is >50kg, and use this weight to check if all packaged can be sent. And obviously, this check will fail for carrier A. Instead, tb should calculate weight of specific package (in this case weight of golden bracelet only) and check if it matches carrier restrictions. This needs to be fixed

Actually, this is not what I meant. The check displayed on your screenshot is performed by thirtybees, but it's performed at the time user adds item to the cart. It can be a long time before the customer completes the purchase. If this was the last product in stock, and somebody else purchased it before the first customer completes order, you would end up with negative stock. To prevent this (or mitigate it), I've added another test that is performed at the very last second -- when you click on 'Buy' button in chex. There is still a chance that you will end up with negative stock, but with this check in place, this issue should be reduced to minimum. The race condition is now limited on the timespan that customer spend on payment gateway only

I've just released new version of chex module containing following enhancements: Minimal purchase amount Chex now verifies minimal required purchase total settings that can be set in Preferences > Orders Last second product availability check New feature - check for product availability. This verification is performed right before the user is redirected to payment provider. If the product is no longer available, redirection to payment gateway is blocked, and customer is notified about product being not available anymore. This feature greatly reduce the possibility of ending up with negative stock. Support payment form binding Added support for payment modules that implement redirection to payment gateway using POST form binding. Remember selected payment option This small enhancement make selected payment sticky. When you navigate from checkout page and later return back, then previously selected payment option will be recovered

@AndyC please PM me your shop address so I can test it myself. Also, please back office credentials, so I can enable/disable chex module

These recommendations were discussed many times on the forum, for example this flame from two years ago. Unfortunately, not much was done in the last two years, other than code implementation. Stable and nice codebase is important, of course, but it's not what will attract users. When I look at the last two years, I see a lot of wasted opportunities. There should have been massive campaign to attract ps16 merchants when support for their platform was ending. There was none. Third party developers with ps16 modules should have been contacted, and some incentive should have been offered to them in return for maintaining their modules compatible. For example, their modules could have been highlighted in the 'modules' page in your back offices. Again, this didn't happen. And since then, most of these developers either completely migrated to ps17 platform, or quit the presta-world completely. And there are so many other things that could have been done. Instead, the platform stagnated. The only area that was worked on was codebase. And that just not enough. Two years ago, I wrote: I wonder how accurate builtwith.com data are - they track ~576 sites Now, this web tool tells us there are 509 active thirtybees sites. These two years should have been the best time for attracting new users. Instead, we lost some. This inactivity is what drove my decision to quit. I have no problems working for free on an open source platform. I have problems seeing this work being wasted. If the situation changes I might revert my decision. But I don't see how it could change, unfortunately. Also - I don't want to 'take over', as some of you suggested. While I'm flattered, I don't want to do that. I would really hate doing all those things that I've just complained above. I'd be terrible at that, I'm sure.

fixed in 1.1.x https://github.com/thirtybees/thirtybees/commit/15da223b227dc973ef8d7d448292896ca8b3a27b

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