30knees

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?)

The right to be forgotten applies to any entity collecting and controlling data. Basically, the right says: Delete all data on me that you're not legally obliged to keep. If you think of Facebook and wanting to close down your account there, it makes sense. You don't want them to keep your photos and likes forever. With a shop, if you only collect the necessary information to process the order, it doesn't make that much sense. If you profile your customers, however, it does, because the customer will want the data/profile deleted. For us small shop owners and thirty bees, it basically boils down to the understandable wish of: I don't want to have a login at your shop anymore. It doesn't have anything to do with orders per se. However, what it does mean, and this applies to guest orders equally, is that after you are no longer legally obliged to keep the order data, eg for tax purposes, you must delete it. With a customer account you could argue that the data may be kept as long as the customer has an account, as the customer will have an interest in seeing their order history. But once the account has been deleted, or where it never existed because the orders were places as guest orders, the data may *generally speaking) only be kept as long as you are legally obliged to keep it.

Would this permit the customer to re-register with the same email address? If so, that is indeed all that's needed. They shouldn't be able to see their past purchases, however.

Exactly. All the retention requirements remain unaffected. The only data that would get deleted when the customer clicks "Close my account" would be their login data. Their past purchases would remain in the system.

I think customers should have the ability to delete their account. This would mean that any past purchases made by the customer become guest purchases and that they customer can create a new account with the same email address going forward. For one, I think this is a basic sign of respect towards a customer. For another, it will reduce customer errands for merchants, as customers do have the right to have their account deleted. This right will be only become more acute with the upcoming EU General Data Protection Regulation.

Hi, We have the problem in our TB 1.0.2 standard multi-step checkout that there is no country to select in the address field, both when checking out as a guest or registering as a customer. We have countries activated and mapped to zones and zones to carriers. Does anyone have an idea why this might be and how to fix it?

@dynambee Are you still happy with Cloudways? And did you discover the answer to your question from the first post "Currently I am using PHP 7.0 and MySQL 5.6. Would there be an advantage to migrating to MariaDB 10? Any problems with using PHP 7.0?"?

Also, I can see that in both German and English it shows a different (higher) amount of points first, but then it switches to the correct amount in German and it shows the no reward message in English.

No, I have all cache turned off.

I'm using the module "Customer loyalty and rewards v2.0.0 - by thirty bees". In one language, German, the loyalty points are shown on the product page. In the other language, English, they aren't and the customer is shown "No reward points for this product." Does anyone have an idea why this could be and how to fix it?

Thanks! Though I just edited the title to include "affiliate program module", as that's what I'm mainly looking for. The module you linked to looks great, but it's much more than I need.

@mdekker I'm new to PS/TB and haven't tested it yet, but I remember that merchants complained about it. @lesley What are the main features missing, in your opinion?

Can anyone recommend an affiliate program module? Or is the built in one decent? Edited: Changed title and body of post to show I mean an affiliate program and not a customer referring customer module.