datakick

I believe the easiest solution for you is to just tall your store to use old prefix. To do that, edit file /config/settings.inc.php and change value for define('_DB_PREFIX_', 'tb_'); for example to define('_DB_PREFIX_', 'ps_'); Then go to core updater and check database differences. If there are some critical changes, apply fix. Please backup your database before. If this prefix changing is not the right approach for you, for some reason, you will have to copy every table independedly. Use sql like this for every table (ps_product is source, tb_product is target) truncate tb_product; insert into tb_product select * from ps_product; If the columns or their position are different, you will have to enumerate all fields as well: insert into tb_product(id_product, id_supplier, id_manufacturer,.....) select id_product, id_supplier, id_manufacturer,..... from ps_product; Very tedious task

@jmeca download this file: https://raw.githubusercontent.com/thirtybees/thirtybees/main/tools/cacert.pem and upload it to your thirty bees /tools/cacert.pem

Server certificate on api.thirtybees.com is not expired, it's completely valid.

what?

This is your server configuration problem. Certificate on api.thirtybees.com is valid and trusted: Your server probably do not have updated trust stores / root certificates. You need to update your server packages. How to do that depends on your distribution. Some hints can be found for example here: https://superuser.com/questions/1679204/curl-on-ubuntu-14-all-lets-encrypt-certificates-are-expired-error-60

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