datakick

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

No, it's not supported. The highest supported php version is 7.4. Support for php8 should be in upcoming version 1.4.0. Note that support for php5.6 will be dropped

I have also deployed the bleeding edge to my demo server. You can play with it there and test the solution. https://demo.getdatakick.com/admin561wkvz9k/index.php?controller=AdminLogin&token=a0bcc55a35147408f49720ea9ac7cf79

This is now in bleeding edge. Nobody reported any issues, so hopefully it will work

what?

Hi guys, I'm looking for a testers of a new functionality -- dynamic pack quantities. This new feature allows you to create pack of existing products, and system will automatically calculate available quantities based on quantities of products in pack. The previous method (manual tracking of pack quantities) is still supported. In order to implement this functionality a lot had to be changed, so there is a potential for bugs. Therefore, I would really appreciate your help testing this before I integrate the code to the bleeding edge / next release If you want to test, please use latest version of core updater (1.5.0), and in settings, select 'Distribution channel' = 'Custom targets' in Update tab, select Version type = 'Development branches' Development Branch = 'dev' This will update your store to 'dev' branch.

It's not much of a core material, given that only a subset of merchants would want such feature (only EU, and I guess they do not want it). No changes to the core are needed in order to implement this functionality in a module as well.

I assume this regulation is concerned about final prices. As you know, there is no 'single' final price in thirty bees. There are a lot of components that can impact final price - customer group reductions, specific prices reductions, cart rules, quantity discounts, specific prices for different currencies, etc... Theoretically, the function to calculate final price depends on customer group customer country currency quantity carrier price(productId, customerGroupId, customerId, countryId, currencyId, carrierId, productQuantity) -> number Of course, in most cases, the final price is the same. But it *can* be different. So, for every productId, we would have to calculate final prices for all combinations of these input variables to figure out the lowest final price, and save it somewhere to price history table. And we would have to recalculate prices (sometimes for all products, sometimes only for subset of products) every time something important changes, like product base price changed customer group reduction changed product carrier association specific prices was created, deleted or modified cart rule was created, deleted or modified customer group was created, deleted, or modified Alternatively, we could calculate lowest price for all products periodically, like once a day. But then there would be a potential for breaking the law, as a short-lived price reduction might not be caught and tracked in price history table. Then, some merchants will want a functionality to track multiple lowest prices, for example for 'Wholesale customers' and 'Normal customers' groups. This will make it even more complicated. All of that is a huge amount of work. Just to track price history. This regulation was clearly designed for brick and mortal shops, where there is only one single price displayed on a shelf. In dynamic e-commerce environment this makes much less sense.

Ability to have custom code per store is added in bleeding edge

Very nice. I've tested it, and found only a small issues. For example, escaping for separator value (I can't use separator >) Otherwise, very nice addition. Addition: for 'schema' -- it would be nice to also have {count_values} -- displays number of values {first_value} -- first value according to 'Sorting settings {last_value} -- last value according to 'Sorting' settings

Oh my, what a stupid directive. For example, if I reduce price for a single day (black friday) by 50%, I will not be allowed to announce any reduction for another 30 day, unless it's more than 50 %. Because the reduced black friday becomes prior price. Also, technically very hard to implement.

Fixed in latest bleeding edge, thanks for reporting this issue. https://github.com/thirtybees/thirtybees/commit/c024695e15c5a7f0f8c3b6fdf7859d150a577154

Of course, if the browser visited the page before you fixed the cache-control header, it will keep using cached version of the page for the next 30 days. There's no reason for browser not to do so