Traumflug

Today we have to think that the mobile version is almost more important than the desktop version No doubt about the importance of mobile devices. Nevertheless, (mobile) device detection is a technology which is pretty much abandoned already. The modern replacement is coined "Responsive Design", which means: Don't try to detect the device, deliver the same HTML/CSS/JS to every device. Use conditional CSS, which changes appearance based on screen width. Much better than device detection, think about users turning their phone from portrait to landscape, drastically changing screen geometry. As appropriate, fluid elements. Like sizing images not in pixels, but in available space (e.g. 'width: 100%;'). With such a responsive design, logo is usually the same for all devices and gets scaled as needed in the browser.

Where's the problem? To me this looks perfectly fine (in Firefox):

Protokollierung von Einwilligungen Ist schon da. Dadurch, dass der entsprechende Cookie existiert, ist das "Protokoll" vorhanden. Beim Kontaktforumlar dadurch, dass der Besucher was schickt. Letzteres gilt ja dann auch nur für dieses eine Mal. “Passwort vergessen” Funktion mit neuem Ablauf Das im Shop gespeicherte Passwort ist nicht umkehrbar, ohne das Original also wertlos. Das Original kennt jedoch nur der Kunde. Logging der Admin-Aktionen Gibt's irgendwo in den Tiefen des Backoffice. Hat aber mit der DSGVO nichts zu tun, denn Kunden können keine Admin-Funktionen ausführen. Versionierung für Rechtstexte im Content Manager Hat mit der DSGVO auch nichts zu tun. Der Rest ... naja, die Leute streiten sich ja immer noch darüber, was es tatsächlich braucht. Manche stellen sich ja mehr oder weniger auf den Standpunkt, dass sie die Daten nur im Sinne des Kunden verarbeiten, sich also gar nichts ändern muss. Auch wenn ich da ganz anderer Meinung bin.

1 CMS seite mit Rechten erklärung für unlogierte gäste, und 1x cms categorie für “My Account” für registrierte kunden. Beim kontaktform wird ein text für gäste gezeigt aber nicht für registrierte kunden. Beim registrierten kunden kann man auch kein email ändern am köntaktformular, aus versehen oder nicht. Gespert Klingt nach einer guten Lösung. Klingt auch danach, dass man das mit der Distribution ausliefern könnte. Dann wären Neueinsteiger schon mal wesentlich näher an einem rechtssicheren Shop. Gute Idee? Würdest Du die Lösungen zur Verfügung stellen?

When we are talking about GDPR, we should stick to the text of GDPR law. You can do that in a forum for lawyers. Laws always have to be interpreted and if you think you can do this interpretation better than actual lawyers, that's pretty bold. For my part I'll stick to how independent/neutral lawyers interpret this law. Especially if such an interpretation follows simple logic more than some personal interpretation. Above I've shown you how persistent cookies can be used to track visitors, you ignore this totally.

Um Min. 44:30 erklärt Jan Phillip Albrecht, dass es "viel zu einfach ist, für Abmahnungen Gebühren zu kassieren". Um 1:08:40 wiederholt er diese Ansicht noch mal. Das stimmt doch mal vorsichtig zuversichtlich, dass diese kostenpflichtigen Abmahnungen in absehbarer Zeit verschwinden. Denn wo immer man die Diskussion um die DSGVO beobachtet, es geht mehr um die Sorge vor Abmahnungen als um das eigentliche Gesetz.

I don’t care about that. Obviously. If you don't trust EC lawyers you probably trust my word much less, so its moot to continue this discussion.

@smarterweb, some quick research found that PHP handles file modes differently on Windows vs. a Unix-type OS. Which kind of OS is your server running?

@datakick said in PGRD Compliancy Module: Basically, any collected information that can be used to identify natural person is subject to GDPR. That's true, and that's exactly the reason why any such collection needs user consent. Simple message: don't collect.

@datakick said in PGRD Compliancy Module: @traumflug said in PGRD Compliancy Module: Persistent cookies are considered to be personal data for their sheer existence. It doesn’t matter what’s inside. This is nonsense. Show me where, in the GDPR text, is this written. It's written here: http://ec.europa.eu/ipg/basics/legal/cookies/indexen.htm#section2 The ePrivacy directive [...] requires prior informed consent for storage or for access to information stored on a user's terminal equipment. In other words, you must ask users if they agree to most cookies and similar technologies (e.g. web beacons, Flash cookies, etc.) before the site starts to use them. And then a couple of exemptions are noted. Common to all those exemptions: they're not persistent. The reason why a persistent cookie is personal information regardless of its content is simple: it's stored on the user's PC and sent on subsequent visits. In your example this means, if the server finds a cookie which sets the theme, it sees "Hey, this user was here earlier". If your theme doesn't use such cookies maliciously its entirely fine, still you have to ask for consent. Or use session cookies.

Great thing! And yes, one of the long standing enhancement requests: https://github.com/thirtybees/thirtybees/issues/397

Do you have non-standard modules installed? Causes for trouble are pretty often found there. But this also gives the opportunity to narrow down that trouble by disabling all the non-thirty-bees modules, then to turn them back on one by one, while exercising what went wrong before.

What?! And what evidences can we have in case of abuse [without recorder IP addresses] ? Regarding Apache/Nginx logs and such stuff, recording them for a "limited persistent duration" is explicitly allowed. See http://ec.europa.eu/ipg/basics/legal/cookies/indexen.htm#section2 , 5th bullet point. Which means, just rotating logs fast enough should bring compliance. If IP addresses disappear from logs after a week it should be compliant with GDPR. And to be honest, one doesn't really need logs older than a week for fighting abuse, right?

Not to upset your lawyers, but not every lawyer understands how cookies work. Persistent cookies are considered to be personal data for their sheer existence. It doesn't matter what's inside. Solution: either make it a session cookie, so the browser deletes it after the session, or ask the user for permission to store this cookie. Maybe you do this already, which is why your lawyers agree.

No FB, no newsletter, no OPT-in. Nothing. Just basic shop. Excellent, congratulations! Drawback: too simple, no module needed: https://forum.thirtybees.com/topic/1796/gdpr-panic-meets-rational-thinking

As we all know, goal of the GDPR is to reduce storage of personal data, especially for extended periods of time. Simple and obvious (but rational) solution is to remove such storage from the software. Done for DokuWiki yesterday, made a nice post, along with a HowTo, providing patches: DokuWiki Issue Comment What happened? Well, Extensive explanations why every single piece line of code has to stay the way it is and why months of head scratching about legal fine print is much more appropriate than applying a patch and solving the underlying problem. The issue gets closed and locked. Without changing the software, of course. Out of sight, out of mind. With this kind of experience I wonder whether it makes sense to solve the underlying problem for thirty bees. In the weeks of discussions here and hundreds of posts, only one link came along with what I think is the right direction: http://ec.europa.eu/ipg/basics/legal/cookies/indexen.htm#section2 Thanks to the person posting it, very helpful. It boils down to "Take law makers by their word". They do want e-commerce (and other types of websites) to be successful. But what should thirty bees do? Let people stick in their panic**? Provide some important looking band aid? Actually solve the problem and risk that nobody believes in such a solution? I don't want merchants using thirty bees to get upset in a fashion similar to the DokuWiki guys. I'm not sure. Opinions welcome. **) I hope I didn't upset people by just telling about the behavior I think I've detected.

Let's track this on Github: https://github.com/thirtybees/thirtybees/issues/522

Unexpected token < in JSON at position 0 This means some Ajax callback delivers HTML instead of JSON. Usually an error page. Last time this was seen it was solved by re-uploading all the distribution files, deleting the database and starting over. If this doesn't help, more information is needed. If you don't feel like entering Firefox' developer toolbox for looking up what that non-JSON is, I'd ask for web access, so I can attempt an install myself.

No votes? Also no complaints, so forwarded this to the 1.0.x branch to get it into the next release.

Ich war früher aush sehr angetahn für Kontaktformular Checkbox. Aber jetzt nich mehr. Weil da gibt es auch mein handynummer und meine adresse auf meine seite. Eine Checkbox am Kontaktformular? Sehe ich keinen Grund für. Wenn mir jemand eine Frage schickt und die Email-Adresse beilegt ist es doch klar, dass er damit eine Einwilligung für eine Antwort gibt. Sonst macht eine Frage ja keinen Sinn. Bestenfalls ein kleiner Text, der die Leute nochmal an diesen Zusammenhang erinnert. Wenn man die eigene Telefonnummer angibt sollte das auch kein Problem sein. Ist ja nicht die Nummer des Kunden/Besuchers.

Das update auf 1.0.4 ist auch "ganz normal". In dem Sinn, dass man den gleichen Weg beschreitet wie jemand, der mit thirty bees angefangen hat. Dass das ein bisschen umständlich ist, ist eben im Moment so. Ist ja gerade in Arbeit.

I read some article that css grid is better than bootstrap, available natively in the browser, cleaner html, more flexibility, and it will be the future of web layouting. I looked into this article and it basically recommends stepping back to having no formatting in HTML. Just like it was recommended before Bootstrap arrived. All this with the knowledge that modern browsers ( < 1 year old) now support reasonable formatting. While this is certainly a way to consider, it also requires formatting rules for every situation ever happening. Less HTML, much more CSS. Unless you have a very standardized layout like e.g. Wikipedia. My $0.02.

Die Erfahrung zeigt, dass es ohne harte Einschnitte nicht geht. Das Gesetz ist ja inzwischen 2 Jahre alt, trotzdem klammert sich so ziemlich jede Software and den vorherigen Gewohnheiten fest. So ist das eben mit den Menschen.

Wie sieht denn das Upgrade aus? Es gibt ein Modul in Version 1.0.0 https://github.com/thirtybees/psonesixmigrator/releases/tag/1.0.0 Bisher konnte ich aber nicht viel darüber erfahren außer das es seit dem 26 Apr 2017 nicht mehr geupdatet wurde. Läuft es Stabil? Ja, das läuft stabil. Dass es manchmal trotzdem Probleme gibt liegt in der Regel an einzelnen Modulen. Prinzipiell funktionieren zwar alle Module für PS 1.6.1.x auch mit thirty bees, doch der eine oder andere Entwickler hat dann eben doch irgendwelche dirty tricks eingebaut. Ein "beliebtes" Problem sind auch Module für einfachere URLs. Bei PS ist da ja immer eine Referenznummer vorne dran. Dazu gibt es Module, die diese Nummer verschwinden lassen. In thirty bees sind diese Module einfach überflüssig, denn diese Funktionalität ist fest eingebaut. Also das Module einfach entfernen, dann geht's wieder. Will man einen schon laufenden Shop migrieren, ist es eine gute Idee, erst mal eine Kopie zu migrieren um zu sehen, wie gut das funktioniert.

Dezeit gibet es auch kein modul für direkt migration von PS 1.6.xx zum TB 1.0.4, aber ich denke das soll sich auch bald ändern. Ähm, das bleibt eher so. Ist ja auch kein Problem, denn wenn man zu 1.0.1 migriert hat, kann man ganz normale thirty bees Updates machen.