Talking Drupal #516 - Drupal CMS & Recipes

John: this is Talking Drupal, a weekly chat about web design development from a group of people with one thing in common. We love Drupal. This is episode five 16, Drupal CMS and recipes

On today's show, we're talking about Drupal CMS analytics recipes, and how to use them both with guest Dharizza Espinach. We'll also cover field data as our module of the week.

Welcome to Talking Drupal. Our guest today is Dharizza Espinach. Dharizza is a Drupal developer and educator with a strong focus on content architecture, migrations, and editor experience. She's passionate about helping teams transition smoothly to Drupal and was the analytics track lead for Drupal CMS. Beyond her technical experience,

she's committed to fostering inclusive and thoughtful digital experiences. She's also a member of the Drupal community in Costa Rica, where she supports community growth and collaboration.

Dharizza, welcome to the show and thanks for joining us.

I'm, I'm John Picozzi, solutions architect at EPAM and today my co-hosts are joining us for the fourth and, and final time as a guest host, but hopefully not final. Rich Lawson, associate Director of Technology at Evolving Web Rich is an associate director of technology at Evolving Web located in Chicago, where he gets great pizza.

I'm sure he has over 16 years of Drupal experience. Rich, welcome back. Thanks, John. Thanks everybody. Yeah, pizza's great. I was in Chicago earlier this year and one of my, one of my things was I have to get pizza while I'm there, so I tried a couple of different places and, sorry, I'm gonna go down, down this rabbit hole for a second.

I now found that you can actually have it delivered to your house. So I didn't get, I didn't bring anything home for my kids and I said, listen, I'm gonna order Chicago style deep dish pizza and have it delivered and we're gonna have it for dinner. And, and now it's like in an active rotation in our house.

It's like, you know, typically during the winter, 'cause you gotta turn on the stove and heat things up. But I'm like, Chicago style pizza. That's what we do. Nice. Yeah. Is it, do they like freeze dry it? Or how do they do that? Yeah, so they've never done that. It's, it's frozen and then they put it on on what do they call it?

The, the ice, the icy stuff that they ship things. Frank dry ice. Yeah, that one. Dry ice. Thanks. And and then they send it to you in a box and you just put it in your freezer and take it out when you're ready to use it. It's great. Nice. Yeah. Best thing ever. And that voice is our, our, one of our regular hosts, Nic Laflin, founder at nLightened Development.

Hey Nic. Happy to be here. All right. And now to talk about our module of the week, let's turn it over to, not Martin, but Jacob Rockowitz, a Drupal consultant and a maintainer of a number of Drupal modules of his own. Jacob, what do you have for us this week? Hi guys. Did you ever need to review all the data in a field on a content type or a specific bundle?

There's a module for that. The field data module. The namespace is field data. It's a very new module. I created it in February this year. It's in Alpha releases. It's got a 1.0 alpha 12 release. It's actively maintained. I'm using it on a project. There's no security coverage because it's Alpha, but it's not something you really need to ever really deploy to production.

You could just use it on a staging environment. There is test coverage. The module's so simple, there's not a lot of documentation. There's just a read me file and an animated gif on drupal.org to show the use case of it. It includes just very, very basic default settings to kind of adjust what type of field data is gonna be displayed.

Meaning only published nodes and maybe only field data for the default language. 'cause a lot of sites use automated translation, so you don't really need to review automated translated values. There's no open issues. 'cause the module's pretty basic. It's only used on 34 sites. And frankly I think half of those are my own.

The, the features are, it adds a data. So in Drupal core, when you turn on the field ui, you get a field list reports. You go to reports and you go to field list and it lists out all the fields on your site and where they're being used. And you get an additional tab at the end of that called data. When you go over to that, you see all your content types and I'll even just go my own.

So I describe it properly where it lists out all your content entity types. The bundles that you have. And then you can click on each bundle and see what fields are on that specific bundle. And the specific use case I'm using it for as a migration. 'cause I need to look at, I'm doing a Drupal to Drupal migration, so I have an older version of Drupal, like eight and I need to, we're doing a whole redo and we're just wanna look at the data.

So it gives you this report where you can go to a content and say, show me all the fields. Show me the number of values in that field so you can find fields that are not being used sitewide. Then you go and look at that data, export it as a CSV, and, and frankly the export is, so someone might clean up the data or do some reporting on the data, but it's a very quick and simple way to just look at field data.

I do wanna call out that there's two kind of similar modules. There's the schema viewer module, which is a very new module. I actually found it last week where that just shows all the database tables. I haven't used it, but it just shows all the database tables. And frankly, I find that a little over, I, I'm using this specifically for.

Site builders or o site owners who just look at field data, they don't need to see the whole schema. And I've recently looked at something called the entity export CSV module, which allows you to like pick up a note and say, I wanna export this data, but you don't get a review in Drupal. And it's a little more, requires more configuration.

Yeah. Yeah. And, and Nic, I'm gonna give a little shout out because I'm doing this massive migration, so I'm just giving you a thank you for the migration boost module because it literally saved my butt. My migrations had like ballooned to this massive performance hit because of a couple of modules.

And that migration boost module allows you to turn off modules during the migration. So literally doubled the performance. Oh, nice. It was like one or two hooks that were consuming most of the resources and I just turned to walk. Anyway, let's talk about this module. I mean, it's, it's, what's your guys' opinions?

I hope you guys are looking at the animated gif 'cause that just shows you what it does. I, I've, I've probably spent the last three minutes looking at the animated gif just 'cause I'm like, like, I don't know. I'm a, I'm a, a fan of animated gifs and it, it very nicely shows me that I can like, go into data and then I can click here and then I can see all the, all the, the, the data, the fields where it's used and click through and like, yeah, I animated GIF for the win.

But interesting, interesting idea. I mean, I think that like, this is super helpful because a lot of times, especially when you're doing a migration or like, just like content work, right? Like my, you know, you're trying to figure out what your content architecture needs to be in your, you know, from one site to another.

Like now, now you have the ability to say like, oh, hey, here you go. This, this field isn't used on all my content types. Right? Or this field is used on all my content types. And sometimes, you know, when you're moving from site to site, that can be, that can be an important one. 'cause you're like, nobody uses this field, it's legacy.

Like, let's get rid of it. Right? So I definitely see a lot of use cases there. I mean, it's, it's great to really, like John said, just audit it. I mean, one, one thing I'm not sure that this does or should do, maybe it's a separate helper module, but one thing that I always run into when you're running, like these migrations are like, are the edge cases, right?

I'm working on a big cleanup project for a client as well where we're kind of trying to. D Nest paragraphs as much as possible because we have too many, and I'm running into a couple of issues for a couple where all but like 20 and like, and this has thousands of paragraph entries, right? All but 20 migrate completely cleanly and finding the 20 that didn't is a little bit painful.

Right. So, and again, I, I think it's outta scope for this, but it's a similar kind of space where just like having a tool to quickly and easily audit what is there is, is extremely powerful. Because, you know, you, you can't build a migration without knowing what you're moving and where. Right. And that sometimes takes the most time.

Yeah. I mean, I take this, I take it back to like when I, when I was doing content modeling and like, especially for, you know, the last content model I did was for an intranet. And there were, it was like legacy Drupal seven intranet that had been used for like. Five to 10 years. So like there was a lot of stuff there and I'm, I, I imagine that this would've made things a lot easier to kind of identify the fields that were used or lightly used or not used at all, and kind of how they related and so on.

So, there's a use case. I just wanna emphasize bad data because I have used it because like on the old site, someone, they required a long title. They said we gotta have an extra long title. And then they had 20 records and we opened it up and we're looking at the 20 records and they're all useless people copied the same title over it didn't really add anything.

So like, and also hints if it's bad data, maybe it's a bad, it's a bad content architecture, we're not getting enough direction, they're entering in the wrong value. So it's also good for that. Is there a good way to get to the content? Like when you're viewing the records and you're kind of getting that at glance, is there a good way to get into the actual content where you'd get like the note.

Yeah. In, in the animated GIF you get to this table view that just, it literally is the field data table. So it has the bundled deleted entity ID and revision id. The entity ID is linked. It's blue, you know, in the animated gif it's blue, but I'm not clicking through. So you are able to be like, why is this bad data here?

Where is it going? And go through it. Hmm. But trying not to get anything outside of that, you know, will keep it really, because it would be nice to listen. You could show the entity. Mm-hmm. It, but the problem is then you hit a performance thing 'cause you're loading all the entities and, right. Yeah. This is very performing.

This is like mm-hmm. You show 500 records. Mm-hmm. It doesn't even batten eyelash. Yeah. Because you're just loading the table data. Right? Yeah. And the CSV is the same thing. It doesn't hit Yeah. Any bottlenecks. I mean, if you hit millions of records, I think you're gonna have to gimme a patch to do a batch operation for the CSV export, which we all hate doing.

But yeah. Yeah, it'd be, I'm adding little features here and there if I see something off with it. You know, but as our listeners know, you are a, a prolific module maintainer, so I I I'm assuming there are gonna be great things coming for, for this module. IB before we end though, I do need to ask Jay, is this the only module you maintain that doesn't have any submodules?

Yes. Oh, no, no, no. All I have whole bunch of UI enhancement modules that are floating around here and there, and they don't ever Oh, okay. Not ecosystems, but, yeah. And by the way, the description's so basic, this module's kind of done in the sense of like, yep. I, I don't know if we should be adding more to it other than Yeah, it's maybe comparing options, you know, when you have select lists, you wanna know how often a singular option is used, and that's kind of helpful in the audit, but, mm-hmm.

Yeah. But you can also export the CSV and build a report on that too. Like you don't need to that. Yeah, that was the whole point. That's kind of exactly it. Yeah. That CS v export I have found so, so useful. I feel like needs to be an ai an AI sub module here. No, no, no. To, to send the data to the AI and let the AI help you do that stuff, but oh, cool.

Yeah. We'll just, we'll put a pin in that one for Yeah. I, I'm, yeah, we all talk about AI every day. We're gonna be at Jake, thanks for joining us. Thank you for much having me. Thanks for filling in. And if folks wanted to suggest a module a week or connect with you and talk about all the great things you do, how could they go about doing that?

I'm on Slack, jrockowitz, which everywhere, but Slack is a good way to ping the, or in the issue queues on this module. Just use the issue queue. There you go. All right. Well, I'll, I will personally see you in a, in a few days. Yep. We'll, we'll talk again soon. Okay. Take care everyone. See there. Bye. Alright, let's talk about Drupal CMS, Drupal CMS Analytics and recipes.

So, I guess the, the first, the first question, Dharizza, is what led you to be the Drupal CMS analytics track lead? And like, how did you get involved with that? Like, somebody just kind of like randomly showed up on your doorstep and was like, Hey, we hear you like analytics. Can you help us with this thing?

Like, how does, how does that work out? Oh, no, it was, it was we were just, we were talking me and, and Simone, our director of Lia Web. And he, he, we were discussing about all of these things. I have been like, trying to get us to do more contributions and then we were in the DrupalCon, yeah, the DrupalCon next, last year.

It was in, in fourth, no, Portland was this year. I just forgot Pittsburgh maybe. I don't remember Pittsburgh. Pittsburgh was like two years ago. Portland was this past year. Okay, so the previous year in 2023? No, 2024, sorry. That year the DrupalCon it was announced the SAR initiative and then we all got the seekers and everything and then we started to discuss, okay, so how can we get involved?

I actually submitted proposals for multiple tracks, but the one I got in was analytics. And yeah, basically what we wanted to do was make sure that there is an easy way for the users to, to like, to users that maybe don't have the technical expertise or. For those who is a little bit more complex to be able to have everything set up on, on their sites.

So we wanted them to be able to have an easy experience and have some options that were already configured and ready for them. So yeah, it, it was, it was a little bit of that We submitted proposal for, I think it was for this one, and accessibility, and I think there was another one. But we got, I, I got this one.

So it was, it was great. So I, I mean, do, do you have a background in analytics or a deep love of analytics or was it just kinda like, Hey, we wanna help Drupal and like, I can, I can, I can be versatile and do, do multiple things. I think usually. I can versatile and, and try and do multiple things. Yeah. In the beginning of when I started working with Drupal, like many years ago, like 10 years ago or something, I started looking into analytics stuff.

Hmm. But with the time, so it was like my basis, it was the first things that I, that I worked on and first things that I, that I worked with basically. Then things happened. I moved on, I kept doing more of other stuff, and then this time it was like a cool a cool thing to, to go back to. Cool.

So what was the, what was the major focus then of the analytics track were, were you trying to just get minimal setup, more features? Like what was your main focus? So basically it was we did an investigation for it because we were not a hundred percent sure what was going to be like the thing that we had to give more importance to what was the thing that we had to prioritize.

So we did a little bit of investigation on what, what were the things that were painful for the users, users and comparing all of it with other competitors, like how do we set up analytics, for example, when we're working with WordPress and how, how does that difference feels for marketers? Right? So, a, because of that investigation we came up with the main issues were how easy it is to install into configure.

Most of the times marketers or not very technical users are. Not so sure about what to put where and actually how to install the module. So the, the idea at the end, the goal was actually make it easy to install and configure and getting everything up and running with the least amount of steps possible.

Okay. So one question that I had is whether or not Dharizza, you ran into any challenges getting everything ready to launch with the 1.0 version of Drupal CMS? We, we had a couple of things. So one of one of those things is that once we decided that we were going go with Google Analytics, because it is the one that has the biggest market share when we were designing and trying to come up with the recipe.

We had this thing that we need the container id. Right? So there were two main issues, let's say, that we had to, to sort out in terms of the recipe building. One of them was that we need the id and the other one was the configuration entity that that needs to be saved. So in terms of the container id what happened with that is that the module doesn't work if we don't add something, right?

Mm-hmm. And then there was the question of, okay, what do we do? Do we just install the module and have a basic configuration imported, just a configuration from the module or something else, because we need that text. And if we don't ask for that text when we're installing the recipe, well the, the main point of the recipe was, was still not going to be met because then the users will still need to have to know.

Out of like nowhere where to go to add that. So this was the first recipe that actually had the functionality of prompting the users for input during the installation. Mm-hmm. So we have, there, there are two recipes that do that. I think currently we only have two. It is the analytics recipe.

Another one is the ai. So if you have seen the AI basically to, it asks you also for what is the, the provider and so on. And then you can add, yeah, I think the API key in the case of Google Analytics, when you try to install it, we get the form that shows that asks what is the container id. Mm-hmm. So that was, that was challenging because at the moment there was no integration with the project browser, or at least not in the ui.

So we had to start and, and coordinate with all teams that were working on that make sure that it was ready to go. And, and it was an interesting thing for, I think for the Drupal economy, Europe in Barcelona last year. We had the first kind of version, but it was like fake working until actually December.

So yeah, that, that one was an interesting challenge. And then the other thing was the configuration entity that it usually had to have a particular name, but normally in through, sorry, in Google tag module, that name matches the Google tag id. Mm-hmm. Yes. And then this is not something that can happen with, with recipes when we're important.

This, we cannot use that input as part of the name of the configuration entity. Entity. Yeah. So, so how so, sorry, John. So how did you solve that second issue then? Did you modify the GTM module itself to change the configuration or. We ended up just adding a name, a random name to it. And it is always going to be the same because this is a configuration that is coming from Drupal cms.

So the contain the configuration item. The configuration entity is basically called, I think it's just Drupal, Drupal Jamal file. So it is like, Google tag do settings, Drupal Jamel, and that's it. So the ID that we gave to it was Drupal. And luckily the module was not really relying on it to load anything else.

All the information is inside of the file, so it was good, but at the beginning we thought that it was, and that things might be failing. So, it was a little bit of the bugging to, to find out how to actually get it to, to work, to, to the point that we needed. And did you, you must have had to have worked with, the recipe initiative to, to kind of add the functionality, to do prompts, right? Or did you kind of just tag on to the AI initiative needing that already track, needing that? Actually, actually the first one who got it was if I'm not wrong, that's what I was told was the first one, the first one that was merged and everything was the analytics one for the prompts.

Okay. Yeah. So what happened there was that fima, he was working with the, the, the work with the, the prompts. So there was already integration in terms of asking for it from the terminal, but there wasn't for for ui the browser ui, exactly. Yeah, exactly. And in there we had to do a couple of fixes and then we came up with, we noticed a couple of box, and then those things got fixed and so on.

Did was come coordination with that team as well. That, that was gonna be, that was gonna be my question, is like, I'm, I'm familiar with the prompts at the command line. If, like you said, when you install the AI recipe, it asks you for, you know, your, your open open AI keys and stuff like that. I actually just I wrote a blog post on installing a creating a basic donation web form, and there's a recipe out there that does exactly what I say in my blog post.

And when you install the recipe. Via the command line. It says, Hey, what's your stripe? You know, API key and asks you a couple of other questions that you have to kind of reply to in order to get it installed. And I was like, I'm like, this is cool. Like, makes sense. But my question was going to be around like those UI elements, so digging into that a little bit more Right.

When a user's prompted. Right. So is it in the Drupal CMS like installer that they get prompted like as part of a setup, like a, a, a setup step for Drupal CMS? Yeah. So if it, in this case, we don't have the analytics one in the, in the main installer. Right. It is like you go to project browser and then you install it that way.

Got it. Okay. Yeah. It is not part of the ones that are recommended in the first step. Yeah, I think in the first step it is basically a couple of content types. So. In the case of analytics, it is not part of that. You have to go to a project browser and then do it that way. When you go to a project browser page, to a recipe section or the recommended section, which is mm-hmm how it's calling in triple cms, you click on yourself for the recipe that you want in this case analytics.

And then once you click on that button, it takes you to another page that basically has a form. Ah, ah, okay. So that's it. So it takes you, it takes you, it launches basically the, the configuration. Yeah. It's not the whole configurations, it is just a simple form with whatever we had added in, in the, and it works pretty much the same way as the, as the terminal front, right?

Because the way in which you configure it is pretty much the same. It is still a form API you still add your text. Sometimes people say that it is like kind of duplicating it, not really, but, but it is basically following the same steps. So. It is a form built would form API for it. Mm-hmm. So I'm wondering, like focusing more in on, you know, leading kind of a, a, a track for Drupal CMS.

Right. You're a Drupal trainer, you're a, you're a backend developer. I'm wondering like. What, what's it like leading a track for like a major piece of, of, you know, Drupal cms? I mean, like, everybody uses and needs analytics, right? So like, it, you know, it not being, there wasn't kind of like an option. You know, what was it like, what was your experience with it?

Like, I, I imagine it, it was, you know, to get things into the one oh version were a little, was a little nerve wracking, but I'm just, I'm interested in hearing more about, about what it was like. Yeah, it was, it was an interesting experience to be honest. I, I think there are things I could have done better as a lead.

But, but it was an interesting thing having to coordinate with the team that was helping me out with investigation, for example, and then also with the Starship Council and then the, the product owner, like Pamela. It was great working with her and then being able to I. Create the proposal, then come up with the updates, and then be working on the things.

It, it was, it was all an, an interesting experience. I think in the case of analytics, we mostly had people, like other people involved in the investigation part of it. And then when we were actually building the, the recipe, it was mostly me and the Drupal CMS team, like the leadership team. So, so were you leading the initiative and also doing the development work, or were you working with a bunch of different developers?

No, in this case, I, I work with, there was one other developer at the beginning that also works at the only web. And then, and then I took it out from, from there. Got it. Okay. So you were, you were kind of pulling, pulling double duty. You know, so, so what, one of the questions that I have that I don't think I've asked the other edition leads and I'd, I'd like to kind of gauge how much work went into this.

Like, if you had to guess. I mean, CMS has been out for eight months now. I think it took eight months. So it's been, it's been about the same length since CMS came out as before. If you had to estimate the amount of time you spent on this in the last year and a half-ish, how much time is that? Is it a hundred hours, 500 hours, a thousand hours?

How much work do you, would you say you put into this? No, I think in this one it was. How much college have been like, maybe like a hundred hours in, in prep? Yeah. Like before launching. Maybe maybe that in, in terms of coordinating, doing investigation or, or helping with investigation proposals and then a little bit of the coding that I was getting involved in as well.

So yeah, maybe, maybe around a hundred. I, I don't think these recipe is actually quite at the end. It resulted on a very small recipe. So yeah, it was a short just outta curiosity, and you can choose not to answer this question if you like. How many of those like a hundred hours were I don't know, subsidized, or let's put it this way, how many of those, how many of those hours were like on the clock working for evolving web versus like your personal time?

Ooh, what a great question.

Maybe. Ooh, I don't know if it was can you can be like general, like 50 50, 75, 25. Like I, I, I'm thinking Yeah. I'm, I'm, I'm leaning towards 50 50 or 75, 25 75 a volume web, but I think it is like a little bit more than 50 50. A little bit less than 75.5. Yeah. We'll go 60 40, you know, that's, that's fine. Exactly. I mean, the, the point in my question here isn't like, Hey, look at, look at the personal time versus the time evolving web is allowing you to work.

Right? It's more that. It, it was a, it was a, it was a, it was a, a team effort, right. There was, you know, yeah. You know, there was impetus from you, the company that you work for, as well as your own desire to help that, that kind of brought this, brought this to the finish line. Yeah. And I, and this is gonna sound a little bit harder hitting than, than it's intended.

And then we generally get, but this is, this question is for you, rich when you're considering, because, 'cause obviously this was, you know, part of evolving web strategy, but when you're, when you're considering these kinds of things, how, how do you kind of plan out that investment or sponsorship from an evolving, I mean, maybe it's not a strict sponsorship, but when you're kind of planning this out and looking for ways to get involved, how did you, how did you kinda gauge it or plan it?

Like, did you expect it to be 70 hours of, of sponsored time-ish? Did you expect it to be 200? Did you. Say like, Hey, we don't know, but whatever it is, we're willing to step up, you know, how, how does evolving web think about this? So before you answer with actual facts, rich, I just imagine in my head, and like when I asked my first question about like, how did you get involved?

I just imagine like Alex running into a room like, like Kramer into Jerry's apartment going, we need to be involved in this. Like, that's, that's kind of the way I imagine you guys getting involved. Okay. Rich, tell us, tell me the how I'm completely wrong and, and the actual facts. Yep. So, you know, I joined involving web about a year ago, and so I wasn't directly involved with this one, but that, so that scenario that you painted John, that might've been exactly the way that it went with Alex, I'm not sure.

But you know, overall what we do is we would be estimating things and, and just kind of taking a look at, you know, like how much time we think it's going to take, and then realizing that, you know, like with these twists and turns, like what Dharizza had brought up before about like the fact that, you know, like there was that UI element that hadn't been built and there's just things that end up being unanticipated as you're getting into it, that it'll, you know, it'll be flexible a little bit in terms of, you know, like what the actual number of hours would be.

Oh, go ahead. We had more people from the team working on it. So as I mentioned, like there was, there were some people helping out with investigation. There was another Deb that was dealing with this and, and, and, and doing development at the beginning. So it, it was a little bit of, of everything. I, I think a lot of it was also we, we discussing with Suzanne at some point.

And, and yes. So we, we had been trying to get more contributions out of the door and then when, when this opportunity came out, it was like, Hey guys, this is happening. This is happening. We can, we can, we can help. And, and, and is it more like, like a downtime or like a off, off project sort of commitment where you're like, oh, I don't have a project to work on right now, let me go work on this.

Or is it like literally planned as like, yep, this is gonna be like, like part of your project workload for the, you know, the next two months? I think it was most like, more like the second option that you said? Mm-hmm. Yeah. Okay. So it's, so at some point we added like a little uhhuh Uhhuh. Yeah. Gotcha. So we tried to get me out of some other stuff to, to be able to take this one on, but it was okay.

Yeah. It, and we, we didn't have this in the show notes, so I, I apologize. We're blindsiding you a little bit with this, these kinds of questions, but it's something that's been at the forefront of my mind is like, how, how different organizations or organizations of different sizes kind of plan out their contribution and, and put that back in.

'cause I, I imagine it's very. Sorry, I, 'cause I, I imagine it's very different for an organization of your size than, you know, an organization of my size, which is just, just me. Right. You know, I kind of just pick and choose what I wanna work on and spend whatever I can on it. But yeah, I, I was curious about that.

I appreciate, appreciate, I mean, I guess it, for me it was more of a, it was more to highlight the fact that Evolving web, right. And a lot of other agencies of the same size, right. Spend, spend their, you know, think about this stuff and they devote a lot of their, their workable hours to to, to helping with these initiatives and pushing them over, over the finish line.

Right. And I, and I think there, you know, there are a couple of different schools of thought here. One is. Hey, we, you know, and, and I'm talking in general, not specifically about e evolving web or, or any other company, but like, you know, I, I think there's a school of thought here that's like, well, you know, open source contribution should happen, like, as a, as a pet project in your own personal time, right?

Not, not on the company dime. Or, you know, if we're doing it, we should do it as part of a paid project where we're not, you know, we're not potentially losing money. And, you know, I, I think it's, I think it's, it's notable and noble to point out the fact that no, this is, this is, you know, core to, to what you guys do, and you feel it's important to, to give this, this time and energy back to the project.

So like, yeah, we're gonna, we're gonna build it in as an actual project as, as you know, yeah. As not, Hey, you have to work extra time to do this, but like, hey, it's part of your, your, you know, commitment. Well, there, there's also another there's another aspect to it, which. Which is that it shows kind of the barrier to entry sometimes to contributing to an effort like this, right?

Building a Google analytics recipe is like, if you had asked like that's, I don't know, maximum eight hour project. Like what? Like, and, and honestly it probably would be like two hours you'd realize, oh, we can't do the token, we're just gonna have to have that afterwards. So the recipe just becomes, it enables the module does some stuff, and then you go to the form, build it in, export that config.

You call it a day, right? But you're, you're solving, you know, part of the track and part of the beauty of CMS, aside from a lot of other stuff we've covered in the show before is you are, you're solving the hard UI problem, which is, how do we make it easy for somebody who doesn't know what they're doing, doesn't know Drupal, doesn't know config management, doesn't know any of that stuff.

How do we make it easy for them to just click a button, get prompted for something that they think that they need? Maybe and then put that in and have it working period done. And that, and those UI things are things that make a project like Drupal or c Drupal CMS or whatever look good, but they require, I mean, a hundred hours for that type of thing is an enormous investment.

I mean, that's, that's so much work. Right. And I mean, I think, I think it's a great contribution. I mean it, but it, it's a big barrier to entry, but it's the kind of things that are getting solved because people are excited about dral cms. That which, which excites me, I think a lot of, of, of the time that we use for this was in the, in the early stages, right?

Like all the investigation, because we we're also thinking about what is the tool that we want to ship this with, because maybe. It was kind of obvious for all of us, or maybe we had the hypothesis of, oh, it's going to be Google Analytics and we're going to go with that, but we actually need to have the data that supports that.

Yeah. That is what all, all people is expecting to use and so on. So yeah, for sure that that's, that's a lot of things there. Yeah. And, and Dharizza I also remember us talking a little bit about like the sensible defaults that, like the configuration that comes in with it. So I would imagine that there were a lot of conversations surrounding like, what should those be?

Because you know, like different things will work for different, you know, projects and so you wanna be smart about it so that it does make it really easy for the user when they, you know, when they're spinning up triple CMS and getting things going. But at the same time, like you don't wanna, you know, have too much there to where, you know, like they get kind of bogged down and maybe it's overly, you know, complex.

Yeah. Yeah. That, that's, that's also something like we, we were thinking about what are, apart from requesting the, the, the Google Tech id what are the defaults that we should have for the user? Like the classic one is excluding administration pages from being tracked. Right? But then we also had to do integration with the privacy track.

So how do we work with that? How do we integrate with them? We need that, the, the privacy track to be done with certain things so that we can actually also add extra configuration to configure Cloudera to include the Google Analytics as part of, of the things that we are requesting consent from for, sorry.

So, yeah. The defaults, the integration with Dollar Track, the investigation, it, it, it's adding up. And then we, we actually wanted to do more things, but those certain things had to be blocked at certain points because some other parts were not ready. Like, something that we will have love to do was some integration with Experience Builder for campaigns.

But I mean, it cannot happen. It couldn't happen at that at the point. Yeah. Yeah. So it's like, yeah, something that, that we have to think about and consider there. So, so you mentioned in the end that the recipe itself ended up being pretty simple. Aside from all the planning and, you know, the, the custom integration with the recipe installer and all that kind of stuff.

What, what is the actual recipe? What's, what else? You mentioned that there's the, excluding the admin pages and stuff, but what. What's the total inclusion for the recipe? What, what can somebody expect? So you can expect to have the Google Tag module enabled. You will be request, it'll request the Google tag id either, whether you install it from terminal or from the ui.

You will have administration pages exclusions on like from, from the, from being tracked. So those default settings are going to be there. And then we also have the integration with the privacy track. So as soon as you install the recipe, you will also get changes in the way the consent is managed for, for Google Analytics.

So what will happen is that normally when you just cell through CMS, the privacy track is basically adding a link in the footer of the main page, for example, where you can manage your settings for consent management. The moment we install the analytics track, the way in which that is displayed changes first because now you'll also have the analytics categories in there that includes Google Analytics and Google Tag Manager.

And second it goes from being just a link in a footer to also being a dialogue that is displayed. So nothing is tracked until you have given your consent for the system to track your data. Okay? So it's those little pieces. It's still a game, a small recipe so far but those are the things that it includes.

So you had talked a little bit about you know, obviously there was the AI track in terms of the ui you talked a little bit about the privacy track in terms of the consent management. But can you talk a little bit, maybe more in detail about like any sorts of dependencies or collaboration you know, with those groups as you were, as you were building out the analytics recipe?

Yeah, sure. So, I think with, with the privacy track, we, we, we discussed with Jor who was the lead, is lead for, for that one about what was needed and, and how to deal with that. So there was integration with them and communication coordination with them for your project browser as well. For that one, it was mostly with Mima that we, that we discussed.

There were all our dependencies on sample the Drupal CMS page recipe, and that's basically, oh no, wait a minute, triple CMS page. Not really. I'm confused in terms that one is penile of the privacy. But I think those were the main, the main integration points, like talking with recipes, team, talking with project browser, talking with privacy, those, those are the main items.

And in terms of the dependencies of, with all our systems I think not really. We basically have the dependency on Google tag. That's the module that we decided to use. And yeah, I mean collateral, but because of the dependency on the, on the privacy track. Mm-hmm. Yeah. Thank you so. One of the things I think like, is the main objective of Drupal CMS is that like it's you know, it expands the adoption for Drupal, right?

It makes it easier for folks that aren't overly technical to spin up Drupal quickly get started with it. Sounds like with analytics you thought of that with, you know, prompting people to enter their Google tag ID to make it easier for, for that setup. I'm wondering though, when you look back at kind of the wider community of developers and agencies that that use, use Drupal, like, is there a benefit to the analytics recipe for them other than just kind of like easily installing Google Analytics?

You mean for like outside of Drupal CMS or? Yeah, yeah. Outside of Drupal CMS, definitely. Okay. So it, it's still like we can still install these or any of the recipes actually even if you are not using triple CMS. So that's the creation of those recipes is still something that can be taken advantage of.

Right. And this doesn't, it's not just for the analytics. Again, it's for all of the ones that we have out there. In the case specific of Google Analytics, again, given it is very simple, if you are very familiar with how to create, sorry, with how to install and configure modules, then probably it's not that big of a deal.

Mm-hmm. Because this one is basically just got like reducing the gap or the entry barrier for people that doesn't have the technical knowledge and needs to have analytics on their websites. Mm-hmm. So that, that will be how I see the difference there. So I, I, but I think there's another. Thing. I think there's another piece of value there that you're, you're forgetting, which is, yes, it's e Even as an advanced developer, it's easy to install that module.

It's easy to configure, it's easier to set, set up, right. It, it's like, it's literally five minutes, you know? Yeah. Including the composure require, but it's also, I mean, this will also be one minute. Yeah. Yeah. Well, no, what I was gonna say is it's also one of the ones that I, you have to have on checklist, because I regularly forget to do until halfway through the project or right the week before launch.

Or if you have it as part of like a recipe and installer, well, it's just a prompt. It's there, it's done. Like you check a box and, and it, it's easy. Now again, like I said, I think the really brilliant thing that you guys did was that UI prompt. Right. That makes it, that's a huge. That's a huge amount of the work on the UX side, but it also makes it that much more simple.

And I think there's a value just having that kind of thing. Like, okay, I can set it up and forget about it. I don't have to remember, I can check that off my list. I don't have to remember the week before, like, oh my God, what's the analytics? And yeah, I mean, I have checklists. It's rare now that I forget to do that, but it is still something I have to remember.

Well, I think you, I think you highlight a very, a very salient point there, Nick, as far as like if you include this in a, in a, in a larger recipe, right? That that's specific to your agency or it's specific to your, the way you like to configure Drupal, right? It just makes it, it makes things a lot easier for you.

I also think that, you know, for basic, for basic developers, that sounds, that sounds reductive, but for, for somebody who's maybe new to developing or somebody who's like, n you know, not a hundred percent sure how. Analytics should be configured. Like they can install this recipe and look at it and go, oh, all right, they did that, they did this.

But also for more senior folks, it might be a catalyst to create other analytics recipes, right? So like if you integrate with Adobe Analytics, so you integrate with your own personal, like analytics package or something like that now you can create, you know, a recipe or at least have a template on how to create a recipe to do that.

So yeah, I can see definitely a bunch of different use cases here. Outside of the ones that you, you defined, I mean, I think the, the, the inclusion in an agency specific, like master recipe is, is, or well, in the future it will be called a site template. But I think that's, that's interesting.

Definitely. Yeah. And, and I think that part is like, I'm so sorry. That's all right. We, we wanna hear you. We don't wanna hear me like Yeah, we talk, we talked too much, so keep going. No, I was going to say that I, I think that part is, is, is quite good in general about the whole recipes initiative. Yeah.

'cause and, and this is something that we're trying to, we're, we're trying to do in, in a volume web. We're trying to come up with recipes that actually will make a lot of all the things that we have to do faster and easier and that we're not going to forget. Maybe there are some things I'm thinking right now about security kit for example.

There is a lot of settings there that I know it's easy to go and configure, but you still have to go and configure each of them, right, to pass some stuff or maybe things related to security policies for passwords and so on. Maybe you want to always have certaining modules in all of the websites that you're building as an agency and, and make sure that you, the maintenance code of your sites is, is lower, let's say.

Or it's better because. You have something that is kind of standard. So being able to have these master recipes or individual recipes that you can add and select on, on each of your sites is, is very useful for that.

So, do you intend to post those recipes to jupa.org as public, or do you think they're just gonna stay internal to, to evolve and Web because they're just like specific to your they're specific to your organization? I, I think I'm gonna go ahead of the guys on that, but I think we want to publish them.

Yeah, so I think that's what's going to happen. They will be published public, sorry. What all, all the recipes potentially will, will be out. We're in the process of building them, so, yeah. Yeah. And one thing I wanted to mention too is, you know, there's other work, like going back to what John had said about the you know, the kind of the installation process and using all these recipes, there's a recipe installer kit that, you know, had been put together.

There's a project on D oh for that. So yeah, it's definitely something that, you know, we will work out in terms of, you know, contributions and, and there's other things to work with to where you can kind of get that similar experience to what Drupal CMS is doing. But, you know, maybe, you know, from an agency perspective, you know, there's a lot more that you wanna include or some different things that you wanna include that can be helpful there.

Yeah, I, I think that's interesting. And I know that project browser is, is working on some sort of version that is like a, also a recipe browser, right? Yeah. So that you have the ability to, kind of install your, your recipes, you know, similarly to you how you install modules. And I know that Jim Birch also has a repo of recipes floating out there somewhere.

So, the saplings, I think I, I, you, you might be right. But I think like, I don't know, I just see exponential growth for like, the recipe ecosystem going forward, which is, which is exciting. I mean, like, like I said, you know, I, I, I spent an afternoon installing web forms and stripe and, and configuring it and, and, you know, getting the form to work reasonably well the way I wanted it to.

And, then a recipe came along and did exactly what I needed to do, and, and it literally took me you know, three minutes, answered a few questions in my, in my CLI Oh yeah. You know, tool of choice and, and like, Hey, here you go. Right. I, I really think the big thing that recipes need, and I it's on the roadmap, I know, I think it's far too, I think it's far too far down the roadmap than it should be, is we need far, far, far easier ways to build recipes.

Because even simple recipes are just painful. And if you're trying to build a recipe that does anything moderately complex, yes. They don't have to be in potent, right. But mm-hmm. There's just so much that goes into it, and you have to know config so, so, so well, to write them, it's, it's painful. It just takes a, it takes somebody who's far more advanced.

To build a recipe that I think is, is reasonable long term. Like we need a way to just ex say like, I built this blog, I want to export everything related to this blog. Yes, maybe it takes too much, but export that to a directory and let it be a recipe like we need. We just need that. I tend to agree with you, Nick, but I mean, I think my biggest issue when I was working with recipes, trying to, trying to create a recipe to kind of like, you know, as a starting a side starting point, right?

I think my biggest thing was like the configuration, right? Knowing what configuration you did need, what configuration you didn't need, what was actually content versus configuration. So like, yeah if there's some sort of tool out there that can kind of automate or help with selecting that and exporting it, I think like absolutely makes sense.

I mean, it, it gets even more complex because you have, you know, config entity versus simple content. A simple config you have. Config. Sometimes you have to use a config action to do something. Sometimes you don't. By default, Drupal puts a, a hash on every config file that you have to strip out. Like Yeah.

And, and like, which folder does it go? Like there's just so much little detail, so many little details that you have to take care of. And then if you're changing it again, so like I tried to create a recipe for a client where they have a set of paragraphs, components that they use all the time on every project.

It's like, okay, that'd be a great candidate for recipe, right? Save us a bunch of time creating the 25 components that they use, or whatever it is. And I went through and I, I even wrote a back script that I haven't released anywhere yet that I should, that helped with, like stripping out the config hash and all that kind of stuff because it's pretty predictable.

But did all that, got all that work. Got it. Working. Then realized that I forgot all the managed display and all the displays and like, just like, and, and I know Drupal and I know config, and I thought I knew about, like, there were just so many false starts like that where I, I basically realized for this particular type of system, it's better to just start from a database like we always did, right?

Have a starter database that has most of the stuff you want, you know, with no content in it. Instantiate that database, export the config, delete the things you don't want, tweak what you need, move forward you know, reset the site, you idea, all that kind of stuff. All the standard stuff that you do. But these really complex recipes, because the thing is you add a new component, you wanna do it?

Well, now you have to strip out that config hash again, make sure you didn't miss any dependencies. Like just maintaining that takes so much more effort than I think is reasonable to make it sustainable. But it's a problem that can be solved. I'm, I'm so optimistic. I'm not, I'm not worried. I just think.

I'm just hoping somebody steps up to do it sooner rather than later. Yeah.

Yep. So, Dharizza, you know, kind of thinking, and you know about triple CMS overall, and you talked a little bit about the roadmap, but are there things that are on there that are really exciting and that you're looking forward to that you could share with us for Drupal CMS? Mm-hmm. Okay. So as far as I know, the Onement for the second version of Drupal CMS is basically having site templates.

I'm an experience builder, and then even more AI capabilities. I am specially interested well, I'm, I'm, I'm interested on the site templates, that's cool. But I'm more excited potentially about the experience builder. Like there's a lot of hype and, and, and I have tried it a couple of times and we have been, we working on, on.

Experience builder readiness as, as in working on our own components to make sure that they are compatible with Experience Builder and they can work well once experience builder is out so that we can start using it immediately. Mm-hmm. So that's, that's something that I feel is, is quite, quite interesting at this point.

Do, do you see any future enhancements to the analytics recipe specifically? Like are you looking at other features, functionality you like what And actually, actually Mamo is on the roadmap. I, I have a, a first version of a recipe for Meta. It is not full yet. That one I'm working on. Okay. It's another tool for what, what is, what is that?

Yeah, I'm, I'm, I'm out of the analytics game clearly. Okay, so Mat is another tool that we can use for tracking analytics data. There is even a Drupal module for the integration. So yeah, actually that was one of the options that we consider when we were doing the first investigation about what should we ship the, the, the recipe with.

And I mean, Google Analytics took 95% of the market, so we went with that one. But then Madam was in second, or th or third place. I can check my notes. But it was in second or third place. It was a lot smaller, but it is still something out there. And we have an integration with Drupal, so we do want to have that one out there.

Currently what is kind of stopping me is that, yeah, we do have like the separate recipe, but I'm still considering how to. How to make it so we can do something similar to what the AI is doing. Like ask a user which one is the one that they want to go with, and then try to apply one or the other.

Because currently they exist a separate recipe. So we have the Google analytics recipe, and then it'll be Mamo recipe. But ideally there should be in the CMS, there should be one analytics recipe that can provide multiple things depending on what the user chooses. So in this case, it's kind of complex because this master recipe like will be, we cannot call the two recipes in this case because they're separate.

Yeah. So that's what's happening right now. That's why it is not fully moving. No, not fully out there. But that's one of the things, having support for all our tools. And the other thing is I'm still interested on, on getting work. Done for integration with Experience Builder and being able to change the data layer to make sure that that is configured or pre-configured for the users as well.

I'm still not sure how that is going to look like, but it's part of the things that we, that we had in the roadmap. Sorry, I, I've gone down the Omo rabbit hole here of figuring out why I should use that over Google Analytics. The big, the big takeaway here is like a hundred percent data ownership.

Yeah, yeah. Pri privacy and data ownership, right? Yeah. So if you have to meet GDPR or HIPAA or those kind, or you care about me, you know, keeping your own data to yourself, me is the way to go, and you could sell post. Interesting. Okay. All right. That is super, super interesting. I mean, I think that, you know, talking, talking to a, a track lead and talking about analytics and talking about Drupal cms, so Drupal CMS 2.0 should be looking for something about that at DrupalCon Vienna.

Is that, is that accurate? I, that's a good question. I'm not so sure about, I think, I think that's a question for Gaber, I thinks. Yeah, I will. I mean, I will, I will, I will redirect that question to to him then. Yeah. As far as I know, in theory there should be a release in September, so that is like what, two weeks from now?

Three weeks from now? Yeah. So yeah, I assume Vienna will have a nice show about it. There you go. Well, therea, thank you for joining us and hopefully we'll, we'll talk again soon. Thank you so much for having me. Do you have questions or feedback? You can reach out to talking Drupal on the socials with the handle of talking Drupal or by email we [email protected].

You can connect with our hosts and other listeners on Drupal Slack in the Talking Drupal channel. You can promote your Drupal community event on talking Drupal. Learn [email protected] slash td promo.

Get the Talking Drupal newsletter to learn more about our guest host show news upcoming shows. Much more you can sign up from the [email protected] slash newsletter. And thank you patrons for supporting talking Drupal. Your support is greatly appreciated. You can learn more about becoming a [email protected] and choosing to become a patron button in the sidebar.

All right. Dharizza, if folks wanted to get ahold of you to talk about analytics, about recipes, about Evolving Web, about all the things that you're involved in, how could they go about doing that? Well, my username is therea almost everywhere, so it's just really weird. You can find me under that in Slack, in, in Drupal Slack, or in Drupal dr drupal.org as well.

Perfect and rich again, thanks for joining us for the last four weeks. Pleasure. Don't be a stranger. Feel free to come back anytime. If folks wanted to get ahold of you, how could they go about doing that? Thanks, John. I'm RK Lawson and Drupal Slack active on LinkedIn can reach out there and you know, definitely for revolving web.

Check out evolving web.com. Hey, Mike and Nic, what about you? You can find me pretty much everywhere at Nicxvan N-I-C-X-V-A-N. I'm John Picozzi. You can find me [email protected] or on social media and drupal.org at John Picozzi. And you can find out about EPAM at epam.com.

So, if you've enjoyed listening we've, enjo enjoyed talking and I thought a really great tagline for today would be, you know, Drupal Unleashed since we had the dogs, you know, involved a little bit earlier.

You know, who let the Drupal out maybe. Yeah. Who let the Drupal out? That's even better. I like, maybe, maybe that's, maybe that's what we go to from now on. We could even like sing it. Like who let the Drupal out? Who, who, who? We'll workshop that one.