30knees

Can't find any error.log file, unfortunately. :(

That's the only error I got, unfortunately. It shows up on the page: Localization>Translations after using the copy from theme A to theme B function.

It is on, but I don't get an error message.

Hi, I tried to copy translations from the community theme to the theme I'm using through the backend, but I got the following error: Table 'sjlkjsll.tbtbattachment_lang' doesn't exist SELECT * FROM `tb_tb_attachment_lang` WHERE (`id_lang` = 1) Can someone else confirm this bug or is it something with my shop?

Is there a way to give eg Shipping costs a fixed tax rate regardless of the shopping cart contents until the bugs have been fixed? Ideally, the carrier prices would then always be incl. taxes of X%.

Here's a feature suggestion you can vote on: https://thirtybees.com/suggestions/filter-delivery-slips-generation-by-order-status/ Currently, the bulk delivery slip generator works only by dates. I think being able to filter according to order status would be a big improvement - at least for our workflow. I'd use the different PDF files generated for different recipients, and I could filter nicely according to the order status.

@mdekker I think generally you're right, though in Germany the legal opinion is divided whether displaying the shipping costs directly before the "Buy now" step is enough or whether you need to show them also before. However, something else to take into consideration is that the link "Shipping excluded" (which should be changed to "plus shipping") next to the price on the product page leads to the shipping cost overview page. I don't think listing net shipping costs and explaining that the total will depend on a proportionate calculation makes sense.

Bug report filed: https://github.com/thirtybees/thirtybees/issues/326

Thanks, @Occam! That means that if I have "Proportionate tax for shipping and wrapping" enabled the shipping rate will change dependent on the contents of the cart? Is there any way to fix this? That's really a big bug - we need to tell our customers in advance what the shipping rate is, but we can't if it's dynamic.

@mdekker Ah, then the module probably doesn't have that hook. Is it an easy fix, just insert a piece of code somewhere in the module?

Nobody?

Awesome, that was it! Thanks so much. :)

Two questions: German 1.0.0 on crowdin is basically done. How can we get all strings from 1.0.0 that are identical in the later versions into the later versions and approved, without having to approve each string individually? How can I get the translations from crowdin into the shop in one swoop?

I'm trying to properly understand the translation system in tb/PS. Please confirm or correct me in the following: Front office translations: Only theme translation. Back office translations: Only core translations, theme independent. Error message translations: Only core translations, theme independent. Field name translations: Only core translations, theme independent. Installed modules translations: Core and theme translations. PDF translations: Core and theme translations. Email templates translation: Core and theme translations. The structure is mirrored in the file directory of tb. If I want to translate directly in the files instead of through the backend translation tool, I can do so. Theme or core? 1-4 only have either theme or core, so choosing which to translate is easy. But 5-7 have files both in the core and in the theme. My understanding (coming from here) is that the core is the default. If I select a theme, all translations from the core will be copied to the theme. So module X in core becomes module X in theme. Updates Updates from tb will overwrite the core. If I'd like customised translations, I should make edits in the theme.

I'd like to use a module called Bitcoin HD. It's a payment module that permits customers to pay in Bitcoin. It worked fine in PrestaShop 1.6. With tb 1.0.2 I'm getting the following error. To me, it looks like Bitcoin as a currency isn't defined. The currency is in the backend in Localisation>Currencies. Does anybody have an idea how to fix this? ``` BTC at line 51 in file vendor/commerceguys/intl/src/Currency/CurrencyRepository.php public function get($currencyCode, $locale = null, $fallbackLocale = null) { $locale = $this->resolveLocale($locale, $fallbackLocale); $definitions = $this->loadDefinitions($locale); if (!isset($definitions[$currencyCode])) { throw new UnknownCurrencyException($currencyCode); } return $this->createCurrencyFromDefinition($currencyCode, $definitions[$currencyCode], $locale); } CommerceGuysIntlCurrencyCurrencyRepository->get - [line 869 - classes/Tools.php] - [1 Arguments] ToolsCore::displayPrice - [line 952 - modules/bitcoinhd/bitcoinhd.php] - [2 Arguments] BitcoinHD->toBTC - [line 34 - modules/bitcoinhd/controllers/front/payment.php] - [1 Arguments] BitcoinHDPaymentModuleFrontController->initContent - [line 366 - classes/controller/Controller.php] ControllerCore->run - [line 743 - classes/Dispatcher.php] DispatcherCore->dispatch - [line 33 - index.php] ```

Would anyone like to participate in developing a refined checkout process? I'd need it to be compatible with the Advanced EU Compliance module. My idea would be: Ask for email address 2a. If customer is registered, ask for password and prepopulate the shipping and billing address 2b. If customer isn't registered, ask for shipping and billing address Ask what shipping method Ask what payment method Confirm purchase If customer wasn't registered, ask whether they'd like to create an account and let them set a password

In 1.0.2, some payment methods are not shown when I activate 'Advanced Checkout Page' in the Advanced EU Compliance module. The payment method, a third party module, is in the hook area 'displayPaymentEU'. Is there anything else I need to pay attention to so that the payment method shows?

There already is a PR with a very easy fix: https://github.com/thirtybees/thirtybees/commit/fff86f1cfb23b45daa531367eecc1f42bfe37ed3

Hi, Could someone else please check that when enabled the EU Advanced Compliance module takes the shipping price and adds VAT on top of it? This is surprising for me and I don't know whether it's intended or not. I would expect the module to take the shipping price entered at the carrier as gross, i.e. including taxes, and not net. What would you expect?

It depends on the jurisdiction, but for example in some countries you are legally obliged to keep all information that is necessary to understand a business transaction for X years. I would argue that this includes the “order” in the shop, which is why the customer’s request to delete their data is really only as outlined above.

@mdekker Lesley took a look and said he think the query might be broken and suggested reporting it as a bug. I've done so here: https://github.com/thirtybees/thirtybees/issues/321

I have carriers for all countries. In the community theme it also by default selects the standard carrier, which is assigned to a country. But I can't select any country in the drop down menu of the address field.

@MockoB is correct in so far that any data that we are not forced to keep legally or for which we have no real purpose must be deleted. @lesley It's not only for front end information. It regulates the whole data life cycle and also data processing activities that go on behind the scenes, so to speak. The legislation itself can be read here: http://eur-lex.europa.eu/legal-content/EN/TXT/?uri=CELEX%3A32016R0679

I have the same problem with the community theme. I'm guessing it's a setting somewhere, but I don't know where to look.

@MockoB This right is not absolute. Please re-read my post above. We don't even need a "Close my account" button. It's only a nice to have. Customers can always write the shop owner and the owner can then manually delete their account from the backend and check the option that the customer can re-register with the same email address. (Question: This doesn't delete all past orders, right?)