datakick

any admin templates override installed?

Nope, just a couple of Deprecation warnings. Your module code contains some syntax that newer PHP does not like so much, but it still tolerates it.

What is the reason your current module stopped working? Did it use override?

Check blockcart.tpl in your theme. It probably uses some smarty variable that is not defined in core / module(s)

For product to be indexed, it must have visibility set to Search or Everywhere must be Enabled (in shop context) must be associated with given shop (in case of multistore)

Any javascript errors in console?

Have you tried blackhole for bad bots module? Might help. If you know the IP address upfront, you can also pre-populate the blacklist: INSERT INTO tb_blackholebots_blacklist(address, date_add, date_upd, cnt) VALUES('123.123.123.123', now(), now(), 1);

not related to thirty bees, it is server misconfiguration. Google error message.

Notice: Upcoming version 1.4.0 will no longer support import of Excel files, at least not out of the box. Why? Thirty bees uses third party library to read excel files. Currently used library is no longer maintained, and does not run properly on all supported version of PHP (specifically on PHP8). There are alternative libraries that we could use, but those does not run on older supported php versions (php 7.0 and php 7.1). Because there is not a library that we could use that supports all php versions thirty bees support, we had to remove excel import functionality from the core (together with current library). But don't worry. Import functionality was extended, and we have introduced ability to register custom importer via module. And we will release new module 'Excel Import Datasource' shortly. You will be able to install this module if you run on on PHP 7.2 and newer. With this module installed, the Excel import will be allowed. This extension also allows for different data source implementation, for example import from XML files, or from API. If you are running on php 7.0 or 7.1 -- you should consider updating your PHP version.

only you can decrypt the message - we dont know your encryption key. Go to Logs and use decryption tool

On php side this is governed by directives post_max_size upload_max_filesize If you have proxy in front of you php server, for example nginx, you should configure it as well.

Upcoming version should run on PHP8. But of course, there might be some modules (third party or even thirty bees) that are not compatible. At the moment, you can try update your store to bleeding edge using core updater, and then switch to PHP8, and test. That would definitely help

the quantity info is not stored inside tb_product table, the column exusts for backwards compatibility only. Look into tb_stock_available table.

The file is owned by different system user than your php server runs under

I believe you are correct. Back in the day we didn't remember exact revision that was being used, we only remembered version. In this case, it is 1.1.0-1.1.x. Problem is that this version pointed to different revision after every commit to the bleeding edge branch. Because we now do not know exact revision, core updater compares your code base with 'current' bleeding edge for branch 1.1.x. And it will find differences, and mark them as manual changes. These warnings can be ignored now. After update this will not happen again, because core updater will remember exact revision.

This is filesystem permission issues. Your php server does not have permissions to write to directories /cache/smarty/cache/ /cache/smarty/compile/ or any subdirectories / files inside these directories. Use ftp, and delete these directories completely, and then create them again. Ensure that the access permissions are valid, and that the owner is the same as the user your php server is running under.

Your current installation seems to be very broken. Try to go to Advanced Parameters > Performance, and enable Debug mode. If this is not possible (another 500 error code), then use FTP and edit file config/defines.inc.php, and change line define('_PS_MODE_DEV_', false); to define('_PS_MODE_DEV_', true); Then go to Admin > Advanced Parameters > Logs again. It should display error in plain text now.

Your ajax request that should return json responded with html error message. This can happen when there is some fatal exception very soon in the request handler, before the controller action. I have extracted the (encoded) error message from HTML response and saved it as .txt file: exception.txt Download it, and then go to your Admin > Advanced Parameters > Logs, and use DECRYPT AN EXCEPTION MESSAGE functionality to see what went wrong.

I suggest you first investigate reasons why core updater causes "flood of errors". If there is a bug in core updater, we are happy to fix it. It is quite stable now, however. If you send me access credentials to your store (and ftp access as well), I can check the errors for you.

That's great to hear. I have moved this to bleeding edge, will be part of 1.4.0 (to be released soon). Fingers crossed. 🙂

This is error in 1.0.8, fixed in 1.1.0 by https://github.com/thirtybees/thirtybees/commit/840a9d6b0e54a5e8fb46cbf52242348f5651339b

Not sure. Maybe you have truncated ps_referer / ps_connection / ps_connection_source tables, but forgot to truncate ps_referrer_cache as well? Go to Stats > Referrers, and click on Refresh Index and then Refresh Cache. That might sync those tables together.

Yes, it's mentioned on the primary CTA on download page. Default download package is indeed for php7.2, since it's very unlikely that any new installations would be done on php 5.6 Support for legacy php versions are mostly for existing stores, and they do not need to download packages. But in rare case anybody needs it, it is there.

https://thirtybees.com/download-specific/

define('_PS_DOWNLOAD_DIR_', '/path/to/dir');