datakick

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');

your email template uses invalid placeholder {virtualproducts} instead of {virtualProducts} yep, it's case sensitive. Go to localization > translations and edit email template there. ps: the smae with {nbProducts}

anyway, zip files downloaded from crowdin are not valid localization pack. The output needs to be slightly post-processed and then repacked

I see what's wrong. The code does not accept zip files, only .tar.gz or .gzip archives. You will have to unzip the file, and repack it as .tar.gz file first

Try to rename file to pl.zip

Hi all, the next release will come with new version(s) of smarty library. Depending on your php version, it will be either smarty 4.1.1 (php 7.1 and higher) or 3.1.45 (php 7.0) Since templating engine is critical component of a store, I would like you to ask for testing before the update. You can use core updater module to update your testing store to custom branch 'smarty'. Please report any issues

I believe the upload size is governed by your php settings: https://www.php.net/manual/en/ini.core.php#ini.upload-max-filesize Regarding the download location: you can try to change constant _PS_DOWNLOAD_DIR_ To do that, create file (if it not exists yet) /config/defines_custom.inc.php and add this <?php if (!defined('_PS_DOWNLOAD_DIR_')) { define('_PS_DOWNLOAD_DIR_', '); } You will have to move all files from /download/ directory to the new location. And hope it will work 🙂

Maybe it would be a good idea to investigate / fix those integration issues first Of course. But whatever security measure you implement they can, and will, overcome. Merchant: Lets implement request rate limiting per IP address Hacker: nice try. We can use TOR network to send every request from different IP address Merchant: Let's implement request limiting per customer id Hacker: bummer. Never mind, let's create new account for every credit card test. It will only take two seconds more per test Merchant: Let's add another input into form, for example email the second time. Normal customers will be confused, but it will surely stop those bots Hacker: Hey, Jose, they changed the form again. How long will it take to re-record the script? Nah, it's just another email address... Two minutes? Great, whenever you have time Merchant: Captcha, Captcha, Captcha, ReCaptcha and TriCaptcha Hacker: Image recognition, machine learning, AI,... or simply outsource to India for $5/day -- human can solve 1000's of captchas per day Merchant: I don't know... Hacker: muhehe Off-site payment processors for the rescue. Let smart guys from stripe bring the heavy guns into this fight. There are lot of payment gateways. I agree that paypal is not the best out there.

This is fight against windmills. Whatever security measure you implement will be overcome. Card testers are using your store for one and only reason: you support on-site credit card payment. The fix is simple -- STOP THIS NONSENSE, and use off-site payment processor. Stripe, paypal, or any other payment gateway available). If you redirect your customers to external payment gateway, it will be responsibility of the payment gateway to prevent attacks. And they can do that, they have resources, smart developers that are constantly enhancing security measures, auto-fraud detection, shared and updated IP blacklists, and whatnot. Since attackers are not able to break their defense, they are targeting small sites like yours. Also, having on-site credit card payment form is very dangerous. Your checkout page is sending plain card details to your server php script: So, obviously, your store have to be PCI compliant, which is a huge burden. But it also makes your store primary target for hackers -- if they take control of your store, they can steal credit card data. And you would be responsible for any damages. I would be scared out of my mind if I had credit card form on my site. Please, pretty please, use third party payment processor. It's 2022, nobody is expecting credit card form to be part of the checkout form. In fact, this is a huge red flag for a lot of people -- I personally would never complete transaction on your site because of this. I don't trust your store with my card information