Yabber

Check your tax configuration in Localization -> Tax Rules Maybe you have deleted tax for some provinces. Screenshot below shows the default tax configuration for Canada imported by thirtybees.

In all themes for Prestashop (both free and paid) there are hundreds of inconsistencies with the requirements of WCAG 2.2 AA https://www.w3.org/TR/WCAG22/. Also on Prestashop there is not a single store that meets the requirements of the 2019/882 directive, i.e. the European Accessibility Act. Both themes included in thirtybees also do not meet the requirements of WCAG 2.2 AA. With this validator https://wave.webaim.org/ you can check your store pages.

It looks like some errors in the code of your own modified email templates in the /themes/_YOUR_THEME_/mails/en/ directory. You can check this by copying templates with a name starting with order_conf from the /mails/en/ directory to the /themes/_YOUR_THEME_/mails/en/ directory. Thirtybees update process does not update email templates from the /themes/_YOUR_THEME_/mails/ directory.

By default, ThirtyBees does not have the ability to manage product quantities with decimal parts. There are modules sold for Prestashop that supposedly add such functionality, but these modules use hundreds of core method overrides and only introduce a huge of errors into the store engine. Therefore, a better solution is to switch to smaller units of measurement in product quantities. For example, instead of a kilogram, it is a decagram or gram, instead of a liter, it is a milliliter, etc.

@datakick I think the only reason for the incomplete update process of thirtybees is the prestashop modules using overrides. Maybe "Core Updater" should disable all overrides before starting the update process?

There is no need to do anything about it. If you enable “Smart cache for CSS”, these errors will disappear.

Adapting the prestashop 1.6 theme to thirtybees with PHP 8.3 is a very simple job. For example, the original default-bootstrap template has only a few errors, including two critical errors in the “blockcart” module templates. On the other hand, the modules sold on prestashop addons are a different topic. It can be said that all modules sold there have some major or minor errors. And it doesn't matter the PHP version. And the Vietnamese and Indian modules sold together with the themes are the ones with millions of bugs 🙂

Such an approach will result in a store with no integration with any external services, and the only payment method in the store will be only traditional bank transfer. Currently written PHP libraries most often require a minimum of PHP 8+, and no one writes software for such ancient PHP versions as 4, 5 or 7.

The 'mailalerts' module passes the {message} variable to the template email 'new_order' sent to the store admin. Check in this email template if you have such a variable.

Looking at your store https://bountyhuntertoys.com/store/ it is clear to me that absolutely NOTHING in this store has been configured. Starting from such basics as enabling friendly URLs or anti-spam protection of the contact form. Also switching to a paid SaaS might be a good option, pay $300 a month, then at least the basic configuration will be done for you by shopify support. As for migration, exporting data from thirtybees to CSV will not help you at all. You need to be very knowledgeable about the database structure of both applications to properly map the data. Also, it is best to pay a few hundred dollars and have the migration done by a company that will do it properly. For example, Cart2Cart: https://www.shopping-cart-migration.com/provided-services/data-migration-service-packages And such a note that the migration does not transfer customer passwords, also all your customers will have to reactivate their accounts.

@DRMasterChief In blockcart.tpl template, change: {assign var='free_ship' value=count($cart->getDeliveryAddressesWithoutCarriers(true, $errors))} to: {assign var='free_ship' value=count($cart->getDeliveryAddressesWithoutCarriers(true))}

@the.rampage.rado The order of attribute combinations in the product configuration has no meaning. If I change the “Position” in the attribute values then the order on the store front changes identically.

I checked on TB 1.6 and sorting attribute values in BO by “Position” also works correctly on the front end on the product page.

@DRMasterChief The code you provided in the first post is about features, not attachments. And can't you use this futures functionality to present this additional product data? Instead of making some weird modifications to the attachments functionality.

Is it possible that we configure a different server and SMTP account in the module than we have in the “Mail via PHPmailer” module and the module uses those settings to send its emails?