datakick

Yes, I was thinking about similar solution. It does not even have to be integrated with payment solutions, but vatmodule could do that automatically after order has been created. If the order contains address with VAT# that is not validated yet (validation failed during checkout), vatmodule would set the order status to 'Awaiting VAT Number validation'. Merchants could manually verify the vat number, or the module could use some cron job and try to validate against VIES webservice. If the validation fails, the status would once again be switched, this time to 'VAT Number validation failed' status, and merchants would have to contact customer and ask for valid vat#, or for additional payment, or cancel order and refund money. The important thing is that the invoice should not be generated before the vat# has been validated.

Thirty bees vatnumber module can do automatic vat number check using VIES webservice. Unfortunately, VIES webservice is very unreliable. It very often returns error messages like TIMOUT or SERVICE_UNAVAILABLE. When that happen during checkout the order process is blocked. Customers are unable to complete the order, and leave the site. Not nice. For that reason, I disabled automatic check. But that brings other problems. Customers from other EU states sometimes enter invalid vat numbers (or valid vat number that is not eligible for cross-border transaction). System accept these invalid VAT numbers, and creates order without tax, and customers pay less. I will detect this situation later, but it's too late. Payment is already made, and goods are delivered (I sell virtual products, so there is no delay). I can ask the customer to pay the VAT. Sometimes they do, sometimes they ignore me. If that happen, then I have to pay the tax myself. In any case, there is a need to modify or issue a new invoice... it's a lot of hassle. How do you do that?

You can do this in javascript. Use page onload event, get url parameter from url, and put it into dom element with some ID.

We just released new version of module that fixes this api change issue. Please test. update module version go to https://dashboard.stripe.com/developers and upgrade your API version to latest

They should not be in sitemap: https://github.com/thirtybees/sitemap/blob/c1ade8ced29c953c5dd2e19d992cbcf437628066/sitemap.php#L697 Sitemap shows only products that match both these criteria: active = 1 AND visibility != 'none'

That's true, and it's terrifying. We will "fix" this issue

If you don't have access to back office, and you don't even know what email address was used for administration account, then you need to use FTP and upload unlock php script to your store. You should have some access to your hosting provider control panel. If you don't know access credentials, contact them, and ask them to provide one. Using control panel you should be able to set up FTP access. It might even be possible to directly upload files using web interface. Script to reset passwords for all employees is here: File to download: reset-admin.php Content: <?php include_once __DIR__ . '/config/config.inc.php'; header("Content-Type: text/plain"); $employees = new PrestaShopCollection('Employee'); /** @var Employee $employee */ foreach ($employees as $employee) { $newPassword = Tools::passwdGen(8); $employee->passwd = Tools::hash($newPassword); echo $employee->email . " = " . $newPassword . "\n"; $employee->save(); } Upload this script into root directory of your thirty bees installation under file name reset-admin.php And then visit your shop www.domain.com/reset-admin.php The script will change passwords for all employees, and displays the new passwords on the screen. Very dirty and unsafe 🙂 After you do that, delete the script from your store!!!!

What kind of access you do have? FTP/SSH/MySQL ?

If feature and feature value already exists in database, you can associate it with product by calling $product->addFeaturesToDB($id_feature, $id_feature_value) To dissociate product from all feature values, call $product->deleteFeatures();

That's weird error, I've never seen it before. Is this clean installation? Did you create some custom fields in module back office?

Let's blame it on CORS then 🙂 If you are unable to update to 1.4, you can applie these lines (warning PHP7 syntax used - I know you are working on some PHP5.6 servers, for some reason) https://github.com/thirtybees/thirtybees/blob/81dd5d911a086164146bafc3bf650694786d9a56/controllers/front/TriggerController.php#L38-L44

What tb version are you using? In 1.3, this issue was caused by CORS preflight requests. Not a critical issue, because trigger was executed during preflight request. Fixed anyway.

It's a synthetic event to trigger scheduler. To run scheduled and deferred tasks. In ideal deployment, this would not be needed, because scheduler events would be triggered by cron or external process. That's not realistic for small shops, so it's emulated using this synthetic events. Tell me you have never wrote a test without telling me you have never wrote a test.

As I wrote before -- combinations for virtual products are allowed in bleeding edge (with the limitation of per-product downloadable file). If you are ok with this, you can simply update your store to bleeding edge using core updater, and use this functionality right away. Or manually apply the fix https://github.com/thirtybees/thirtybees/commit/c6e3694becb6f9b8aa8256d3d662e275ce19d179

Sure, go for it. You need to change database schema to support saving more than one files per product by removing unique key constraint and introducing new join table between product_download and combination table rewrite virtual product tab view - display list of files, support entry form for new items, and edit form for modification of existing files modify admin controller and implement saving of data passed from view to (modified) database tables modify object model for Product class and fix deletion of associated product downloads. Currently we delete only one file, we need to delete all of theme modify csv import to support importing with multiple downloadable products extend GetFile controller to support multiple files per order line. For backwards compatibility reasons, you should implement new view to select file to download (if combination id is not sent) modify email template to send multiple downloadable files modify theme templates to display multiple downloadable files review all usage of ProductDownload class in core to ensure nothing was forgotten do this all in a way that's backwards compatible and doesn't break anything. Note that changes to core should work on third party themes (tricky one) create Pull Request of you change so others can benefit from it as well There are a lot of requests for enhancements. Some of them have higher priority than others. As always, I like to remind that this is open source project, and contributions are welcome. You can ask for new feature, but that is definitely not a guarantee that somebody will work on it.

Tracked under issues https://github.com/thirtybees/thirtybees/issues/1642 https://github.com/thirtybees/thirtybees/issues/1643

In 1.5 combinations for virtual products will be possible, @e-com submitted the PR for that recently. However, downloadable files will be still be possible on product level only -- all combinations will share the same file. It's better, but still not perfect

Lol, that's funny. As I already replied via store contact form - we are happy to make the modification. Because we are not familiar with this module, it will probably take us much more time than it the module developer.

I have reproduced this issue. https://github.com/thirtybees/thirtybees/issues/1640

I'm looking forward to test this one

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.