datakick

turn on debug mode first in Advanced Parameters > Performance

Ou, revws tables use utf8 charset, that's not suitable for storing emoji. I might fix this in the future. Meanwhile, you can modify the tables https://stackoverflow.com/questions/39463134/how-to-store-emoji-character-in-mysql-database

Thirtybees is continuation of ps16, and should be backwards compatible with it. That means, most of ps16 modules will work on thirtybees. But thirtybees modules might not work on ps16. Ps17 is completely different beast. It's not compatible with neither ps16, nor thirtybees. ps17 is often not compatible with ps17 itself 🙂 Stay away from it.

Address format is determined by country. Country (and associated AddressFormat) is not multi-store ready, so this settings is global for all stores. I believe this is the correct behaviour. Your use case is really very rare, and in my opinion does not justify making AddressFormat multistore. To solve your requirement, you can override method AddressFormat::getFormat. Please do this in custom module if you can

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