datakick

They have a banner on their home page saying "All our Modules & Themes are Now Free due to the COVID-19 Outbreak!" That's a very nice gesture

And what does the error message says?

That's not true. I'm using tb in my local installation with php7.4 without any problems. True, there are some notices and warnings in the log. But that doesn't mean tb is incompatible with 7.4. It means that it will not be compatible with future versions of php, unless somebody addresses those warnings.

I don't see any reasons why thirtybees wouldn't work with php7.4. There might be some new warnigns / notices in the logs, but nothing serious. Report these to github.

For performance reasons the geolocation result (country code) is stored inside cookie. If you visited your site using the Safari before you turn on the VPN, it's likely the cookie contains your real country

Google (and others) is using many data centers across the globe to crawl and index your site. Guess what will happen when google access your site from a restricted country, and your server responds with standard success http page? It would index this 'This page is restricted' content instead of the real content, and that would hurt your seo efforts greatly. That's one of the reasons why tb responds with 503 error page -- to clearly indicate to all crawlers that the content they are seeing is some sort of exception, not to be cached or indexed. Anyway, I don't understand the need for geo-restriction at all. If you don't want to ship to some countries then solve this at carriers / zones level. But to completely block access from these countries is overkill

Looks like modules directory is missing, or has wrong permissions /home/domain user name/domains/pewterjewellery.co.uk/public_html/modules/

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