datakick

Of course I can ask them to look into database 🙂 But fortunately I won't have to

Why? For people that will use Stable releases this is not an issue. The revisions will always match official release tags, such as 1.3.0 or 1.2.0. If you are using bleeding edge, then you will see current exact git commit. This information for machines, not for humans. Revision is precise and it nicely correlates with information on github. I understand that from human point of view, it's nicer to see 1.4.134 instead of d601a7dfa69025341ea598f558885b6cbbd7b7b4. However, nobody would be able to figure out what exactly is part of version 1.4.134, or what are the differences between 1.3.0 and 1.4.134, simply because 1.4.134 would not tracked in repository. With revisions, we can look at github and see it all. What is part of this version? https://github.com/thirtybees/thirtybees/tree/d601a7dfa69025341ea598f558885b6cbbd7b7b4 What are the differences between 1.3.0 and current bleeding edge? https://github.com/thirtybees/thirtybees/compare/1.3.0...d601a7dfa69025341ea598f558885b6cbbd7b7b4

I believe you were on some bleeding edge version before? If that's the case, then rest assured -- this is the one-time issue only. Next update will not be affected. When updating to bleeding edge we didn't actually saved exact git revision that was being used. In your store the only available information was that this is some variant of 1.2.0. Not very useful. During update, core updater asked server for a fingerprints of files for version '1.2.0', and checks it agains files on your server. Of course, every files that were modified between 1.2.0 and the bleeding edge version you have on your store will have different fingerprint, and so they will be considered modified. The new core updater fixes this issue -- we now define new constant _TB_REVISION_ that points to exact git revision or tag. During update, core updater will ask for fingerprints of files for this exact revision.

From server log I can see that some clients requests file list over and over again. Looks like the client fails to store the file list to cache. At least thats the only explanation I could came with. This is (hopefully) fixed in latest version of the module. Are you using 1.4.3? Edit: From your log it's evident you are using 1.4.0. Please update core updater module. BTW, what mysql version are you using?

Install new version of core updater 1.4.3 and try again.

Then it's the issue of your theme. You will have to edit product.tpl and fix it there

definitely not 3 gigs, maybe 3 megs. But you are correct, we log too much. I've released new version of core updater with optimised logging. Looks like the the API request didn't finish for some reason. This is server-server communication, so definitely not browser issue. Maybe you have some sort of antivirus / security software installed on your server?

Yes, reinstallibg module should create mebu item. Even if not, you can go to module configuration page, and click on Check Updates on upper right corner

try deleting cache/class_index.php

Also, if you are using cloudflare, try to disable it for the installation process. Cloudflare by default respons with 524 Gateway Timeout error after 30 seconds... so even though your server supports 300 secs the request will be terminated after 30 seconds.

Hard to tell what's wrong. This seems to be server configuration issue, though. Maybe there are performance limits on php/mysql server

Yes, it would be updated, unless Update community themes option is disabled in core updater settings.

search for 'Spam'

There was a bug. It is fixed now.

Still weird. The controller code verifies that the list of bcc addresses is valid, this should not result with null item. I tried to reproduce the issue, but without success...

The root cause is here: /home/veganlin/public_html/classes/Mail.php(293): Swift_Mime_SimpleMessage->addBcc(NULL) The system is adding null BCC address. Now, the question is why. Do you have some module that hooks to hook actionEmailSendBefore? check BCC all mails to configuration option in Advanced Parameters > Emails can you PM me access to your back office?

Disable module mailalerts and try again. If it works, enable it again, and fix its configuration.

The root cause is well hidden... this module does excellent job hiding everything important from everybody Edit file modules/stripe/classes/PaymentProcessor.php, find line this->addError($this->l('Failed to validate order'), (string)$e); and change it to look like this: d("$e"); $this->addError($this->l('Failed to validate order'), (string)$e); The d("$e") should display additional information when error happen. Hopefully we can use this info to figure out what's actually wrong

Looks like when you updated module, its configuration was reset, and it's back in testing mode. The payment intent is stored in cookie, and is no longer valid. Please check module configuration and switch it to live mode, if that's what you are testing. Also, clear browser cache / cookies.

https://github.com/thirtybees/tbcleaner/releases

PHP 8 is not supported. I guess this will be the source of the problem.

Did the ajax request failed, or just took a long time to process?

In my opinions these are indeed critical. System expects that database columns can store more data than they actually can. There are two possible things that can happen when system tries to store longer strings data truncation -- entered data will be silently truncated by the system. Loss of user entered data is a serious problem, imho an error can be thrown -- sometimes data are not truncated, but an actual exception is thrown. For example, see this issue: https://github.com/thirtybees/thirtybees/issues/1056. Yes, these are serious issues, hence the critical flag

This is actually a first time issue only. This was always a problem with bleeding edge. When you updated your store to bleeding edge, we never actually saved information about the exact git commit that 'bleeding edge' referred to. Without that information, core updater couldn't really check what files were modified. It always used files from latest stable version (1.2.0), and compared files on your server agains them. Obviously, any and all modifications to core files performed between 1.2.0 and git commit that was used for bleeding edge would be marked as 'modified by user'. Which is not correct. From now on, core updater will store the exact revision inside _TB_REVISION_ constant. _TB_REVISION_ can contain either specific tag (1.2.0), or exact git hash like a09146c3db421e1604dd45dc8d63925c4aee7c4f. Core updater can use this information to compare your files with proper git commit.

I have uploaded new version of module (attached in the first post), which fixes some issues with 500 errors logging, and also with the incompatible modules