30knees

Also, why do the payment methods look (different logos) and why are they named differently depending on whether ‘Advanced Checkout Page’ in the Advanced EU Compliance module is activated? Shouldn't their names and logos be consistent throughout?

Hi all, Two questions: Is the PayPal Sandbox always US? I'm testing the module and the PayPal checkout page (where you log in to PayPal) is always US based, regardless of the billing address entered during the checkout. The PayPal checkout page should recognize the billing address and tailor the page accordingly. So if it's a German address, the PayPal checkout page should be in German. The PayPal checkout page has a thirty bees artisanal coffee and tea logo behind the PayPal iframe. Where can I change the logo?

@Occam Thanks, a good tip! So, it looks like the Bitcoin HD module was based on the "Pay by Check" module. I found this in it's file: ``` public function hookDisplayPaymentEU($params) { if (!$this->active || !$this->checkCurrency($params['cart']) || !$this->checkConfiguration()) { return; } $payment_options = array( 'cta_text' => $this->l('Pay by Check'), 'logo' => Media::getMediaPath(_PS_MODULE_DIR_ . $this->name . '/cheque.jpg'), 'action' => $this->context->link->getModuleLink($this->name, 'validation', array(), true) ); return $payment_options; } ``` And then I also noticed that the payment method "Pay by Check" is shown, even though I don't have it activated. It turns out the AEUC translation label for the module is "Pay by Check". I changed that now to "Pay by Bitcoin" and the payment method is shown now in AEUC as "Pay by Bitcoin". Do let me know if there is anything else I should do to clean the module up a bit.

Hi, I'm getting the following error when I try to finalise a purchase using this Bitcoin module. The orders are ultimately captured, however. Does anyone have an idea for a fix? Thank you [ThirtyBeesDatabaseException] Unknown column 'bitcoin_address' in 'field list' SELECT `bitcoin_address` FROM `tb_orders` WHERE `id_order` = '5' LIMIT 1 at line 797 in file classes/db/Db.php 792. if ($webserviceCall && $errno) { 793. $dbg = debug_backtrace(); 794. WebserviceRequest::getInstance()->setError(500, '[SQL Error] '.$this->getMsgError().'. From '.(isset($dbg[3]['class']) ? $dbg[3]['class'] : '').'->'.$dbg[3]['function'].'() Query was : '.$sql, 97); 795. } elseif (_PS_DEBUG_SQL_ && $errno && !defined('TB_INSTALLATION_IN_PROGRESS')) { 796. if ($sql) { 797. throw new PrestaShopDatabaseException($this->getMsgError().'<br /><br /><pre>'.$sql.'</pre>'); 798. } 799. 800. throw new PrestaShopDatabaseException($this->getMsgError()); 801. } 802. } DbCore->displayError - [line 460 - classes/db/Db.php] - [1 Arguments] DbCore->query - [line 710 - classes/db/Db.php] - [1 Arguments] DbCore->getRow - [line 740 - classes/db/Db.php] - [2 Arguments] DbCore->getValue - [line 741 - modules/bitcoinhd/bitcoinhd.php] - [1 Arguments] BitcoinHD->generateBitcoinAddress - [line 700 - modules/bitcoinhd/bitcoinhd.php] - [1 Arguments] BitcoinHD->hookActionGetExtraMailTemplateVars - [line 771 - classes/Hook.php] - [1 Arguments] HookCore::coreCallHook - [line 487 - classes/Hook.php] - [3 Arguments] HookCore::execWithoutCache - [line 280 - classes/Hook.php] - [7 Arguments] HookCore::exec - [line 389 - classes/Mail.php] - [4 Arguments] MailCore::Send - [line 510 - classes/order/OrderHistory.php] - [13 Arguments] OrderHistoryCore->sendEmail - [line 422 - classes/order/OrderHistory.php] - [2 Arguments] OrderHistoryCore->addWithemail - [line 949 - classes/module/PaymentModule.php] - [2 Arguments] PaymentModuleCore->validateOrder - [line 61 - modules/bitcoinhd/controllers/front/validation.php] - [9 Arguments] BitcoinHDValidationModuleFrontController->postProcess - [line 355 - classes/controller/Controller.php] ControllerCore->run - [line 743 - classes/Dispatcher.php] DispatcherCore->dispatch - [line 33 - index.php] ```

What's the status of the German translations on CrowdIn? @eleazar Is it just needing to approve now because you uploaded everything already?

Can anybody else reproduce this?

The module has the displayPaymentEU hook, so it looks like it is something else. Any ideas on how to figure out what it might be? It's only the Advanced AEUC checkout where the payment method isn't shown. It's shown on the standard AEUC checkout.

Strange: I have 1.0.2., but the file was still the old version. Any idea why this could be? However, updating didn't help. I still get the exact same error.

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?