DRMasterChief

Leider habe ich noch keine Lösung gefunden, einen Teil der Artikelbeschreibung (Tab more Info) mit in den Warenkorb zu bringen. Das einfachte wäre es ja, die ersten xx Zeichen der Beschreibung einfach unterhalb jeden Produkts im Warenkorb anzuzeigen, schon wären wir rechtssicher. Eigenschaften wie Farbe, Größe usw. werden ja sowieso noch dazu angezeigt.

You talk about problems with a payment service and disputed orders and so on? Good point, but i am not sure with the GDPR, which says that customer must not forced to accept anything, they just have to be informed. The acceptance is then automatically given when customer finish the order.

@lesley i know it sounds crazy, but it is. The law says, that the terms and conditions of the online merchant will then become part of the contract with the customer if the customer has been made aware of them by an explicit and explicit reference to the contract and when he was able to take note of the terms and conditions under reasonable circumstances. It is not necessary that the customer expressly agrees to the terms and conditions by a tickbox. This is the regulation for the checkout (here in Germany) and a lot of newer judges go the way that no tickbox would be better. Therefore, it could be better when we clearly indicate our terms and conditions and provide them to customers with the text content of the terms and conditions, for example, by linking the term "terms and conditions" in the checkout. The same applies to the privacy policy and the cancellation policy as well as other, similar information. In each case, it is not required by law that the customer expressly confirms the knowledge of this information. We just have to declare it with an link at the appropriate place. And this is the recommended thing for GDPR (a lot of lawyers recommend definitely NO TICKBOX FOR GDPR). I am afraid we have to see what will come in the next months. My question was if this would be possible as a choice in the module in BO? So everyone can decide if he will use a tickbox or not. @mdekker yes this is also recommended, but it must not be directly below the sign-in for newsletter (but hey... why not). I know this is maybe also a weird information, but in Germany (with the strict rules) we have not discussed it until yet that the sign-out has to be that public. It has to be in each newsletter-mail and in customer account, if the customer has one. And there should be the hint for unsubscr. near the sign-in, as i asked here: https://forum.thirtybees.com/topic/1651/hint-in-newsletter-block-for-revoke-at-any-time-gdpr

Would it be possible to remove the tickbox - but leave the text- from - Block customer privacy (module) - checkout last step (i agree to terms and conditons....) because customers must not be forced to tick any of these. They just have to read it. This is why the text (with link) should be there, but no tickbox. Would this be possible with the tb GDPR module?

Here is my solution: i have added in /theme/modules/blocknewsletter/blocknewsletter.tpl this here (place it where you like): {l s='here is my text. its a wonderful day. ' mod='blocknewsletter'} Works with my Theme. And you can translate this (if you have more languages) in the translations for modules - great :)

Thank you for your input about his. I have found https://developers.google.com/fonts/faq#whatdoesusingthegooglefontsapimeanfortheprivacyofmy_users which sometimes is good and sometimes not.... damn. but thats an fact from the Github discussion: .....For example collecting and processing the user's IP without the user's consent is against the GDPR. If the user does not consent then it doesn't matter how the data is collected/processed/transferred, it's still against the law...... more about this is in Recital 49 EU GDPR

Hello, when a Google font is loaded directly from the Google server in the US, your IP address will be sent to this server. Advocates and IT-consultants have concerns that Google may store this data internally (and maybe use it not or later to track visitors or to create profiles). Would it be possible with TB store to load the webfonts from the local server the shop is installed? Should not that much effort and another security thing to be ok with GDPR.

Hi, as part of the GDPR handling, I came across the fact that a 3rd-party shop module loads Google web fonts (and i think also the original Theme does so). That seems to be a problem and has to be noted in the privacy policy, according to law. I also found some detailed information in German (https://www.7media.de/wp-coaching/dsgvo-neue-datenschutz-anforderungen/) This report is just about it, it's about the reloading of webfonts with GDPR and that this reloading definitely should not be done anymore with 25. May. Everyone can check for themselves, if the design or Theme of the shop itself uses Google fonts and usually then they are reloaded from the Google servers. You can search for something like this in the source code: //ajax.googleapis.com / . If I understand the Google license correctly, you can use the fonts offered by Google (https://fonts.google.com/) for free and also install them locally. But these fonts are only available in .tff , and conversion to another file format like , .eot, .svg etc. seems to be a license violation. In many themes (also in the original) there is a script that loads the webfonts. How do you deal with it now? I'm a bit baffled here again and would like to try to load the Google Webfonts not from extern source, but only from local server. How can we do this?

C'mon CoffeeGuy

@ukclearance thanks for sharing, contentbox also looks interesting for us. Do you have an example from your shop, just to see it? Thank you

you are right, the AEUC is useless in this point and does not meet the problem. I thought about the Service already, how long does this take? The information should get from the setting from the product or from the cart (which uses the same availibily settings from the product site as shown in the 2nd picture). I can implement it in the mail template, but i dont know how to configure where it has to come from.

Ahh no, you mean in the AEUC module the first two points?! Delivery time (in stock) and Delivery time (out of stock) But this is not suitable for the correct information which has to be sent to the customer. I need the specific availability for each product, and it can be a lot of more than just these two points from above. We have items with 1-2 days, 4-7 days, 10 days and non available items. We just need the possibility to get this data from each product configuration, which we set in the product configuration. Please find 2 pictures here, hopefully now it is clear :)

Hi, yes absolutely, everything would be an option :) My mails/de/orderconf.html and mails/de/orderconf.txt are already changed to my needs, so it is no problem to change them. But i dont know where the information has to come from.... i read about that these has to come from payment modules or something like that. Could this be true? Thank you

Hi guys, any help with this? plz

think its hard to say. 1.0.4 is a RC - with all the problems and benefits of a RC :) 1.0.3 is stable and you can work with. I think there will be also an easy upgrade from 1.0.3 to 1.0.4 when time is come.

@nickon - i absolutely agree with this. I really can not understand why some people ask for new versions every month, or an "new" 1.0.4 and so on.... TB has so many benefits compared to PS and most of the shops can use it out of the box, i am wrong? So why do you bother the team about the new version? I really think they fix a lot of things in the background and a new version is coming when time is ok for it. In the meantime you can use 1.0.3 or use it not and stay with PS, it´s your decision. Honestly i would also like to ask if some more things from the community here can be implemented. There are a lot of asks and ideas here and the thing is, that the team has to discern them and make the best with this.

Hi, we will go live with the TB shop in the next time. Unfortunately we have expected a problem: In the order_conf mail which is sent to the customer, there is no "delivery time" given. It is necessary by law to give the delivery time for each item in this e-mail to the customer. The delivery time has to be the same as given in the shop for each item near the price. I am not sure if this problem came from the core of TB, or theme or module "advancedeucompliance" or from all of them when they are working together. I think -usually- the delivery time should appear in the order_conf mail, but it doesnt? Or is this not supported by TB shopsystem by default? Do you know where we can have a look at or what to change ? (attached a picture how it should look, not a picture from our shop, only for example) thank you

So, mails werden nun richtig verschickt, es war der altbekannte Bug aus PS daß der Ordner /mails auch in den Templates geändert werden muss und die Sprachen (lang.php) jeweils reinkopiert werden müssen. Noch eine Frage aber: in der order_conf wird ja keine Lieferzeit bei jedem Produkt angezeigt, das muss aber rechtlich sein. Hat dazu jemand schon eine Lösung? danke

Hab´s nun nicht mehr versucht, da ja auch viele andere Dinge leider nicht übertragen werden - anderes dafür wird bei jedem Shopabgleich überschrieben. So lässt sich nicht arbeiten. Wir werden nun nur die Bestellungen in die Wawi holen, den Rest erledigen wir im BO vom Shop.

Hello, we are not using TB until now (still testing and arranging everything), but we have this also with our shopsoftware which we are using at the moment. Sometimes the customers send an email to us and ....blabla password not working.... or something like that. I also think that it is 99% at the customers. We change the password and send to customers manually and it works..... hm. But we also know that there are a lot of e-mail services which are not accepting mails from the shop or move them to spamfolder or something like that. GMX, Yahoo and especially Hotmail are horrible !!

Hello, this would be horrific (* sorry *) Some customers use e-mail-addresses like myname.1 (e.g. at Gmail service) and Gmail (and other e-mail-services) do not distinguish between an e-mail-address wich is myname.1 and myname1 (this is fact). But most of the users dont know about this and both e-mail-addresses can be different people. You can read about that fact in Gmail usage description. And i also tried this for my own with such a similar e-mail-address. So this means, when a customer use such an e-mail-address, it can be also seen by the other Gmail user as it is delivered in his mailbox when he registered this before at Gmail (or also some other services). Then a totally foreign person can see all the order details, address, maybe bank account or such things. This is very strange and does not comply to any privacy policy or law or GDPR. Beware of this.

@kryotic said in Floating/Fixed Top Bar: .... Will be checking out Woo and PS 1.7. Never run a shop on a CMS - too much security issues imo. And hey... PS 1.7 seriously ? Just play around a bit with thirtybees and you will see the benefits.

Yep, i think it will just use this {l s='Blabla here\'s my info'} Is there a possibility to translate this into the 2 languages? Or what about my idea with an mini-module for e.g. $5, would TB be interested in offering something like that?

Yes i can include this easily in the blocknewsletter.tpl after the and before the {hook h="displayBlockNewsletterBottom" from='blocknewsletter'} but the icon is very small and i am not sure if it is legal to manage this with an hint icon ?! The 2nd problem is to translate this into my other language (i have english and german). And a 3rd problem: this solution does not work at mobile´s like tablet or smartphone (no mouse-over...) thank you

ufff... where to add this?? I am not a developer, but a big thank you for your fast reply. Maybe we can work out a solution here?