datakick

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

Nah, theme switching will not create such mess. If I remember correctly, back in the day when we were updating from 1.0.3 to 1.0.4 manually, the instruction was to remove these modules from filesystem. But that did not remove references in the database, obviously. I had problems with these modules once, so I had to create consistency check module. That can help you to get rid of these easily.

Yeah, that's unfortunate. I'll extend the core updater module to automatically remove reference to these non-existent modules from db.

This table is created during module update / installation. Thirty bees automatically executes module update sql scripts/php scripts when the newly uploaded version is higher than current version. My guess is that you had merchantsedition version on core updater installed previously. That module has version 2.0.0. When Overriden by tb version 1.4.0, thirty bees decided no to apply update scripts.

@Mark thanks for the info. Could you copy the error message and send it to me via PM. Or, alternatively, give me back office access so I could test? Thanks

The main issue I have with this concept is the different level of support of these elements/components by themes. Third party commercial themes would not come with templates for these components at all. Some themes might support only subset of components (maybe new components were introduced after the theme was released). The only way I can see this to work is for every component to have some default, theme agnostic, template. And this might be hard to do, because such template would not be able to use any framework css, any framework js,... Themes could, of course, override these default templates. But even if they did not override them, the components would still work to some extent. Is this aligned with your vision?

utf8 encoding is basically utf8mb3, and as such it can't store some utf8 characters. While most merchants will not encounter any issues with this, it's still recommended to update to utf8mb4 to be sure no data will be lost when saved to database. Most importantly, without utf8mb4 encoding, you can't enter emojis into your product descriptions. And we can't allow that. /s