Talking Drupal #573 - Off The Cuff #13

[00:00:00] Nic: Hey. I scroll down. So this is Talking, this is Talking Drupal, a weekly chat about web design and development from a group of people with one thing in common: we love Drupal. This is episode 573, Talking Drupal, Off the Cuff number 13. On today's show, we're talking about DrupalCon Rotterdam, Canvas, and evaluating modules.

We'll also cover Revision Graph as our module of the week

Welcome to Talking Drupal today. We have no guests today. We're going to be doing another off-the-cuff with Martin and Tim. I'm Nic Laflin, founder at nLightened Development. The show notes are a bit of a mess. If you noticed, we're a couple minutes late, so I am a little out of sorts, so I appreciate your patience.

Tim is a web developer at Appalachian State University. He's also a co-organizer of Drupal Camp Asheville and loves connecting with other Drupal folks. When he's AFK, he's usually tinkering on a project he may or may not finish. Welcome back to the show.

[00:01:07] Tim: Hey, Nic. I finally finished a project. I built my first gaming PC, so I did actually.

Oh, very cool. Yes. Very happy.

[00:01:17] Nic: I, uh, I did that a few years ago for a VR PC, and it turns out that the CPU and motherboard were incompatible, and it took... Like, the version was compatible, but the- Oh ... specific firmware was not, and it took a lot of effort to get that working.

[00:01:33] Tim: Mm-hmm.

[00:01:34] Nic: Um, but it's fun. It's a, it's a good skill to have.

Definitely. Uh, also joining us for the full show today because John is at a conference, Martin Anderson-Clutz, a senior marketing manager for Drupal at Acquia. Welcome to the show, Martin.

[00:01:48] Martin: Hello, internet friends.

[00:01:53] Nic: And, uh, one thing I really need to figure out is when I'm doing the intros is how to do the transitions to Module of the Week, because the show notes are in a different tab in this switch, so we will make that smoother at some point.

Uh, so Martin, uh, what do you have for us this week?

[00:02:11] Martin: Thanks, Nic. Have you ever wanted to see a node's revision history john- drawn like a Git graph with each transition as its own branch? There's a module for that. It's called Revision Graph, and it was created in September of 2019 by Shiven Das. Uh, his Drupal.org username is D34DMAN, which is, I think, kinda leet speak for dead man of Factorial, and it has a 4.0.0 version available which works with Drupal 11 and 12, and 3.1.1, which works with Drupal 10 and 11.

It is actively maintained. In fact, that 4.0 release landed in mid-August after two alphas the same week. It has both security and test coverage, and for documentation there is a solid README plus in-depth technical and revision model docs in the repo. It has no open issues, and it is officially in use by 242 sites according to Drupal.org.

Now, with the module installed, every node gets a Revision Graph tab right next to the core revision- Revisions tab. One row per revision, one lane per language, so you can see when a translation branched off and how it's evolved since. Each dot tells you two things. A solid ring means that revision was live at some point, a dashed ring means it's a draft that never was, and a filled center means it's what that language is serving right now.

Yeah. It works with content moderation if you have it, showing your workflow states as text badges with whatever names your site uses and adapts cleanly when you don't Uh, reverts and edits made from the published version while a draft is pending show up as forks instead of a straight line. Under the hood, Drupal doesn't actually store which revision a new one was derived from, so the module adds a small base field that records it at pre-save.

Older revisions don't get backfilled on purpose, since reconstructing that would mean guessing. Those edges are inferred, and the graph draws inferred edges differently from recorded ones, so it never implies more precision than it has. So on an existing site, make sure you run drush updb after enabling it.

Uh, it ships a distinct color for all 95 languages or language codes Drupal knows, so it looks good out of the box, but you can override a lane's color or the fallback palette in config. The graph loads in pages as you scroll, so long histories render quickly, and it's keyboard navigable, area labeled, and works in forced colors mode.

It's great for editorial teams on multilingual sites and handy for compliance or auditing when you need to answer what was live and when. Now, a couple caveats. It's nodes only, and for obvious reasons, a user will need the view all revisions permission in order to see the graph. But let's talk about a revision graph

[00:04:58] Nic: I think this is interesting for, uh, like I, I hesitate to share this with the standard editor because I think, you know, it's a very much a Git, uh, it's a very much a developer thing, but it is good for reconstructing that history.

I, I do wanna question... I, I do have one question about one of the technical things. So you said on an existing site, make sure you run drush updb after enabling it. Is that something that comes from the module page? 'Cause updates, when you install a module, it marks all updates that exist as run, so there's no, uh, anything that it should be doing for base fields or for it should be in the install hook, it should be taken care of.

So maybe we can create an issue if that came from the-

[00:05:42] Martin: Yeah, I'll have to go back and check where I got that, but yeah, it's possible that, um, that maybe that's more, you know, something that, um, is a legacy- Yeah ... in terms of where I got that from, so.

[00:05:53] Nic: I, I, as, as a colorblind person also, I shudder to think what 95 different colors look like.

There's no way of being able to distinguish it. I mean, that's not a problem he can really sol- I mean, 95 is 95, but as a colorblind person, I guarantee you I'm gonna see, like, 10 colors, and they're all gonna look the same to me.

[00:06:12] Martin: Yeah, I can't imagine there are too many sites that are live these days that are using all 95 languages, but- Yeah

um, yeah.

[00:06:20] Nic: I think, I think the largest set I work on has 20, 20 something, so yeah, it's... And that's very much an outlier.

[00:06:26] Tim: Yeah.

[00:06:26] Nic: So.

[00:06:26] Tim: I, um, I'm getting into content revision for, uh, at App State, and so y- you know, being able to deal with different versions and also being able to visualize all of that, I mean, I'm looking a lot at different interfaces and stuff like that, and I, I do love how visually...

Like, this is a beautiful module. I lo- uh, uh, I... Maybe I'm just because of, uh, uh, the, the developer kind of focus on it and, and, you know, with the Git sort of view. It's, I, I really love this, this new way of displaying revisions. Um, we don't do as much translation, but I still really like the way in which we have different branching off capabilities with this.

So, I mean, props to, to this developer. Also, 2019, so does that mean... Can, can we, can we assume this was not Vibe coded?

[00:07:28] Nic: Uh, that's an... We'll talk a little bit more about evaluation schemes, but I will say the original module wasn't. I know that, uh, Deadman is, um, uses a lot of AI, so it's just in looking at the commit messages, they, um, they follow that pattern.

So I would... I, I, I don't know if I would classify it as Vibe coded, but it's very heavily, um, using AI tools, uh, to manage this version.

[00:07:56] Tim: Mm-hmm.

[00:08:01] Nic: Well, Martin, as always, you find interesting modules of the week to chat about. I think this is one that, um, the, the one thing I wish this would do, which it clearly says that you can't, but seeing that history, it's not the kind of thing that I think I would want to have on permanently. Like, it feels like an audit trail type thing.

But if you can't track the history of them without having it installed, maybe it's worth, uh, testing out and seeing if it's something you wanna have in the background, so if you ever need it, it's, it's available. Um, it'd be interesting if you could just keep that piece of it and nothing else until you need to display the information too.

[00:08:35] Martin: Yeah. Yeah, that's an interesting idea. If there was kind of more of just like a tracking only mode that you could keep it in to sort of minimize any potential load on the server. Um, it does kind of feel like there's probably, you know, a subset of modules that are really gonna find this, like, uh, completely compelling in terms of it really adding substantially- Yeah

to their workflow. But I feel like people that are in those use cases are probably gonna really love it, so.

[00:09:00] Nic: Yeah. Yeah. It's, it's one of those things where if you don't need it, it... Most people probably don't need it, but the ones that need it really need it, and this provides a nice visual way to represent it.

Like I said, if may- maybe there's a, a way to present it in a less developer centric way for, you know, for editors at some point, uh, if the data's there. So

[00:09:19] Tim: yeah,

[00:09:20] Nic: be interested- For sure ... to see where this goes. All right, uh Yeah, one of the things is, uh, you know, this is still a new tool for me. I still need to figure out the best way to switch back and forth between the different, uh, environments.

So thank you for... Thank you again for your patience. But yeah, this is going to be another one of our, uh, Off the Cuff. This is the 13th time we've done it. Um, we've also had, we used to call them This and That, I think. Um, I don't know if the, we count those in the 13 or not. Maybe that's, uh, some homework for myself to do, is go back and figure that out.

But, um, we have, uh, some various topics for you guys today to chat through. Um, the first one is, I, I think Martin, you were the only one of us that made it to Rotterdam. Uh, how was the vibe? What was it, what was it like? What was, how was DrupalCon?

[00:10:14] Martin: I thought the vibe was great. I mean, it, it was interesting. I think somebody had made the comment, I, I haven't had a chance to completely verify this, that this was the first time that DrupalCon Europe was in a hotel instead of a conference center.

Oh. So a little bit smaller venue, but, um, you know, I think a bit more intimate vibe and I feel like if that lowers the cost, makes it easier to, to do certain things in terms of like, like I know conference centers oftentimes are s- more strict about using their catering or different things that, you know.

Things that allow us to maybe be a little more flexible, um, as a community in terms of how we do that, I would see that as a huge positive and, and, you know, everybody that I spoke to had a really great time at the event. There were lots of good conversations. Um, I actually met Geek Merlin, uh, for the first time.

Oh. Yeah, so, so that was pretty fun. Uh, so yeah, there's, there's always those kinds of sort of, you know, hallway track type of, um, things that happen at Dru- DrupalCon where you sort of bump into folks and, and get into, to interesting conversations with people. So really loved all of that. Um, the, uh, it was interesting, the Acquia booth this year was actually made out of all cardboard.

Yeah, I saw that. And kind of the message was, you know, um, instead of putting together a really fancy booth, we did something really basic and basically used the money saved to donate to Drupal associations. So would love to see, you know, other, other exhibitors kind of follow that pattern of, of seeing like, you know, still have a booth, uh, still make it impactful, but, but make it more about the community and- Yeah

and what we can all do to sort of help Drupal more. So, so that, uh, was pretty fun. There was actually not one, but two AI summits. So in addition to sort of, you know, there was a higher ed summit and a couple of others, but um, there was an enterprise AI, AI summit that was really focused on bringing in not just people from the Drupal community, but trying to have sort of, you know, marketing and senior leadership folks from outside the Drupal community.

Yeah. So I thought that was really cool. Uh, they actually had that on a boat, which I thought was an interesting choice.

[00:12:13] Tim: Oh.

[00:12:13] Martin: Um, so you know, of course the Gilligan's Island theme was playing in my head when I heard about that- ... uh, aspect of it. But, um, I was actually at the Dev.ai summit and, uh, and so that was a great experience.

Uh, it was interesting with sort of the two tracks to, to really be-- have the conversations kind of focused for the specific audiences. So at the Dev.ai Summit, I actually... I thought it was great that it was, you know, a lot of them were very in the weeds technically. I gave a talk called, um, you know, Moving From Developer to Code Director, sort of talking about how AI, um, tools can sort of shift, you know, the, the approach that you take to development and, and some of the things that shouldn't shift.

Um, and that was well-received, but I think it was probably, like, the least technical talk of the day. So, um, lots of smart people there, uh, sharing their thoughts and, and really enjoyed that. Yeah. And then of course we did a Drupal in a Day at the end of it. Um, and that's always great. It was, it was interesting that for this one, a number of the attendees were actually-- had already sort of been hired as interns at local agencies.

And so for them it was not kind of an abstract- Yeah ... like, "Maybe I'll use this someday," but like- Oh, wow ... teaching them things that they're gonna start to use right away. And I think that's, y- you know, I think- Wow ... the exciting thing for that is that for them, you know, it's potentially the launching off point for a career as opposed to, you know, just something that, that maybe they'll, they'll use, so.

[00:13:34] Nic: So, so there-- Uh, seeing a lot of the Drupal core issues flowing through, one of the big topics that I noticed, and I'm, I'm curious if you've heard it, heard any of this buzz, is, um- Start... There's a lot of interest in getting Drupal ready for app ser- um, I keep calling them app servers for, like, FrankenPHP.

So long learning persistent app servers. And, you know, there's a lot of work to do, but I think it, it was a, a very, very common topic with a lot of the core committers that were there. Is that something that you heard, uh, heard around the venue, or is that something that was maybe in a, a different track than you were on?

[00:14:12] Martin: Yeah. It sounds like that's something that was probably on a different track. I did see, I think it was just before DrupalCon, that somebody had released kind of a, a local environment that you can run, run Drupal inside that's actually based on FrankenPHP. So, you know, if there's still things that they're massaging in Core, I'm not 100% sure how, how easily that works

[00:14:30] Nic: or- Oh, there's a lot of stuff to do in Core before it's really ready, but, um-

[00:14:33] Martin: Yeah

[00:14:34] Nic: people are starting to really identify the nitty-gritty. So, like, uh, to give our listeners a little bit of background, FrankenPHP, instead of spinning up a new service for each proce- or each request, um, it can have a process that's running for a very, very long time and just, you know, so it can reuse a lot of resources.

But there ends up being a lot of problems with things like static variables that are caching things because you need to... You just... It's not that you don't want to cache them, because it's kind of part of the point of having a persistent server is that stuff is already cached, but also you need a way to clear that when you need to when something changes without...

'Cause you're not gonna get a new request in a new, um, new environment. So there's a, there's a lot of work going on in identifying all the things that need to change. Um, some of them are on the container, some of them are on various services. Um, but, um, I saw a lot, a lot of issues coming in around it, so I think, uh, I think maybe in the next year or so, we'll, we'll get good support for that, which, which will be interesting.

[00:15:37] Martin: Yeah, I mean, I think even some of the work that had, uh, been done around making Drupal support, you know, fibers and different things, you know, sort of has inched us towards that. But yeah, it's great to see that there are people sort of more actively working on, on getting that addressed specifically, 'cause I agree.

I think there's a lot of excitement around things like FrankenPHP and, and if that's, you know, one of the, the tools that people can use to, to make Drupal better suited for kinds of applications where sort of the standard PHP is maybe, um, not quite up to, to what, you know- Yeah ... those applications need, then, then I think that's exciting for sure.

[00:16:16] Nic: Yeah. All right, Tim, I think that you, um, I think, well, I think all of us have, but you listened to the Driesnote and there were a couple things that really excited you about that. You wanna talk a little bit about, uh, what came out of the, the Driesnote for

[00:16:29] Tim: you? Yeah, definitely. So first off, I mean, the graphics.

Big props to the team that put together that. I mean, I, I think that this, this is a beautiful pr- presentation. This was my first one that I've watched, um, remotely, you know? And, um, so that was really great. Um, I love the, all of the demoing that came out of it. Um, I think that's really what we need, is that we need, um, ways to demo all of the latest and greatest stuff that's coming out.

So, um, there was a awesome, um, a lot of different awesome, uh, videos that I saw on LinkedIn, um, that really could just stand alone by themselves. I think that's really great, and I think that's, um, you know, being able to see content that can live on beyond just the Driesnote was awesome. Um, you know, I, I think, like, for me specifically as a new developer, the talk louder about Drupal part, the way that he ended the, um, the Driesnote was, that was really impactful.

I think that was really, really cool. You know, the Drupal advocacy program really starting to encourage folks just to start to post online about Drupal and start to just create this buzz. You know, we know that, um, LLMs will scrape Reddit, they'll scrape Quora. Um, you know, so they're just really just an average, you know?

And so, so much of the Drupal stuff that's out there, it's like, ah, well, Drupal's just hard to use. There's a learning curve. But, you know, being able to, like, really amplify all of, like, the new stuff that's going on, all of the different problems that we're solving. I think, you know, starting to expand the contribution system to actually include going on a podcast, and that a podcast that's not yours.

And, you know, I think that's just a really, really inspiring way, um, you know, as we've, we've start into, started to think about- What is contribution? Um, you know, who's a maker, you know? Um, and I think that it's, um, it's really cool just to really start to broaden our horizons with that. And so, um, yeah, I was really inspired- I,

[00:18:53] Nic: I think, I think the interesting thing too is, and this is something I've been hearing for the last six or eight months, but it's becoming more clear, is the focus on talking, like, talking about the positives rather than the hedging it.

'Cause that, that is something that I noticed. A lot of people say, like, "Oh, this part's difficult, but this is great." And they're like, no, just talk about the great stuff because w- Exactly ... first of all, we're shaving away a lot of the friction. Like Drupal CMS, I even, even, even if you set aside the use cases that CMS has directly, like there are so many people out there that can use CMS, like out of the box, and it will work perfectly for them.

Like a small marketing site or blog or plumber site or something like that. Like i- if we can get them in an ecosystem, like there's three or four new products that have jumped, um, come up on the hosting side where you can just host it and they don't have to think about it, CMS will cover their use case, and it's a good system for, um, for entering the content.

But if you set that part aside, even just the part that it's allowed Core to slim down, I mean, we, Drupal 12 drops six or eight different modules and themes, and that just gives less surface area for Core to focus on so we can focus on the parts that make every site better. Like the performance, one of the things I really liked about Dries' recent update to the core metrics graphics is it shows the number of queries or the performance that it takes for th- o- over, over time.

So like Drupal 11, the, the increase in performance of the life of Drupal is significant. Like we dropped 60% of the queries on a cold cache, I think something like that. We, you know, the amount of traffic that you can serve, you know, the access control system that Drupal has is second to none. The language system is second to none.

You know, there are things that Drupal does that other CMSs just don't do and can't achieve because the way Drupal was architected from the beginning. And we're, because we're measuring that stuff now, we're getting improvements there. And so having a focus on advocacy where it's like, "Hey, talk about these positive things.

Push that out." And, and to be clear, Tim, we, you know, at least us, you know, we've been giving credit for our guests and guest hosts for, uh, four or five years now. Uh, it took us a few years to think to, to have that light bulb moment and be like, "Hey, wait a minute. Th- we can, we can give contribution credit for that, too."

But having it, um, come from the top, come from the pulpit means that, um, agencies will be thinking about it and looking for that, too. So I think, I think Drupal's about to get a really big megaphone. Um, I think people that haven't heard about Drupal in years are gonna start hearing about all the great stuff that we've been doing, and I'm excited.

I mean, even just the shows we've had recently with, um, Elizabeth and, um, Matt to talk about how other, you know, the PHP Foundation and Laravel kind of handle this, I'm very excited, uh, for Drupal's future. Um, we just need to get the word out, and now there's a direct benefit for, for doing that.

[00:22:01] Martin: Yeah, and I was actually in a session where it was sort of, uh, trying to remember what it was called, uh, Drupal CMS update, something like that.

But Angie Byron actually gave, her segment of that was, was all focused around sort of, you know, the new focus on advocacy. So, um, you know, anybody that knows Angie or has been around the community for any period of time is probably really excited that, you know, she's gonna be spearheading some of that work, and I think she's a perfect person to do that, so.

[00:22:28] Tim: Yeah. And I'm, for me, DevRel, like, that's a new term for me, you know? So but I think that that's really interesting also of, like Really communicating, really celebrating, really, you know, um, and also giving people that career path potentially also. You know, encourage, go into other events that are not Drupal specific, talking about Drupal, getting this cross-pollination, going on a different podcast, you know.

I think that's, that's what's really been cool about, you know, um, like you were saying, Nic, about getting other people, uh, like Elizabeth and Matt on here. It's, it's, it's really, that's where you get a lot of excitement. And, um, yeah, and I, I'm sure that, you know, Matt's gonna s- he's gonna be talking about Drupal a lot more since he was on this podcast.

Yeah. Um, you know, it's, uh, yeah. It, it's, it's really cool. I think that the vibes, generally, I think that's what I took away as, as, as a, as a, um, a viewer. The vibes are really- Yeah ... good right now in the community, and I think that's what we need. And, um, you know, I think this is gonna have a lot of synergy.

And, um, so that, that was, that was just really cool, um, to be able to see that.

[00:23:50] Nic: So let's, p- so we have a question from Roger on LinkedIn. Uh, he says, "Hello, everyone." And he Uh, it says that he's been telling people about Drupal CMS, and people are still requesting WordPress, and wants to know if that, you know, why we think that is.

I mean, I, I think part of it is historically WordPress was a lot quicker to spin up. Um, I think part of what we need to do as the Drupal community and part of the advocacy program is talk about how much faster CMS... I think there's two sides to it. One is spinning up CMS is faster than spinning up WordPress.

I mean, you can... You select a couple recipes, apply them, and within 30 seconds you have a whatever full feature recipe that you chose. It is faster. Um, we, we still are working on making the hosting part simpler. Like I said, I, you know, not to name names, but there are a few projects that have launched within the last month or so that make spinning that up very, very easy.

And so I think I'd recommend that you look at those. Um, and I think the other thing you wanna talk about is kind of there's, there's two really big things on the long tail. Drupal allows growth that WordPress will really struggle to, and Drupal has un- the underlying API system that WordPress will struggle.

Like, even things like responsive images, right? The responsive image system in Drupal is orders of magnitude, um, more powerful.

[00:25:20] Martin: Yeah, and I think the other thing is that at least from what I understand, in the WordPress world, there are lots of plugins that only work with certain themes because, you know, there's so much business logic kind of put into the theme layer.

And so it's- Yeah ... in some ways WordPress is not, you know, one ecosystem, but, but many because it is- Yeah ... a bit fractured that way. Whereas with Drupal it's a lot, you know, for the most part, you know, you can use any module with any theme. You can use combinations of modules. It's pretty rare that there are ones that, you know, don't play well together, those kinds of things.

And so it really- Yeah ... is much more composable from that standpoint.

[00:25:56] Nic: Yeah, like it, to, to your point, like even if you stay out of the theme side, like a m- Gravity Forms is like the bigger equivalent for a web form, but it's a paid module. There's, there's a couple of different ones like that, and each, each plugin in WordPress has to decide which ones they're gonna integrate with and may support them differently.

But I, I was, I was also gonna say the other thing to keep in mind is, um, I think the way, um- One of the big knock on-- One of the big effects of AI right now is there's a significant increase in the number of security, uh, releases both for WordPress and Drupal. Um, one of the things that, um, I would consider talking about with your clients, Roger, is, you know, the, uh, Drupal, even though there's a lot more to track, they're still scheduled for Wednesdays, so you can plan around that time.

I, I... It was very stressful a couple weeks ago with all the web form. I mean, there were 30 something things like that. We still need to build tooling around how to prop- quickly update and handle that. But, you know, Wednesday I have to block off the afternoon to update my clients. With WordPress, you don't, they, they don't have that, um, schedule yet.

I, I hope someday they'll get one. But, you know, in the last two months, they've had a release on Friday at 4:00. They had a release on Thursday at 5:00. They had a release on Tuesday. You know, which it, it's good that they're updating and providing these backwards compatible, uh, updates so you can keep everything secure.

But from a scheduling standpoint, um, you kinda have to be ready to, or you have to have auto updates on, right? Which You know, sometimes breaks things, sometimes doesn't. So you wanna, you wanna kinda keep an eye out for there. But yeah, I would, I would tout the, the long tail. You know, getting Drupal CMS up and running is as easy or faster than WordPress, and you have the flexibility to kinda grow into whatever you need to grow into with Drupal.

And-

[00:27:55] Tim: Yeah ...

[00:27:57] Nic: you know, WordPress is more exponential effort to get the, the-

[00:28:01] Tim: And I started on WordPress, uh, at a community college, and then I moved to four-year university, and we have Drupal. Um, I will say that with WordPress, with the module system, I mean, or the plug-in system, I mean, a lot bigger, but really freemium, freemium hellscape almost.

Yeah. But those, those are all these hidden costs, right? I mean, of course, developer time is also a cost as well. Yeah. But I really have appreciated the, the strength and the robustness of the contributed module system.

[00:28:38] Nic: Yeah. I, I, I will say one of the things that I've been battl- 'cause I do have some clients on WordPress, um, and they just...

Dru- one of the things that the Drupal ecosystem does, and this, I don't know if this really works for your case, Roger, but I'll, I'll just kinda comment. It, it's just something I've been battling with, so it's, it's worth letting people know. It's something to think about. But Drupal generally has standardized on a way to do deployments, right?

You can modify it. You can make your system work. You can do what you wanna do. But, um, for example, using Composer as a way to deploy and having a write-only hosting system, which is more secure, is kind of the, the fact Drupal is built to handle that. WordPress, um, a lot of the... Like, for example, Wordfence, which is one of the plug-ins that I really would recommend people look into because it's a, it's a firewall, and, uh, it helps keep track of which plug-ins need updates and, and we're...

Like, it's a good way to get notified when an update needs to happen on a site. But when you have the premium version ex- it expects to be able to write to itself in a bunch of directories, and so you have to, like- Bend over and they don't have Composer integration, so you have to bend over backwards to get that to work on a system like, um, Acquia or Opsun or even Pantheon because they're all read-only at runtime.

Um, so there, there's even just things like that that are architecturally different from a

[00:30:04] Tim: product standpoint,

[00:30:05] Nic: um, that just take, uh... I, I sleep better at night having a host that is read-only, right? It's just, you know, it's just safer. Um, and WordPress, you can get, you can work around it. There are ways to build around that, and once you know how to do it, you know how to do it.

You can copy that, but it, it takes effort to... E- each plugin you have to kind of discover yourself if it's gonna support Composer or gonna expect to be able to write to itself. Um, I see a note here about Rosetta Sprint. I didn't actually see anything about that. What, what, what was the Rosetta Sprint?

[00:30:42] Martin: So in the Dries note, it was, uh, mentioned kind of, uh, briefly, but it's a- Oh, I missed

[00:30:46] Nic: that

proposed

[00:30:48] Martin: gathering of sort of bringing together people that are working on different elements around sort of, um, you know, like tool API. I think, um, as an example, he was talking about how, um ECA and Flowdrop and Maestro, you know, are all kind of, um, modules that, that have different strengths, but, you know, to an outsider, you know, look like they do-- they have a lot of overlap.

And so, you know, making sure that we're not duplicating effort, uh, that all of these things kind of play nicely together and, um, you know, really just making sure that as a community, we're doing everything possible to make sure that the work that we're doing is, you know, as optimized for not just sort of, you know, people using Drupal directly, but increasingly people who may be, you know, updating their Drupal site through an AI agent, you know, either even, you know, on like a, you know, voice, uh, type application, you know.

So sort of saying like, um, you know, update the pricing on the blog post that we published yesterday and having an AI agent, A-AI agent that can go in through MCP and make that change and have a stage or even publish that. I mean, you know, obviously everybody's comfort level there is gonna be a little different, but, um, some of the use cases are pretty interesting.

So Dries, I think in the, in the Dries Note showed an example of using a local agent to, to look for an image that was in the media library that he has on his own blog. And so to get that running, you know, I think he said it took like 1,200s li-lines of code to take sort of, you know- Yeah ... existing services and make those properly exposed out to the MCP server and, and that s- is what drove one of the other things that I thought was really exciting in the Dries Note, which is this new sort of tool annotation, so that if you have some of those existing services, you know, with, with just a few annotations now, those can be exposed out so that they can, you know, uh, be leveraged using those kind of outside in AI agents.

And so, you know, I thought it was kind of inspiring that he, he made the call to sort of developers and maintainers within the community to say, you know, if you have modules that could be useful to those MCP agents, then, you know Figure out ways that to just, you know, add those annotations in so that those can now be exposed as, as tools to the MCP agent or MCP server.

So, I, I, I have started to look at my own sort of list of modules and, and try to figure out, you know, where there are some potential use cases. But I think that'll be really exciting to see if we can have, again, you know, not just sort of, uh, the Drupal AI, you know, core module and, and some of the pieces that are maintained by, by the, the AI initiative team, but sort of, you know, the broader ecosystem start to have more support for those, you know, could be really transformational, I think.

[00:33:48] Nic: Yeah. I, I must have missed him calling it the Rosetta Sprint, 'cause I remember that, that whole discussion, but I, I didn't remember hearing Rosetta.

[00:33:56] Martin: Right.

[00:33:57] Nic: All right. Speaking of Rosetta, which only makes me think about, uh, languages, uh, there's some big news in the Canvas sphere, too. Um, what's the, what's the buzz around Ca- Drupal Canvas?

[00:34:11] Martin: So the, the big news on the Canvas front, you know, one of the things that a lot of people have been saying was the, probably the single biggest piece that's been holding them back from adopting Canvas was really its previous inability to support multiple languages. So- Yeah ... as of the latest Canvas release, there is a symmetrical translation.

I think a- asymmetrical, uh, translation is also on the roadmap, so the ability to actually have slightly different layouts, as an example, between languages. So today it's symmetrical, meaning, you know, all of the different components need to be the same, but the, um, the properties for each component can vary by language.

So that's pretty exciting and, and again, something that will mean that there are lots more, you know, teams and organizations that can start to adopt Canvas. Yeah. Uh, the other thing that we saw with Canvas at DrupalCon Rotterdam was, uh, some really exciting new tools around integrating with headless front ends, so-

[00:35:08] Nic: Yeah

[00:35:09] Martin: within the, the Drupal tooling now, you can s- you can basically say, "Okay, I've got this fresh install of, uh, you know, Drupal CMS, and I wanna be able to, to use it with a headless front end," and basically use Drupal to spin up the front end, and then it's sort of like pre-integrated with your Drupal back end, so now you can go ahead and start to, you know, build out all the things.

[00:35:31] Nic: I, I was actually... Ha- have you tested that piece at, at all? Um, 'cause I, I have a project coming up that might need some headless stuff, and it's been a long time since I've worked on an actual head- headless project. And so I was curious if it was worth spinning that up to te- like, does it work with any headless architecture, or do you have to use Astro or...?

[00:35:52] Martin: So I think there's, there's, uh, five that are supported. So let me see if I can remember them off the top of my head. So there's Next.js, there's Vue.js, there's Astro.

[00:36:04] Tim: I think TanStack.

[00:36:05] Martin: There's, there's one that I keep forgetting. What... Sorry, what's say that?

[00:36:08] Tim: Uh, TanStack.

[00:36:10] Martin: TanStack, yes. And then Angular was the one that they just

[00:36:12] Nic: added.

Oh, Angular. Yeah, that was the one they added while, like in between the demo and the... Yeah, you did the voiceover- Yeah ... for that part, right? For the demo. I

[00:36:19] Martin: did the voiceover for the multilingual part. Yeah, so.

[00:36:21] Nic: Oh, the multilingual part. Yeah, yeah.

[00:36:23] Martin: Yep.

[00:36:23] Tim: Very good

[00:36:23] Nic: voiceover. Yeah, uh, do you have any experience with Canvas, Tim, as of or-

[00:36:29] Tim: Oh, gosh,

[00:36:30] Nic: no

have you not used it yet?

[00:36:31] Tim: Not too much. It's really just been in small little snippets. Um, but I, um, I, I love, I love it. I, I think I love the idea of it. I mean, I think that's exactly where we need to be going. Um, it's a really good complement to, you know, SDCs, you know. Um, and, um, yeah, Mike Anello did a really great, um, a really great talk at Drupal Camp Asheville about SDCs and creating all of that.

Um, and I think that it's, um, it's, it's, it's, it's really interesting how, um, with, like, headless, you know, all of the different... It, that's, that's, that's one of the, uh... I, I'm, I'm new, so, you know, um, hearing headless and all that, it, it's, it's a new concept to me. But, um, you know, some of the other sort of ways that I've been thinking about is, like, I...

Digital signage, uh, that was one thing that, uh, uh, there was a Pantheon talk that, that, a we- web talk that I sat in on, and they, they had mentioned how you could, you could have a headless site, but you could also connect it to your digital signage. And so we, we have, um... I, I don't work with the digital signage at the university, but I've heard it's quite, mm, there, there's not a lot of developer control that we can really assist from, from the web team.

So, um, but, you know, you think about every single, uh, digital sign, and it's basically just, you know, like a TV. Yeah, I mean, there's,

[00:38:03] Nic: there's some famous Drupal integrations that, um, like with, uh, NBC, I think, for... And was it the, the college football? I think it was, where they run- Pac-12

[00:38:16] Martin: maybe, yeah.

[00:38:16] Nic: Yeah, Pac-12.

I think they run a lot of their TV chyrons off of Drupal and digital signage and things like that. So y- yeah, you can use Drupal as a, a way to feed. I mean, that's one of its long-running strengths that we should announce from, from the advocacy program. Yeah.

[00:38:32] Martin: Yeah, I think one of the biggest examples that I remember hearing about was the MTA, so the, you know, New York City sort of Metro Transit Authority.

[00:38:39] Nic: Yeah.

[00:38:39] Martin: Um, all of the displays on every s- uh, subway platform that said, you know, next train arriving in whatever, four minutes. Yeah. Um, all of that was... Those, those were locally running headless apps that all pulled from a Drupal backend. Hm. So that was, you know, one of the highest profile sort of headless Drupal implement- implementations that I, I think I'd ever heard about, so.

[00:38:59] Nic: Yeah. Uh, I, I will say, I think n- probably more than 90% of installs still probably want to use a traditionally coupled Drupal site. There's a lot of performance benefits and things that you can get, but in certain cases- Headless does make sense, and so, you know, having integration somewhat tightly coupled integrations with, like, the new content builder canvas, right?

I think is, is a huge benefit for Drupal. Um, yeah, so maybe I'll spin that up and test it. We're, we're really trying to talk to the client to figure out what... It, it's a new client for one of my clients, and so we're trying to talk through their use cases and why they're looking for headless to see, uh, if it's one of the use cases that's really a strong, uh, strong indicator for Decoupled, but it's good to know that there's new tools for that too.

[00:39:51] Martin: Yeah. And, and just to quickly answer your earlier question, Nic, I haven't personally used the installer yet, but I did see it demoed live at Decoupled Days back in Montreal in August, so,

[00:40:00] Nic: uh- Oh, okay ...

[00:40:01] Martin: yep.

[00:40:01] Nic: It's been around, around for a couple months now. Um, okay. We also have the Drupal 12 beta came out.

That's another big announcement. I know the team put in so much work to get that ready. Uh, I think, uh, Mike Herschel, I don't know how much time he's putting, uh, he's put in getting, uh, the default admin theme ready. Um, I think he was tearing his hair out for a little bit there trying to get that ready.

And then, um, a lot of people put in a lot of work to get, uh, the four or five other modules like toolbar and search ready for removal. Um, so yeah, the beta, beta's out. It's ready for testing. You know, get your, get your modules ready and do test updates to see what works and what doesn't, and file bug reports if you find something that needs tweaking.

[00:40:51] Martin: Yeah, I mean, that is part of why I thought it was particularly apt to feature a module of the week this week that has Drupal 12 compatibility, but hopefully that's something we'll see more and more uptake so that by the time Drupal 12 does have its first stable release in December, that there's, you know- Yeah

a solid, uh, set of modules that, that sites can run right away without having to sort of do any kind of weird patching.

[00:41:15] Nic: Well, if I, I'd like to highlight, so, um, Björn Ralla i-is doing a lot of automated work with Rector, with the Rector bot, the Drupal update bot, to, like, fix a lot of these things. But Nod, um, Theodore also put together a, I don't know what you'd call it, a data set on, uh, deprecations in contrib.

So he basically hi- he wrote a table that gets built that will say like, "Hey, Drupal just dep- Drupal Core just deprecated this API." It will then search through all of contrib and identify how many uses there are for that one, and that will help Björn prioritize which ones need to not... 'Cause for example, if there's an API that changes that's just like renaming a method And only one module uses that.

There's no need to write a rector rule for that to... Like, it would make it easier, but that's more work for Bjorn and more s- tests and things like that. You know, it doesn't make sense for him to write something like that. But if there's an API that changes that affects 50% of modules, well, that's a really...

Or, or like the, uh, um, the hook migration stuff. Like, I think there's a bug right now that I need to work on with him. But, like, many, many, many modules m- use many, many, many hooks. So having those automatically convert, huge benefit. Um, so yeah, having, uh, having- And

[00:42:44] Martin: I will say n- not just sort of convert to the new, um, you know, the new paradigm of, of having those as classes, but also even as part of the, the automated, um, you know, patches that are provided still have the backwards compatibility.

I thought, you know, to me that was- Yeah ... really impressive and, and, you know, definitely valued.

[00:43:05] Nic: Yeah, we're do- we're doing the same thing for 12 that I think we did for 11, which is version 12 and 11.5 are exactly the same version in Drupal. The only difference is all of the deprecated code was removed, right?

So if you get your site working in Drupal 12, uh, Drupal 11.5, it will work on 12.0, assuming that all of your modules have removed the deprecated pathways. But the, the actual work to get there should be pretty, pretty straightforward. Um, I just wanna also highlight, uh, Rajab mentioned that, uh, Drupal 12 needs 8, PHP 8.5.

That's true. That's one thing I have been running into with clients as they're updating to Drupal 11. We've been trying to bump to 8.5 support at the same time, and I would say half of them had no problem, half of them decided to downgrade to 8.4 because a lot of contrib still hasn't gotten... Um, mostly it's just like, uh, implicitly nullable deprecations in 8.5.

Um, m- I don't think... I, I think I've only seen one site where something actually broke on 8.5. Um, but yeah, you're right. The minimum required version of PHP is 8.5, and I think a lot of... I, I think his point is that a lot of, um, modules aren't really paying attention to that. Um, so they're, they're saying they're Drupal 12 compatible, but they're not testing against 8.5.

So we should try to get the word out about that too, that if you're marking 12 compatibility, you should really be dropping... You should be supporting 8.5 as well, which means that you should probably be dropping 8.4 and below, which means you should stop supporting 10

So although, wait, does Drupal 10 support 8.5? Maybe it does. So maybe I was wrong there. I'll, I'll have to look that up and I'll put it in the show notes. All right, so before we wrap up, I just wanna spend a few minutes. This is something that's been on my mind, um, which is, uh... So I've been thinking about this a lot over the last month or two, which is how, if, or maybe not how, if I need to change how I evaluate modules nowadays because...

And I was thinking about how module evaluation has evolved for me. So like when I first started building Drupal sites, I didn't even evaluate modules. I would just install it. Sometimes I would try to install a module that didn't even support the version of Drupal that I was working on. You know, then I very quickly learned that, hey, I need to check to make sure that it supports the Drupal 5 or Drupal 6 site that, or 7 site that I'm working on, right?

And that was it. Like I would, I would just install it and see if it worked, right? Um, then I started to, um, maybe a couple years in, my evaluation changed to, uh, are there more than one-- is there more than one module that does this kind of thing? How do they compare to each other? And then I started looking at things like stable release, how frequently it's updated, how often they have releases, what, you know, what versions of Drupal does it support?

Um, who is the maintainer? What's their track record? Um, and now I'm starting to, um, and, uh, you know, and more recently, things like does it have security coverage, right? Is, you know, sometimes you can get a module, uh, sometimes I'll install a module that doesn't have security coverage, but if there's a module that provides security coverage, I'll prefer the security coverage one over the non-security coverage.

Um, something that I'm... We were chatting about this briefly before the show, and something that I'm starting to add is, um, not just... I have mixed feelings about this because I'm finding that more and more people are marking their modules as supported un- in, uh, under security coverage, right? People used to just keep a module in beta or alpha forever and never do a full release.

And more recently, I've noticed more and more people are marking it as a full release. But I almost feel like we need, um, as a community to start using the, the fully maintained, um, there's like a status you can add, like this is partially maintained, looking for maintainers. I think we need to start thinking about using that more because I'm seeing, you know, some people are doing a full release and they're, they're supporting the module.

Like they're replying to bug reports, they're adding new features, they're tweaking it. Some people are marking it as ready and then never looking at it again, which is, which is fine. It's their prerogative. They're, like, this is open source, this is volunteer. But as somebody evaluating it, I think it's good to see what the support plan is.

Like it's more, it's more important Um, and I'm curious if you guys have been reevaluating how you evaluate modules recently or if nothing's changed.

[00:47:58] Martin: Well, it's funny because one of the signals that I used to use was actually the size. So it used to be when downloading was kind of one of the-

[00:48:06] Nic: Oh ...

[00:48:06] Martin: the paths to install it.

Like if, if I was looking at two modules, and I had kind of like a simple thing that I need to solve, and one was like 80K and the other was like two megabytes, I'm like, "I'm gonna go for the smaller one."

[00:48:18] Nic: Yeah.

[00:48:18] Martin: Because, you know, there, there's probably fewer things to go wrong. Um, and so, you know, once everything kind of sh- the emphasis really shifted over to Composer, you know, that was actually a thing that I kind of missed seeing.

Um, so, you know, but th- that, that goes on. I mean, I... In terms of the signals, it's, it's an interesting question. I mean, I think one of the things that you mentioned before is, you know, there are definitely people that have differing comfort levels around, like, the maintainers' use of AI tools as an example, right?

And right now we don't... Some, some module on the project page, they may disclose, you know, AI tools are used in the, the development of this, but other people I'm sure are, are using it and, and don't feel like they need to disclose it. So, you know- Yeah ... having sort of a community stance on what's the responsibility of the maintainer, I, I do kind of feel like over time we're probably gonna see the, the number of modules on which AI tools are never used kind of getting smaller and smaller.

I mean, you can even talk about the, uh, you know, the rector patching that, that we talked about for Drupal 12. A lot of the rules that went into that are, you know, AI generated. And so I mean- Yeah ... if you use a module where you didn't use any AI tools directly, but you applied some of those rector patches, you know, how, you know, can you still say- Yeah

that there is no, you know, AI went into the, the maintenance of that? I don't know. It's, it's a bit of a slippery slope argument, I guess.

[00:49:40] Nic: Well, well, I, I will say I, I do distinguish, um... Well, yeah, so let's talk about the AI maintenance piece because that is one of the things that I think about. I, in my mind, using AI to generate a rule Is different than using AI to generate directly.

So for example, um, I mean, I, I have some questions about the scale of rule. I think that's one of the reasons why what Nod is doing is great, 'cause it allows Bjorn to target more closely which rules are worth approaching. 'Cause yeah, he can better QA 10 rules that he creates versus 300 rules, right? Um, but for example, I would trust an AI-generated rule to convert hooks because you can compare the bo- before and after output more easily than I would trust somebody that pointed AI at a module and said, "Hey, convert these hooks from procedural to OP."

Because o- one of the things is, is the process for a Rector rule is gonna be consistent. Like, if you run a rule today and tomorrow it's gonna pr- provide the same output, it's idempotent, right? The rule itself may change, but you can, you can compare the changes. If you're using AI to do the actual conversion one time to the next, it's gonna use the same number of tokens relatively, and it's going to, um, probably have slightly different output.

So, um, for example, when we converted Core, I spot checked dozens and dozens and dozens of hooks and different types of hooks, and once we got it working, each time I ran it, I was confident that it was giving the same exact output every single time, right? Barring upstream changes, like if they changed a hook implementation somewhere, obviously that was gonna change, but I didn't have to worry about, well, this time it converted the 26,000 lines this way, and next time it did it another way.

Also speed. It took... By the end of that, Rector took a f- it was a five-minute run to convert all of Core. Whereas running u- using an AI agent to convert all of Core would take two, three, or four hours, five hours even now. So I, I put those in different buckets, but I, h- I think really what I'm, what I'm thinking about isn't necessarily...

I mean, it'd be good to know people are using AI to maintain, right? It, it's a, it's a factor. But really it's more about scale, I think. Because, um, somebody that's using AI to assist themselves writing tests, writing code, what- whatever is one thing, but I've seen modules recently where there's, they have six, 700 commits a month Are they able to...

From one person, right? Are, are you really able to understand what's going into that project at that scale, right? Some people, th- I'm sure there's some people out there that can. Most people probably can't. But that also means if I'm using that module, how much of it is changing under the hood every single time?

If they're doing 600... If they're doing six releases a month, eight releases a month, and they're doing 600 commits, that means every single time I update the site, that module's gonna have an update, and the release notes is gonna have 200 issues for me to look at, if they're even doing issues. C- 200 commits for me to look at.

How... And so, and I'll... And A lot of those commits are thousands of lines of code, right?

[00:53:10] Tim: Yeah. Y-

[00:53:11] Martin: yeah. So I would say... Sorry, you go ahead, Tim.

[00:53:15] Tim: Oh, no, no, no, you're, you're good. I was gonna go off on a different tangent, so. But you- you've got something to go on.

[00:53:20] Martin: Well, I, I guess what I was gonna say is, to me, the, um, you know, the, the commits that are thousands of lines of code i- is, in a way, probably more alarming than, you know, the, the sheer volume of s- Like, if it was lots of small commits where, for whatever reason, like, you know, they just want a lot of granularity.

Like, sometimes I'll make a one-line change- Yeah ... but I'm like, "I'm gonna put that in a commit," just so that there's sort of, like, traceability- Yeah, yeah ... around why that change was made. So I think, uh, the way I look at it is that AI shouldn't change the, the goalposts in terms of, you know, best practices. I think, if anything, using AI tools should remove the excuses for why you don't follow best practices.

And so e- you know, particularly things like, as you say, you know, commit size, you know, like, there's no reason why you couldn't break that up into s- into smaller pieces of work.

[00:54:12] Nic: Yeah.

[00:54:12] Martin: Uh, so that, you know, when somebody goes back, they can underst- they can get their head around, like, you know, what were the- Yeah

pieces that changed and why. And so, yeah, I, I think there's, there's definitely a lot to be said for, you know, wha- looking at those kinds of things because I agree. Like, if, if people are, you know, very often completely overhauling the code, that, that should definitely be a sign- Yeah ... of concern. I would agree on that front.

[00:54:35] Nic: And, and, and for, and I know we're almost out of time, so do you guys have a couple of minutes if, if we, if we go a little over? Tech's- Yeah ... we started a little late. So, um, I, I will say, for a concrete example, too, right? I, 'cause obviously I'm not reading every single commit of every single module that I'm updating.

Um, but it's, it's generally about scale. But, for example, security updates I almost always do, right? If, if a module has a security update, I pretty much always look at the commit for that module, even if it's just to understand, hey, what did they do wrong? Is that something I'm doing in custom code? Is that something I should watch out for?

And if we use, you know, obviously I think, I think Jacob is one of the premium developers in the Drupal ecosystem. You know, he's, um, very much all in on using AI and, and he wrote a int- very interesting blog post about how he used it for the recent, uh, spate of security issues. But I look at that cha- There's, it's a 2,637 lines added, 161 lines removed.

Like, getting through that to understand... I mean, there's a bunch of like, oh, there's this one thing, we changed all, all that, but there's also a significant number of traits and tests that were updated. So, like, getting through and seeing everything is, is More, it, it becomes a scaling problem at that point.

And like I said, I'm not saying that we- he shouldn't have fixed them that way, or I'm not saying... But, like, if every module starts doing that, how do you keep track of what is going onto your sites? Is that something that you guys are concerned about?

[00:56:17] Martin: Well, so I think, you know, in the Webform example, I th- my impression or my understanding is that a lot of those were done in a more granular way, but because of the way the security release process is, that he basically had to sort of roll those up into, you know, a single set of changes that could be committed all at once so that it could go out as kind of that, that single release.

So to me, it was, it... That was more of, like, a process thing of how they ended up that way, but they were actually done kind of more piecemeal, uh- Yeah, which- ... while it was actually being worked on ...

[00:56:48] Nic: which also makes sense because if he had done them piecemeal, he would... Webform would've had a release every week for 22 weeks, right?

Which-

[00:56:55] Martin: Right ...

[00:56:55] Nic: also would've been an, an absurd amount of work and would've made people question. And who knows? Some, some of the reports might have been in such a way that if they fixed one, it would've exposed the others, so they kinda had... So like I said, I'm not even saying that... I'm not even trying to imply that what he did was wrong.

Sure. But when you start looking at these scales... And, and I'm not saying that I'm considering not using Webform or anything. Like, what I'm saying, in general, when I'm evaluating a module from a developer that I don't know or don't use, if I see, hey, they've had 400 commits this month, that's a, that's a question mark for me now, and it didn't used to.

Well, actually, I... If five years ago I saw somebody had a module that had 400 commits in a month, I would've been like, "What is going on with this too?" But, um, it is something that I've added to my, um, my mental checklist. Like, I'm, I'm going to look at the commit history more often than I used to, um- I don't know where that lands me.

Like, I haven't made a decision on, like, where that factors, but it's something that's been on my mind a lot lately because I've been noticing a lot of modules coming back from the dead. They have a new maintainer, and all of a sudden there's a brand-new major version, and the module's been rewritten out from under itself.

And is that something I want to update to? Maybe, maybe not. I, like, I, I don't have the answer. It's a question that I have Which is, which is always interesting. Yeah. So wh- Yeah ... where were you gonna go, Tim? Oh, go ahead, Martin.

[00:58:25] Martin: No, no. Let's, let's move on to Tim. We've talked

[00:58:27] Tim: a lot. Oh, gosh. Well, I was gonna go fully in a different direction.

But, like, what Nic, what, uh, it was really interesting what you're talking about is how you were evaluating all these little different components, these little different pieces. I've started to also, you know, as we're growing our distro, you know, starting to look at other modules. But I will say that, like, um, one of the things I struggle with is discoverability of modules.

Mm. And so-

[00:58:55] Nic: Yeah, we have maybe 3,000 modules now.

[00:58:57] Tim: Yeah. With easy. Yeah. And so, I mean, 2026, the year of Linux. I have been messing around with CachyOS. I've been doing all sorts of ones. But I've also been on the Flatpak, uh, or Flathub store, you know? Mm. And so I've, I've been interfacing with apps and stuff like that through, you know, the App Store.

And, and Linux is an open source project as well. They have even more for, uh, uh, projects than we do. And so, but- There is a way where I was, I was starting to think about, like, could we start to have some sort of, like, app store type interface where there is some sort of discoverability that's not- Have you heard

[00:59:44] Nic: about Project Browser?

[00:59:46] Tim: I have heard about that, but the one problem- Yeah ... that I have with that personally would be you'd have to know to download and add that to your, your platform. I mean, uh, you know, it's, it's a CMS, sure.

[00:59:57] Nic: Yeah.

[00:59:57] Tim: But I mean, I think that, like, with drupal.org, I mean, that, that, that is kind of a representation of the Drupal project as well, and the discoverability, the findability of that.

Um, I, part of me- Well, the, the- ... should we have an initiative to

[01:00:14] Nic: make that- Yeah. Well, that, well, I, I, I think that's a good point. I... Well, first of all, the initiative is the Project Browser initiative. Mm-hmm. The, the idea is eventually it was meant to be part of core, and I think it still is a candidate to be a core thing because, yeah, you want the discoverability everywhere.

Um, I, I will say part of, like, a flip side of the coin to what you're saying that I've noticed too that I didn't bring up is I'm noticing, and there's positives and negatives to this, but I'm, I'm noticing that people are starting to fill gaps by generating modules, but that means that people are generating the same module multiple times.

[01:00:54] Tim: Mm. Yeah.

[01:00:54] Nic: Um, that... So people aren't doing... Like, one of the reasons why, I think one of the strengths of the Drool- Drupal ecosystem is that Webform is the way to do forms on the site. Right. Like, there is contact form. Almost nobody really uses that. Webform is the de facto way. Everybody integrates with it.

It's open source. It's not premi- premium. It's not paid. It is the way to do it, and everything integrates with it. It's open source, so it's great that people can create forks if they need to, but what I'm noticing more and more, like, even just, like, content discovery, like, there's, there used to be one or two ways to look at your content on the site and how they have relationships, and now there's 10 modules that do that.

Each one of them has two people using it. It's good, but at some point you want that to consolidate, and you wanna, you wanna get behind somebody who, um, who is going to maintain that, right? I would say the majority of people that create a module, they create it for their own needs and then never maintain.

And, and I'm not saying this is wrong. Like, I have modules that I built for clients that I released that I haven't updated except to make them available for the next version, but I don't really s- support them. They're minimally maintained. Um, but having 25 different options that do the same thing- Makes it harder to find the one that actually is supported by a developer that, uh, is s- fully supporting it, right?

[01:02:14] Martin: Yeah, and I definitely wanna jump in and, and, you know, voice my support for the need for better discoverability of modules. I mean, even before AI tools made it so easy to sort of create a module from scratch, I, I had the experience of wanting a module that did something very specific. I couldn't find an existing solution.

Um, went ahead, created the module, got it working, you know, worked on my local, all that good stuff, and then it was actually when I went to register the namespace on drupal.org and it was taken. Right. And I realized, "Oh no, it actually already exists," and it does the exact thing that, that I, you know- Right

I needed to do. That is true. So, yeah. Yeah. So I mean, I don't know if like, I feel like if we could even have semantic search, you know, for modules on drupal.org, that would probably help. Um- Yeah ... you know, sometimes I, I will say, you know, use an AI agent to say, "I want a module that does X, you know, is there something existing or, or should I try and..."

You know, sort of start to have that as more of a conversation. So I think- Yeah ... the way that we, we solve that will probably evolve- Yeah ... a bit over time, but, but definitely agree that, that there's work to be done there, for sure.

[01:03:22] Tim: Yeah. I mean, I think that even just like a little editor's choice. Just a little sort of a hint whenever you're looking at.

You know, I've got a few different ones that I'm looking at. What, what's more? Because that's the thing, is that there's all this tacit knowledge of developers. Yeah. And you, you f- you kind of start to uncover that the more you go to- Yeah ... you know, Drupal Cons, camps, and stuff like that. Exposing that tacit knowledge in some sort of way could be really helpful.

Um, and you know, the, you could say that moving forward, you know, CMS has that and whatnot, but I think there's gonna be a lot of people who are like me, who are ambitious site builders who come on higher ed, you know, and they're like, "Oh, this is cool. I wanna, I wanna expand on this, but-" Yeah "... the migration's gonna be expensive.

How can I start to give some features?" You know? I think maintaining distributions, you know, at past, past shows have talked about the m- the maintenance struggle of that, which I think is true, but I don't see them necessarily just going away, you know.

[01:04:30] Nic: Well, we're, we're doing our best to, um, move the pieces that the distribution does uniquely to, um, other sections so that they can be more eas- The, the, uh...

Really quick side tangent and then we'll close out the show 'cause we're, we're already a few minutes over. But, um, one of the problems with the... The problem with distributions is that once you choose one, you're locked into it basically for life. You really... It's really difficult to get out of it, but that also means that you can't really use other pieces, like other things from other distributions, and recipes do allow you to do that.

The one thing that distributions do allow, through profile sort of, that you can't do with recipes really, is you can customize the installation process and you can customize the installation theme. And so we're trying to find a way to provide those, and then you can just have everything else be a recipe, and then you're not locked into the upgrade path of distributions.

But anyway, I'll get off my extension maintainer soapbox, and, uh, we can, we can work towards, uh, closing out the show. Uh, if I can remember how to, how to use this tool again. Well, thank you guys for joining me for, uh, one of our, uh, wonderful Off The Cuffs. This is number 13. It's been a pleasure chatting about all these various topics with you guys Also, don't forget that you can reach out to us on the Drupal Slack in the Talking Drupal channel or email the show at talkingdrupal.com.

You can promote your Drupal event, sponsor an episode, or become a guest by visiting talkingdrupal.com and clicking the buttons in the sidebar. And thank you patrons for supporting Talking Drupal. Your support has kept us talking for 573 episodes. All right, Tim, if our listeners wanna get in touch with you, what's the best way for them to do that?

[01:06:23] Tim: Yeah. So you guys can find me on, uh, Drupal Slack. I'm, uh, tea sharp, T-E-A dash sharp. Um, you can also reach out to me on LinkedIn. Um, and yeah, I would love to s- keep the conversation going about, um, discoverability initiatives, all sorts of stuff like that. I, I, I, I love connecting with new people, so feel free to reach out.

[01:06:49] Nic: Awesome. How about you, Martin?

[01:06:51] Martin: Folks can find me as mandclu on a variety of Drupal and social platforms, and most of my recent writings are on acquia.com. And also thought I would mention that in a couple of weeks, or I guess less than two weeks now, I will be at the Pacific Northwest Drupal Summit in Vancouver.

I- And the following week at the Southwestern Ontario Drupal Camp. Uh, so some opportunities there, particularly in Canada, to, uh, you know, meet me in person, and love to chat about modules of the week.

[01:07:20] Nic: Awesome. And you can find me pretty much everywhere, @nicxvan, N-I-C-X-V-A-N.

[01:07:26] Martin: And if you've enjoyed listening, we've enjoyed talking.

[01:07:29] Nic: Thanks, guys.