 Welcome, everyone, to the session about leveraging contributed modules, best practices with EU cookie compliance module, web analytics tools like Google Analytics and Motomo. So I'm Nils. This is Ishtran behind me here. We've been working closely together for the last four years, and we have been involved in this experience together that we try to explain to you now. So I wanted to say, enjoy freshly baked Belgian specialty, the waffles. I hope you already had one because, sadly, they're out. So if you enjoyed it, good. Otherwise, please don't run away to get the last ones. So I want to set some expectations clearly for everyone. What is this not about this session? This session is not about what is GDPR. That can be found anywhere on the web. I would recommend to look at the European institution websites for that as well. The why of why do we need to be compliant? I think that's not something that I want to cover now. What is legal and what is not? That's also something we do not cover. And then specific GTM and Motomo configuration is also not something that we cover. But if you need help with that, just talk to us after the session, and we'll see how we can help you. So no guarantees. We are not lawyers. We don't look like lawyers, maybe. So we cannot give you any guarantees. So the difficulty here is that legislation is pretty vague. So it is up to interpretation. Slowly courts around Europe are actually getting more concrete with their cases. So please always check with your own legal department to be sure you're doing the right thing. So now what we'll be talking about is our experience, actually. How did we tackle this entire problem that started for us in 2019, and how we went through that, and how we got to a solution that we were comfortable with? So our experience. When we started out, when we first had the first GDPR definitions, we started looking internally like, what does this mean? What do we need to do? And we distilled some best practices from it, like some things that we definitely wanted to cover. And one of those was, for instance, like, OK, the possibility for the user to change the language, because we're from Belgium. We have a lot of multilingual sites. So it was a requirement that a user can actually see the cookie notification in their own language. Then also, we had different categories of tracking. You've probably all seen those now, which are very common, the statistical cookies, the different and necessary cookies. So that was also a requirement that we had. And then a very important one is that no tracking scripts should actually be loaded as long as no consent is given. That was one that we saw that many alternative solutions actually faulted against. So that was one of the important ones that we wanted to make sure that we had. And then configure how long the consent is kept, and also a way to force it again that people ask for it again. Then the last two are, basically, we want the consent form to look like the site. We don't want it to be a disjointed experience for the end user. We want them to feel comfortable when they see that dialogue and that we're actually trying to give them the right information. And then the last one was an integration with the content itself, because if we have content in your website, the most basic example is always a YouTube video. You embed a YouTube video, that will set a cookie. So we wanted to make sure that all that embedded content also is safe, actually. So we don't load that. We don't do those calls to the external domains. So we're actually safe, and we try to be compliant. So we had a couple of options. We looked at what was available in Drupal Core and the contributed space. There were some great initiatives already, but it didn't quite meet our requirements yet. Then we had the idea of maybe we build it ourselves, and we use it just for us. But then we're also not helping everyone else forward. And you have to think Drupal is a community. And then the third party option was, I think they popped up everywhere. The cookie pros, the whatever else, they saw there was a market there. So we also looked at those. So we did a comparison back in the day. They all had these things like the free model supported some things, but not everything. Some were actually not, according to me, not really compliant because they did not prevent the loading of cookies or the loading of the external domains without giving the consent first. So it was some trickery that was happening. So we ended up actually choosing to contribute. We thought it was a very, we thought it was a good idea to actually look at the you-cook-it-compliance module and see what else could be added to that module to actually make it work and to comply to our best standards, our best practices. So I would like to invite Isfand to actually talk through what we did for those things. Okay, hi everyone. So as I said, we choose the you-cookie-compliance module first, because this was the best option that we could find at that time in 2019. Why? Because it had many of the, it was already used by many, including us on several of our websites. It had some nice features out of the box that we needed and it looked like to be a healthy module which is actively being maintained. This is how it looked by default. So it's a small box on the corner of the screen, definitely not meeting the best practice requirements that we set to ourselves. But it does cover some of it, like for example, limiting script before consent is given and allowing custom teaming. So we can tick those already just by simply installing the module. Then we got to work and tried to cover our other goals. First step was to introduce the opt-in with categories option and some additional buttons needed for that. Obviously we needed for that the category, so we created a custom translatable entity for that. As Neil said, we needed to be that information to be available in the languages, all the languages of the website. And the configuration UI where you can configure these categories, their descriptions, and also the default state of each category if they are enabled or disabled. We also introduced some low-level JavaScript observers just to give flexibility and extensibility of the module in general. Status-related events can be used for any constant method while the preference-related ones were specifically for our new opt-in with categories constant method. We introduced also a new configuration option for policy version. By changing this value, you can make the banner appear anytime you want it before the cookie would normally expire when your privacy changes. So at this stage, what we had was a pop-up that facilitates the freedom of choice for different categories. You can force it to reappear anytime you need it and in the background, it triggers some nice JavaScript events that you can bind to. So we are making some good progress towards our goals. Two more checkboxes. But we also learned the hard way that we were dealing with a complex code base and the process was slower than we expected. We should have checked the code as well at the beginning because if we knew from the beginning, we might have done this faster from scratch. For our next target, based on this knowledge or learnings, we decided to go our own way. So we created this small lightweight extension, your cookie compliance GTM module that extends the big one. It's needed for tag managers like Google Tag Manager where you can leverage conditionally adding scripts to the sites. I assume this is known by everyone by now. In our case, the conditions are the categories the user accepts in the pop-up. For example, we only include Google Analytics when the analytics cookie is accepted. So this tiny module gives you an extension of the admin UI where you can add some additional data to the cookie categories defined and expose that in Drupal settings as well, but primarily, it's job is to send that information to the data layer. We initially started with one event containing all the data, but in our latest iteration, we also trigger individual events for each accepted category, which is similar to how other third-party solutions do it. This screenshot shows you what events are triggered or added without accepting anything, so only the necessary cookies. And here, on this one, you can see how they fire one after the other. For events like page views or tags that you need to fire on all pages, like, for example, Facebook Pixel, use the individual events because in some edge cases, the cookies might not be yet set, but for events like click, scroll, form submit, you can use or you can check the cookie value already because by the time they are set for sure. So nice, one less thing to worry about. And another lesson, if you have a good foundation like extensible JavaScript events, then it's a lot easier to progress in a separate module or in a separate sub-module. Okay, so next target was to be able to block third-party scripts, loaded via iframes. For that, we use another module called cookie content blocker. This is something agnostic, so it's not dependent on you cookie compliance. It can work with any consent-based tool. And guess what? It binds to JavaScript events. So once we had those, it was easy to configure them. After configuring some placeholder copy here, you can inform, make it aware of the presence or the lack of consent. So we were able to leverage this module with just small adjustments. By the way, the latest version of this module also allows you to define categories. And then you have this configuration for each category separately. So you can hide and show different iframes based on different categories. Initially, there was only one at the time we started. Yeah, that gives us an extra check on one of our goals. So no third-party is ruining our aspirations to be compliant. And but we still have some other options or other items on the list that we need to check. So for this, we created another module which is called the cookie compliance rocket ship. I'll explain shortly the names of rocket ship is a distribution, is a team generator, is a suit of modules that we use at Dropsolid to kickstart our projects. And you can visit our booth or find us in the Dropsolid t-shirts to learn more about this. But you can also find it on drupal.org. This is an opinionated module already, mainly used by us, but it's available. So you can check how we handle this stuff. And this is how the pop-up looks compared to the original after the makeup of rocket ship. Categories are initially hidden, but to speed up the choice for visitors who already know what they want, either accept anything, I don't care, or I don't want anything to be accepted. But you can open and drill down and make educated decisions on what to accept or what not. So we managed to make our goals. So let's have a final look at the final result. I don't know if I will be able to play this, okay? Cool. So this is a short video demonstrating the behavior of the pop-up when the page contains blocked YouTube embed. It will only show the embed when you accept the necessary categories. So when I accept the analytics one, it already shows in the background I'm clearing all the cookies. Pop-up is appearing again. Then I'm accepting other categories, saving preferences, and it will still show the placeholder and that placeholder has a button to always open the pop-up. So that's really nice. That's what we were trying to achieve. Lesson number three we learned here is that we had a lot of back and forth with hooks and even model ways to achieve our overrides with this module because the original module was changing hooks that they implemented. So we had to follow up as we go. So the lesson is basically when you contribute to module and make sure from the beginning, if possible, to give it a good API, structure it well so that other modules can build upon it easily. That also saves you time on maintenance of the module not having to spend time on feature requests because people can do their stuff by using the API. So as a conclusion, we have a contributed solution that can be configured to follow the best practices even in this vaguely defined GDPR world which is really a nice thing and saves us from recurring payments to third parties and it also allows us to deploy this feature in less than two hours which will be offsetting our initial investment into the module. Another lesson with great power comes great responsibility so also when you contribute to module you will need to maintain it because that's really how the community will benefit from it. So make sure that you put that into the return of investment calculations. And Nils will tell you more about the future. Yes, so I will tell you all about the future. So we saw there were some problems that we identified so it feels now that we kind of have the feeling that EU cookie compliance module feels a bit bloated. There might be too many options in there already makes it confusing for people to configure it so maybe it's a good way to look at what options are still used, maybe clean it up and make it simpler for everyone to actually use it. The fact that the cookie content blocker also has those categories, maybe it's a good idea to abstract those away into a separate module so we use both use the same thing. So to, again, decrease the amount of configuration you need and to make it work together. And then we also, in Rocket Ship, in our module we had an automatic iframe text filter so if somebody would add an iframe in a easy week somewhere, we would automatically replace that with the logic actually that is used by the cookie content blocker to make sure that it's replaced. So an option for that would be to actually move it to the cookie content blocker where it probably would be more at home than in our custom module. So the possible solutions we see, yeah, so we do a refactoring, we split it up. I think it's probably better for that module or for the life of it and for the maintenance. Maybe also move it towards a more event-based coding style and then clean up some of the spaghetti code that's in there. And maybe even for the future, something that's in core possible, who knows. Do remember, when we started this journey, it was 2019. This might not all be that relevant anymore. There are other players in the field that have made a single solution that does this all. So please do also look at those. This was, this session was mainly to talk about our experience on how we tackle this issue and how we want to go forward. So let us know what you think. If you wanna help us build and actually help together with the maintainers to see if we can improve this. There's also a roadmap for the 2.0 version and that's it. Any questions? So we don't have any questions on the screen and I don't know if we have, we still have time? Two minutes, so yeah, probably not. So if you have any questions, yeah, we have it. It works. It's just, you need to configure more stuff than you have to sometimes configure in two places. So that's it. No more questions? Okay, thank you very much.