datakick

Also check Advanced Parameters > Logs and look for entries that starts with MaxMindGeoIP2

Are you using cloudflare, by any chance?

You can probably use multistore to achieve this. I believe @rubben1985 do something like this

Hard to tell, this can be caused by many things. Somebody needs to debug things

Oh, this looks like a bug. There are different rules to determine set of hooks affected by FPC in Configuration page, and in Hook class. This should be unified. With this in place, this issue will probably be solved itself, because 'actionProduct...' hook should not be considered at all

When you copy the url and paste it into address bar, does it work as expected? If so, then it's javascript / client side issue. If the url does not work, it's server-side dispatcher issue.

Mark the hook actionProductListOverride as cached (green) in FPC settings

Unlikely. This sql query is run by dashactivity module -- the main Dashboard page in your thirtybees backoffice. The query is perfectly valid, and it runs without problems on virtually all thirtybees installations that exists. You probably have huge tb_connections and tb_guest tables. There are modules that can clear these tables for you

Definitely not what I meant. Patching core files is not the right way to do things. Core files should remain as they are supposed to be. At the moment there are two mechanism that can be used to tweak behaviour - hooks and overrides. There is a big hate towards override system among developers. I agree that it's not ideal, but a system like this is necessary in order to have a flexible platform. And hooks are not the solutions here - it's just not possible to pre-make hooks for everything, as core developers can't anticipate all needs. Some people argue that if module developer needs some new hook, he can always create a pull request, and the hook will be in the included in the future version of the platform. That's true, he can do that. But there are many buts: first of all, it's not guaranteed that the PR will be merged at all if it is merged, it can be merged with some modification, prompting original developer to adjust his module once again it can take a lot of time for the new version to be released -- module developer can't sell his new module meanwhile even if it's merged, module developer can't sell his module to older version of the platform and finally -- hooks are runtime mechanism that adds quite a lot of overhead. The more hooks we have (support), the slower the system. Overrides are much faster I believe hook system is nice to have, but it can't be the only tool to tweak the platform. We really need overrides, or similar system, for example AOP. For backwards compatibility reasons, we need to support overrides. Otherwise 50% of modules would stop working. Because it's such an important part of the customization mechanism, it should receive some love from the core developers. And this is what I was talking about in my former post Implement better override installation/uninstallation mechanism. Automatic override removal when module is disabled or manually removed from filesystem. Semantic analysis of overrides - parse the override file to determine what core methods or properties gets override. Warn if module overrides method that has been deprecated, or removed, from core files. Optionally, report information about overrides to api.thirtybees.com - this would gave core developers much better insight into what can be refactored, and what not.

This is a bit unfair. You shot yourself in the foot back in the day when you decided to modify *core* files. Now you are stuck to the version you 'forked from', and you blame core updater for things going bad during upgrade. Core is named core for a reason. It should not be touched, ever, by merchants. Or by anyone, really. That's why thirtybees have override system in the place, and a hook system as well. Unfortunately, this kind of core modification is very widespread. There are many tutorials on the internet describing how to do things this way. Many third party developers / agencies do this as well, mainly because it's the easy way to do things. The result are shops running on outdated system, scared of upgrading, stuck in the past. It's a bad situation, but it could be fixed, actually. Thirtybees could bail out these shops. We could have automatic tools that would convert these core modifications - extract them to custom modules using overrides. We could also have the system that could learn and understand what has been modified, and notify merchants during upgrade that some of the overrides are no longer valid, for example.

I wouldn't worry, you'll not miss much by not being on the discord channel. And neither will I

I wouldn't call that a flaw. It really depends on what you want to report on. As you know, orders does not always mean income. From accounting and tax perspective, reporting based on invoice data are more important. There is actually a github issue, and PR as well, for this migration to order based reporting. It was never integrated into the mainstream code, because community couldn't decide on what is the right approach here. We even created a poll back in the day, and the result was 50/50. I guess the best approach would be to have this as a preference, or possibility to switch during report generation

No, there isn't

FPC is disabled for logged in user, for security reasons. If you really need this, you can edit classes/PageCache.php, and modify method isEnabled. Then, the FPC will cache pages for customers as well (but for every customer separately), which can lead to huge cache size

Feel free to modify the email template to whatever you need.

Your hosting provider changed the php version on your *live site* automatically without your consent? That's just... well I'm speechless.

This is so funny. Of course you are right. Technically, this is what forking a repository means. That also means that thirtybees has already over 200 forks, so no need to worry 🙂

Most of the ideas you guys posted in this thread are good, and could be implemented. But again, it boils down to the leadership issue. There must be somebody who is actively in charge of the project, and who sets up goals and general direction. Somebody that decides on monetization strategy, and on development directions. You know, The Plan. The reason why I started this thread is that there is nobody doing this job at the moment. It's probably mixture of burnt out / illness that @lesley is going through. But whatever it is, it's not good for the project. And until this is fixed, I don't see any way forward. As @wakabayashi already analyzed in his post, there's only a handful of things that could happen Lesley will once again start doing what he was doing at the beginning of this project. Be once again a leader Somebody buy the thirtybees company, and becomes a new leader somebody forks the code, creates a new company, and starts from the scratch nothing will change, and this project will be frozen in time. It will work for another two to three years, and you should all use this time to figure out what to do next

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