datakick

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

Uninstall or reconfigure blockfacebook module And no, it definitely did not itself after a few weeks of using thirtybees.

Again, investigate overrides / modules. Try to disable overrides and check if dashboard works -- if it works, investigate which override is a culprit Try to disable non-tb modules and check that dashboard works -- if it works, then enable non-tb modules again, and disable individual modules to figure out which one is the culprit This is not a bug in core, it's very specific to your installation. Nobody can help you much without access to your back office and/or error logs

@PeterPan Most likely you have override for template admin/themes/default/template/controllers/dashboard/helpers/view/view.tpl. This template is responsible for displaying the dashboard page Look recursively in your /override/ directory for file named view.tpl

@Mediacom87 I'm not sure what are you asking about. Let me just summarize how installation/update will work, hopefully it will answer your questions You will have to use coreupdater module to update to 1.4.0. If you are running your store on php 5.6, core updater will not offer you 1.4.0 target, because it will not be compatible with your system. You will be able to update to 1.3.0, though. Depending on version of your thirty bees, you will either switch to php 7.x and then update to 1.4.0 -- if you are on relatively new version of thirty bees that supports php7 update to 1.3.0, then switch to php 7.x, and then finally update to 1.4.0 -- if you are running old thirty bees version, such as 1.0.7 Once you are on 1.4.0, you can switch to php8.0. Note that php8.1 will not be supported yet. I have tested it, and there are other breaking changes, unfortunately. I am also working on standalone version of core updater -- a standalone web application that would not require underlying thirty bees in order to work. This version would run on php8 out of the box. You would be able to unzip it into subfolder inside your thirty bees installation, then switch php to 8, and directly update (or migrate from ps16) to 1.4.0.

Multiple feature values was always one of the most wanted feature in prestashop community. You might not have a need for it, but a lot of people do. Anyway, this enhancement proposal by @wakabayashi is not about implementing multiple feature values (that's already in the core), it's simply pushing its usability to new level. I can see a lot of use cases for what he proposes. And it's awesome that there are few community members that contribute to the codebase. Please file enhancement request for blocklayer module: https://github.com/thirtybees/blocklayered/issues