datakick

I'm not sure how I feel about this 🙂 The original purpose of dashboad configuration parameters AVERAGE BANK FEES PER PAYMENT METHOD AVERAGE SHIPPING FEES PER SHIPPING METHOD was to calculate approximate profit margin by deducting payment and shipping fees from order profit. What you are proposing by your PR is to use this dashboard settings, calculate payment and shipping costs per order, and persist them into database. Unfortunately, those would not be an actual costs, those are just approximate numbers. For example, cost of using stripe is 0.5% + €0.25 for standard European Economic Area cards 1.9% + €0.25 for premium European Economic Area cards 2.5% + €0.25 for UK cards 3.25% + €0.25 for international cards So the actual cost of using stripe depends on amount payed + country in which card was issued. Of course you can calculate some average fee based on your historical sales. But saving this info to order does not makes sense. For example, let's say that our average order amount is €1000, so the average stripe payment fee is €10. If somebody places very small order with total €1, should we apply and save this €10 average stripe fee to this order as well? When the real cost associated with this order payment is €0.26? Also, the other issue is that we can't really calculate the order profit in the first place. We don't know the cost of goods sold, because thirty bees does not track this. At the time of order placement we save current wholesale price, but that's not really COGS. We can't calculate profit from that. Well, we do that -- but it's once again just an approximation. Let's say we purchased the product 2 years ago for price €1. Current wholesale price is €5, because our supplier increased price. We sold the product for €10. The profit should be €9 (sales price - purchase price), but the reporting says €5 (sales price - wholesale price). Until we implement proper stock valuation in thirty bees, the reporting will always be just a very approximate overview of your sales. I'm inclined to decline your PR. I don't think it's a good idea to save these approximate/untrue costs numbers into orders. That could only cause troubles. If you want to have better reporting, I suggest we convert those dashboard config parameters to some sort of timeline. So you could say that the average stripe fee in 2021 was 3.21 and average stripe fee in 2022 was 4.12 (because they changed the pricing, for example). Of course, I'm open to your argument.

You mean these ? 'Creating account...' 'Saving shipping address...' 'Saving billing address...' 'Verifying data...' 'Redirecting to payment page...' 'Please wait' You can attach translation file here

I meant this; if ($widhtOfSourceFile >= 2*imageTypeWidth) { // generate retina format } else { // do nothing. retina version for this particular image will not exists } Are there any benefits if the file between $imageType['width'] and 2*$imageType['width']? For example, if source file has width 1005, and imagetype width is set to 1000, should we create image-2x with image width 1005 instead of expected width 2000? Even if the image size is 1500, will there be any retina benefits?

Yes, it is designed that way. You can limit the cart rule to be used only once (Total available for each user). Of course, this is problematic if you allow 'Guest checkout' functionality, because then they can indeed reuse the same voucher over and over again - each guest is considered different user) To mitigate this, you can limit the cart rule only to Customers group -- they can use it, as long as they register as a customer instead of guest.

Blackhole for Bad Bots module is designed for crawlers that do not follow robots.txt instructions, and instead visit every url they find. It may, or may not, help you. Depending on how that particular bot is made. Note that it only blocks IP address, so if the bot is changing IP addresses, it will not help as well.

Well, for 2x images, I think we should not do that. If the source file is not big enough to generate 2x image, then don't do that in the first place.

That functionality is indeed useful. But confirmation email is always sent, and the recipient is likely to move it to spam folder (because they didn't requested it in the first place). This will effectively degrade your send mail reputation. I believe what @selwynorren wants is some sort of bot preventions.

You are absolution 100% correct. If these magic constants ('medium') didn't exists in the core code, there wouldn't be this problem in the first place.

You are also running quite old version of thirty bees - 1.1.0. I suggest you follow this path: first update your thirty bees to 1.3.0 (the last one that supports php5.6) then update your php version to 7.4 update your thirty bees to 1.4.0 install collectlogs module and watch for any warnings / errors and deprecations. do not update to PHP 8 until you fix all those warnings/errors It's a lot of work, I know, but it's not possible to stay at old versions of PHP forever. Your hosting provider might drop support for it in the future, you will not be able to install new modules (or new versions of your modules), there are security issues, etc. Your store is like a shark -- if you stop moving forward it will die.

Delete module modules/maxmindgeoip2 using ftp -- this one is not compatible with your php version. Seriously, PHP 5.6?

Enable debug mode, as encoded encryptions are not useful for us. FTP to your server, go to /config/ directory, edit file defines.inc.php, and change /* Debug only */ if (!defined('_PS_MODE_DEV_')) { define('_PS_MODE_DEV_', false); } to /* Debug only */ if (!defined('_PS_MODE_DEV_')) { define('_PS_MODE_DEV_', true); } Then you will see the actual error message.

Unfortunately, AdminCategoriesController hardcoded these image types into the code. Nobody fixed it yet https://github.com/thirtybees/thirtybees/issues/1394

I would also like to reiterate that this is an open source module. Everyone is allowed and encouraged to submit fixes, and/or new features. In this case, some forum user (@Cassim) actually wrote they they are working on a fix for this. I've not seen the PR yet, hopefully they will submit it soon.

You assumption is not correct 🙂

https://github.com/thirtybees/niara/blob/15e5338e628fca184a339d6cde66c961bfeb8169/modules/homefeatured/homefeatured.tpl#L4

Very nice, thank you. I believe the reason why this functionality was disabled was because it's not possible to have downloadable products per combination, which is something that a lot of people would expect. For example, if you sell modules, it is reasonable to expect that there could be different zip files for attribute platform (values thirtybees / prestashop 1.6 / prestashop 1.7). But even with this limit, it's definitely useful to have combinations for virtual products. With that, you can sell modules with different level of support, for example. I'll test your changes and merge them shortly

It make sense in B2B mode. Not so much in B2C

Actually, when you generate invoice, and no payments are recorded yet, system will create new payment record. https://github.com/thirtybees/thirtybees/blob/8b522e19ccaadd1ba6570d5d853628bd7f471ed8/classes/order/Order.php#L1590 There is a comment in code: Since an invoice always requires an existing order payment, we are going to add one Looks like thirty bees does not support unpaid invoices??? Anyway, if you modify the order after the payment is recorded, you should record additional payment (possibly negative) All payments will be displayed on invoice, making it match

I can't reproduce this behaviour. The system defaults to reduced price, but still accepts custom unit price. Even if I then change quantity, it works as expected. Do you have override for AdminCartController SpecificPrice Cart ??

I don't really know what you are talking about. Could you please describe your set up, what is expected and what is actual behaviour of the system?

That's a strange condition. I believe we should remove this, there's no reason to not support 'free gifts' from back office

It's a actually a bug that you don't have these images 🙂 Compare result (with and without) After installation, these images actually exists. But over the time they are lost, which is a bug https://github.com/thirtybees/thirtybees/issues/1503

Most select queries should work. If not, please file issue on github. Recently, we have fixed some issues in this area, so it's best if you could update to bleeding edge and test there.

This curl command fails: curl -H"Accept-Encoding: gzip" "https://instruments.co.za/attachment?id_attachment=155" --output file.zip Which means your server has some input/output compressing issues. Check mod_deflate configuration

This does not look like an application issue, most likely server configuration issue. It's quite funny, actually. The attachment can be downloaded using 'curl' command without problem: curl https://instruments.co.za/attachment\?id_attachment\=155 --output file.zip However, when opened in browser, 500 error code is returned. There must be some very clever and useful and idiotic security settings enabled on your server. Ask your hosting provider.