Talking Drupal #410 - Off the Cuff 7

 [MUSIC]



 This is TalkingDrupal a weekly chat about web design development with a group of  people with one thing in common, we loveDrupal



 This is episode 410, "Off the Cup" number seven.



 Welcome to Talking Jupil. Today, we're talking about this and that with our Talking Jupil hosts.



 I'm Nic Laflin, founder at Enlightened Development, and today, my hosts are the third week, Tim Plunkett and Engineering Manager at Acquia.



 Also joining us is Martin Anderson-Clutz Senior Solutions Engineer at Acquia as well.



 Finally, we have John Picozzi Solution Architect at EPAM.



 Howdy.



 Now, to talk about ourModule of the week, let's turn it over to Martin, Senior Solutions Engineer at Acquia, a maintainer of a number of modules of his own. Martin, what do you have for us this week?



 Thanks, Nick. Have you ever wanted to give content creators the power to preview how their posts will look on mobile devices even before publishing them? There's a module for that. It's called Responsive Theme Preview, and it was originally created in February of 2013. It has a 2.1.1 version which works with Drupal 9 and 10, and 8.x-1.1 version that works with Drupal 8 and 9. Now, it's officially marked as maintenance fixes only, but the last release was actually just in the past week. It has 21 issues open, but only two of those are bugs against the 2.x branch. Also has test coverage, and it's currently in use by over 8,200 websites.



 Now, it has a team of maintainers, but the last couple of releases were by Rajesh. Shiputra, which is actually also a member of the Acria team as well. Now, in terms of how the module works, it essentially adds a dropdown to the secondary toolbar that allows a content creator to select a device whose display resolution you want to preview for the current page. It launches in a modal overlay and can be rotated so that you can see the landscape view of that. Now, the list of devices can be configured to keep up with the most popular devices as they change over time, including things like phones and tablets. Also, if you are not using the admin toolbar, it does offer a block that you can use to provide access to the preview links as well. Now, it's obviously not a perfect representation of how a given page will look on a mobile device, but it can be a very useful way to see sort of a quick approximation of that page and how it will look on different screen sizes. So let's talk about the Responsive Theme Preview module.



 So it sounds like it's best used by a desktop user. Like it's giving you kind of an overlay to look at, which I assume wouldn't work great on a mobile device.



 I mean, I suppose theoretically you could probably use it on a tablet to preview smaller phones.



 But yeah, I think it's fair to say the intended use is really for desktop. Yeah, I have a question about it. I know, for example, Chrome has its own native developer tools that do that. Are there any advantages to using this module over that that you can think of?



 I think probably just the fact that it's sort of there as part of the website Chrome. So something like the Chrome native tools and other browsers have their own sort of ways of potentially using those, some of them through plugins.



 Definitely also useful, but I would say those tend to be used more for developers. And this is really meant to be, you know, because it's sort of explicitly there on the page, something that's simpler for content creators and editors. Well, thank you, Martin. And glad to have you for the rest of the show. So let's move on to our primary topic. So as I mentioned at the top of the show, this is another off the cuff. So each of us have a couple of topics we wanted to bring up and talk a little bit about. And the first one is module builder.



 I'm not familiar with module builder. Can you tell the listeners a little bit about it? What is it?



 Absolutely. So module builder is really intended to sort of simplify the process of setting up a custom module. So used to be Drupal console. And then later, you know, Drush has had capabilities for scaffolding out certain parts of a module in terms of, you know, creating, let's say your info.yaml and module files, maybe building out some of the boilerplate for custom entities. A module builder, I think, is meant to be sort of more of a way to do that all at once in terms of really selecting the pieces that you want to create for your module. And the other benefit that it has is that if you're using it on a local project, it will also scan through your code base and sort of see all of the hooks available, even ones that are created in your custom code, whereas Drush tends to only provide options for implementing, let's say, hooks that are in Drupal core as an example. So it can be pretty powerful in terms of working with a more custom code base as well.



 That's cool. I know that I used a generator. I think core provides some sort of, or Drush might provide some sort of generator API because when we were working on the ECA stuff, you're going to use the generator that you put together for a bunch of the different stuff. So like setting up an action, it will scaffold all that stuff out for you. So, yeah, there's a lot of boilerplate in Drupal now. It's kind of a fact of life. So anything that can make that easier is wonderful, I think. I'll have to check it out.



 Absolutely. There was actually... So I had heard about it years ago, looked at it briefly, but never really got using it. And then when I was at Drupal Dev Days, I guess it's now a couple of weeks ago, there was a presentation about it. So I'll put a link to the video of that in the show notes as well.



 Awesome.



 Yeah, it's been around like since Drupal 5, at least. I think it has, as you mentioned, all the other alternatives, it's kind of ebbed and flowed with how much it is the primary approach. And I think it's kind of the de facto one at this point.



 But, yeah, it's been around for as long as I have, basically. All right. Tim, we're excited to have you on the show. And as one of the maintainers of Drupal on sort of an ongoing basis, was curious if you can share with us anything you're excited about in the upcoming Drupal 10.2 release we should see later this year.



 Yeah, so I think the biggest thing I'm excited about is all the improvements to the field UI.



 There's actually a couple of things that snuck into 10.1. Drupal 10.1.0 came out about a month ago, a month and a half now. And some of our improvements were in there. And actually, some people already noticed them. Nick, I think you noticed a couple. And then at Dev Days, apparently people were coming up to, you know, members of the team that worked on it and complimenting on things that, honestly, I didn't even realize did get into 10.1. We've been working on it just with 10.2 as the target.



 But, you know, we got them done so quickly. I'd say we started with prototypes back in February for some of the improvements and went straight into user testing.



 Or actually, we started with ideas, which led to user testing, which led to prototypes, which, you know, we went through that whole cycle, which is kind of uncommon for Drupal core development. Usually someone just drops a load of, you know, a bunch of code and says, "Here's a good idea and here's the code for it." And then we go from there, starting out with the sort of the solution. So we started with the problem definition and went sort of the nor, you know, typical ideation process.



 And, you know, we have a team at Acquia who's working on it. There's some members of the community working on it. And, you know, I'm really excited for the things that are, we're finishing now that should be in for 10.2, mostly around field creation. So the content modeling experience will improve somewhat dramatically. So I'm curious about the specifics. What are some of the specific things that are changing? So, for example, right now, if you want to go create a new field, you go click the button that says, "Create a new field," and it prompts you with a select list of every possible field type. And it can be really hard to kind of differentiate between all those things and understand what they might mean. And also, you might not even realize that it's a very long select list and there are many options. You need to scroll all the way to the bottom to find them all. And that's kind of overwhelming, you know, knowing whether or not if you want a list of numbers, you can't just stop it where it says number. You have to go find the list section and find that. And then when you're looking at that, you have to decide whether you want an integer or a decimal or a float. And good luck knowing whether or not you actually want a decimal or a float because they are different, but in very subtle ways. The same thing which goes back to my original Drupal days is, what kind of date field do I actually want? Do I want a timestamp? Do I want it to be ISO, W6O, whatever it is, you know? And so the new UI presents a bunch of cards that are the categories or kind of grouped together of the different fields.



 And then once you select one of those categories like number or date, it gives you the options below that with a description of what they are and why you might want to use them. So it takes it from the most unfriendly select list in Drupal Core to one of the most helpful, visually, you know, delightful experiences in Drupal Core. That's the first step. The second part is that there are about three screens you have to click through when you're adding a field to get to the end process.



 You have to know whether or not the settings are applied if you want it to be required, if you want to have multiple values, if you want to have sort of like validation, like for numbers like the minimum or maximum or default value. And those are spread over different forms. And it's not clear why they're on different forms. The other problem is as you click through each step, those changes are going live to your site. I mean, obviously, if you're on prod, that's a huge problem. But even if you're on staging, it can be confusing to have these new fields created. So the new flow will save all the changes or delay all the changes until the very last step and save them all at the same time. And we'll combine all those kind of confusingly separate forms into a single form as it was in the Drupal 7 days.



 So all those things are on target for Drupal 10.2. I want to say it took me so long. Actually, I don't want to say how long it took me to realize that one of those forms were the things that were for this specific instance of the fields, the other was for the base field. Yes, the shared the field storage itself that's shared across all bundles. Yep. Although that was not true in those things. Those concepts existed in Drupal 7, but they were not presented in a confusingly separate way until Drupal 8, which is when we just change the forms to match to the way it's stored in code. Like in config, rather. And we don't need to just we don't need to show off how it's stored in config to the end user, they don't need to know those things. I will say once I finally realized that I do like that because it.



 Like you just know, you know, like if you're editing something, you know, if you're changing it, but it's much it's a much better workflow to have them on one floor. Yeah, it will still be very clear which ones are which. I think the biggest example of why it's when it can be frustrating right now is if you want to change an entity reference. And this is obviously if you don't have any content in it because you can't really change too much about things once they're started to beat the fields are in use. Let's say you you set up in any reference to users and then later, you know, you want to go change it to the other way from nodes first, right? You know, then you want to change it to users and or back and forth. The which bundles you select. So like I wanted to point to articles or recipes or whatever is on one form. And the fact that it's pointing to nodes or comments or taxonomy terms is on a different form. And then how it's actually then selected by the user, whether it's just the list of them or it's using a view that's in a different place. And all those things are going to be unified now. You know what I would be my favorite change if it was possible to is if you could say something like, especially for entity reference forms, if you could say, hey, the bundles it points to are locked. They're part of they should be part of the base storage, right? Because a lot of times when you have an entity reference field, if you're reusing it, you want them to be the same everywhere. I mean, there's cases where you do want it to be the same field, but different references. But most sites that I work on, if I'm reusing an entity reference field, I wanted to point to the exact same bundles and having if you add a new bundle type, having to edit every single instance of that field. You have to you have to remember, you know, you have to remember that it's it's everywhere. And I think that could that's a modification that could be made. The other the other thing we did work on a lot is the reuse flow.



 Right. Previously, the reuse field was buried under the create a new field as a separate select list, which gave you no context of where those fields were used and how they were set up. And now when you click, there's a separate button at the top level. Now that will say reuse a field. And it'll give you a table of all the fields that are available. What bundles are used on the basic, you know, high level settings. I think the thing that you had noticed that's in 10.1 right now is in the list of fields on a content type. If it's an entity reference or if it's other kinds of specific subfields, field types will give you more metadata about how it's configured. They'll say not just any reference, but what it's pointing to. And it gives you that information in that table. So I think that reuse experience is improved similarly. That is the thing I noticed. And I have to say my favorite thing. And then we can I think we can move on to the next the next thing. But my favorite thing about that is it's one of those changes I never thought about. It was one of those things that annoyed me about triple core, but I never realized. And then it was just fixed. So so like.



 I want to say that that's that's the power of doing the user interviews. You know, we conducted. I mean, Lowry did a majority of them, but many people worked on the user interviews both conducting them and then kind of collating the observations.



 But that was one of the things that stuck out. It was like, yeah, this is annoying and this could be better. And it was the least invasive change, I think. We could have possibly made. And it was, you know, it's going to be better for everyone who ever hits that page, but also for the longtime users, it is something that's good enough that you notice it and feel appreciative of it. So there's the user interviews are it's always painful to have to sit there and watch someone pick apart a UI that you've just dealt with and learned your entire life. And it's like, oh, that's how it is. That's just how it is. Blah, blah, blah. But like being able to make changes and prove those things is really, really kind of gratifying. It's interesting to hear you talk about it, because I think a lot of times like Drupal, like Drupal's come so far from its from its roots and its roots were very like developer centric. And a lot of the UI UX patterns you see are very developer centric. And, you know, I think that this is probably a holdover from that. And now it's it's being, you know, it's being revamped in a way that's more quote unquote user user friendly. Right.



 Also, when we pitched that, we wanted to work on this with internally at Aquea, I was pointing out is the oldest untouched UI in Drupal core. It effectively hasn't changed since CCK,



 which is, you know, the first module I ever used.



 And yeah, it just it really needed that. And it needed us to, you know, uproot those sort of long held just this is how we do things. I think the other biggest thing I wanted to point out was that I think the nice thing about doing user interviews that way are these are little things that no one would ever really file a bug report for. It's not a bug. It's just how it is. But the improvement benefits so many people. I think having the ability to say this is bad without having to come up with the solution yourself is really powerful.



 Like that can be that usually doesn't really go that far in Drupal. If you drop a bug report and you don't have any good suggestions on how to fix it, it might not get the same amount of attention. So I think that doing these interviews has been a really powerful way to get the you know, these little things fixed.



 I won't I won't go into my tirade about noncode contribution and how it's very important and how you know, you ex folks should look at you at the UX of Drupal and put in feature requests to improve it where they see issues. But maybe I just did go into my tirade and just an abridged version. And that's what we're doing. There you go. Great.



 I concur, I think it's it's all great. It's all great. And I look forward to 10, 2 and 11 and 12 and the future.



 Speaking of the future.



 Dun dun dun. Let's talk about AI because it's everywhere now. And, you know, I have clients actually asking me about,



 you know, better uses of AI and how they can use AI to kind of move faster, do things quicker, create websites faster.



 Martin, you actually, I think, dropped into the talking Drupal chat,



 something about Augmenter as an alternative to the AI module for Drupal. Now, I think we're probably all familiar, or at least when you listen to this podcast, you will be familiar, because I'm about to tell you about the the chat GPT, I think, demo or the open AI demo, I guess I should say, that was done at DrupalCon. Dries kind of showed a video of kind of the open AI module working in Drupal, which was pretty impressive, I think. But you're saying that this is kind of a different version or an alternate possibility to that module. Can you tell us a little bit more about that?



 Yeah, I'd love to. So I came across this module on the weekend. I was just doing a little bit of research in terms of AI capabilities within Drupal and came across this. It sounds like it's actually been developed over, I think, a few years now by some folks down in the Australian Drupal community. And that's maybe why here in North America, we haven't heard about it quite as much



 for anyone listening. And I'm sure we'll have a link in the show notes, but it's Augmenter spelled T-O-R, which I wonder if it's maybe meant to be like a play on words of like mentor as opposed to just augment it feels like, you know, my auto correct goes off every time I put in augmentor. But for anyone trying to find the module on drupal.org, it's T-O-R. I think the primary difference between it and open AI is that it feels like it requires more work to set up, but it gives you a lot more flexibility in terms of how you do that. So as a simple example, both modules will allow you to do things like say, you know, if I've already got content in my body field, have it, you know, suggest a title or suggest tags. And those are the kinds of things that I think actually AI today is quite good at. I think in terms of generating content on its own, it has some definite limitations. So it doesn't know about anything, at least the chat GPT models don't know about anything more recent than currently September of 2021. So in terms of saying like, you know, tell me about single directory components in Drupal, it's not going to know anything about those except for things that, you know, go back that far. Whereas to be able to say, take human generated content and Augmenter in a different ways, I think AI is actually really good at that. And we've seen sort of content architectures that expect to have sort of, you know, a nicely written summary and then nobody fills them out. So we end up sort of like truncating the main body field and you can end up with like splits in the middle of paragraphs. So you have to use like smart trim to get, you know, that truncated in a way that that reads a little better. Whereas AI can actually write that summary for you.



 The Augmenter module feels a little bit more, I think, I guess I feel like there's more thought gone into the UX of some of those things. So as a simple example, you can say, have it generate three different suggestions for titles, and then I can as a content creator, pick one of those. Or it'll generate a bunch of tags, but they're actually sort of links and you click on the ones that you want and it automatically adds those into your tag field. Whereas I feel like at least the way they were the last time I used the open AI module, it's it's a little bit more manual in terms of how you would get sort of that machine generated result and actually get it into the Drupal field. The other key distinction is that I think in the open AI module, it's sort of hard codes, the way certain queries will be written. And so, you know, if if you are a person who who wants to sort of really tweak exactly how the prompt is going to be generated to to send to chat GPT using something like augment or really gives you a lot more control to sort of get the exact result you want. And I think also actually probably learn a little bit in terms of how those, you know, AI prompts work as well. So, you know, as I say, it's definitely more work to set up. But I feel like at the end of the day, you're you're probably better off for going through that process yourself.



 So I have a I have a follow up question here, and this is more of just a general question for everybody, right? So when I was was first talking about this, I had said that I was talking to a client the other day and they were talking about how, you know, I could kind of make make their lives easier. And, you know, I kind of focused the conversation on content creation, right? To to kind of facilitate speedier content creation, facilitate checking of content for, you know, in internal terms and accuracy, that sort of thing. But one of the things that came up was AI for increasing development speed



 and being able to, you know, write code, build websites



 in like an AI generated sort of way. And I'm wondering what the feeling is or the temperature is in the room to like, hey, like, let's let's write write our our code for us. And, you know, what type of what types of oversights you think might be necessary there in order for that to be successful? Or maybe you just think it's not successful.



 I mean, I think with any tool,



 we have to learn what the limits are and what we need. But long term, I forget who said this, but somebody said something like AI isn't going to replace programmers. AI isn't going to replace lawyers. AI isn't going to replace a lot of these skilled trades, at least not for a long time. But what it will do is it will allow the developers that use AI to replace the developers that don't and lawyers that use AI to replace lawyers that don't, for example. So we don't really know what that looks like yet. But most likely what it is is things like the module builder



 generator will become more intelligent, more capable and get you further



 into scaffolding. It'll be able to predict certain things like one of the things that's really tedious as a developer is let's say you have to create you created an array of a bunch of things. They needed to create a switch statement based on that stuff. Right.



 You have to like manually change all the cases and do all this kind of stuff to it. But if an AI can see like, oh, you're following this pattern, just generate the rest of that switch statement for you. Yeah, you still need to populate stuff, but.



 It's a tool we have to learn. It's the same thing as like CI CD like years and years ago,



 you used FTP to deploy. And then once these tools started coming out that allowed it, I'm sure there were DevOps people like I'm only going to use FTP because then I can be sure I'm putting it in the right place. And you can't trust, you know, Travis or whatever, whatever the first iteration of that was. Right. And I think it's the same. The same thing is going to happen with AI.



 We have to find out where it's helpful and where it's not helpful and start integrating that stuff into our workflow. It also.



 Another thing that I think really that will really dictate this is.



 What pricing models and things come out like a lot of companies right now we're doing research and a lot of stuff is paid, but they're going to become paid services at some point, right? And how much is that going to be? What kind of access people are going to have? What are the tiers going to be like there's.



 There's a lot of open questions still, I think, with how it's going to be integrated into people's workflows.



 Yeah, I think that's like that's kind of like the way I also am looking at it, I guess, is like it's a it's another tool to help developers move faster, but I don't know that it's going to.



 Going to replace developers, right? And I think like there's a common misconception there that like an AI could replace a developer, right? And be able to move faster than a developer.



 But I don't I feel uneasy with anybody that has that opinion, because I don't I don't feel like that's. I don't feel like that's accurate, at least yet. I think about sometimes there are fields where



 as technology advances as a society, we seem to lose an appreciation for technical specialists in different fields. So I think about, you know, people who used to do typesetting before desktop publishing came along and a lot of of the work and expertise that they have, I feel like some of it got filtered into, you know, more and more advanced desktop publishing software. But but some of it probably, you know, there are rules that they would have considered, you know, you know, very strict back, you know, whatever that would be, let's say 30 years ago, that nowadays people don't even notice, you know, when they pick up a magazine that those those things aren't followed anymore. And and there probably are things that, you know, as things get more automated, that as programmers potentially, we might we might lose some of those as well.



 But at the end of the day, sometimes, you know, there's there's a level of kind of good enough. And if if we can give people products that are, you know, cheaper,



 you know, iterate faster in terms of, you know, providing better functionality, sometimes there's a trade off there that people are happy to accept. But I agree that hopefully these kinds of tools, and particularly when you think about A.I. in the context of programming, that it's really more about being able to better leverage the resources that you have than than thinking about how they can actually replace people.



 Yeah, I think I think Nick's example is really like it's really resonating with me because it's like, hey, if I could take say to an A.I. or for Dolve, we're going to say to an A.I. Hey, based on this list of values, build an array and then build a switch statement to, you know, do what you need to do with that array like that. And then look at it and go, yeah, this is this is good. I can use this. That's that's far more powerful than like, hey, build a application that does all this stuff. Right. And then maybe it works. Maybe it doesn't. Yeah, I think there's a there's a what you just said, John dives into what I'm trying to think about, which is the abuse of it. You know, how do we monitor? How do we deal with it? And that's been a recent topic in Drupal core or in Drupal issue queues in general. And they actually the DA just published a draft policy for A.I. using contribution and I'll link it in the show notes. But the premise is that when when using A.I. in the course of making a contribution to Drupal, we require you to disclose that A.I. was used in crafting the code or content, carefully review and test the output to ensure it's relevant and that it works and provide human intervention to correct inaccuracies, mistakes or broken code.



 And it's saying if you're using bulk use of A.I.,



 it may or may not result a BAM like permanent BAM from Drupal, which is great. Because there's been a a rash of chat, CPT or whatever generate A.I. generated contributions lately that are just bogging down module maintainers because they're useless. They're, you know, it's just complete waste of time.



 Yeah. And we can move on after this, but that's been my point right along. Like it's not that A.I. stuff is bad out of the gate, but all these big systems like Google, like they have to filter through it. Like the amount of the amount of content that A.I. can generate compared to humans is orders of magnitude higher.



 And these systems have to deal with it. And like you said, like



 even just that if you remember, what was it about a year ago when people started getting



 credit for just posting a screenshot of the patch applying like that bogged down stuff and that was humans literally applying a patch, taking a screenshot, posting it. So they could only do one every two or three minutes. The A.I. you can do hundreds and hundreds and hundreds. So and they also this A.I. thing was brought up in the context of, you know, some issue, cue etiquette and, you know, automated contribution, credit gaming work where you no longer get credit by default for anything. They took that away. It used to be pretty smart about uploading a patch, opening an M.R., etc. Now you get nothing and no one gets anything but a fault. And everything is up to the discretion of the maintainer. And we had to take it away because people abused it. But they abused it, as you said, with and without A.I. Yep, exactly. Everything a bit. Nick, you mentioned during the pre-show something about state API. And I want to hear more about that.



 Yeah, so I'm actually kind of proud about how this how this came about. And part of it was because the show with that, I think Matt was on. Mac Lomond was on and talked about how the new feature in Drupal 10. One, I think that allows you to set up pre-debugging in the browser or in the Drupal UI uses the state API. And of course, I was aware of the state API, but I never had actually used it myself and I realized a lot of little things that I do for clients should use the state API. So, for example, I sometimes store value for when a process last ran and just store and config. And I know that it gets over it on the next one, but it's, you know, a lot of these things like they need to run once a day and if it runs twice a day or three times a day because I do two deployments or something, it's not really the end of the world state API is way better for that.



 But I had a request, a kind of a request going on with a client where they had a bunch of little content that they wanted to tweak on the site.



 But because the way the site was integrated, you know, things that you normally would just use a Drupal block for, it just wasn't going to work with the Drupal block and I was trying to figure out how to handle that. So, for example, some things in the footer or some like social media icons and links, for example, that are just, they're used in many, many different places. And on a traditional site, you would just, you know, you'd either make a content somewhere or you would just have multiple blocks and have to remember everything that you need to update. Well, after that discussion with Matt about using the state API, I thought, well, hey, maybe we can use the state API for this. So. That's a terrible idea. I'm sorry. I had to jump in. I'm curious to hear why. Yeah. I mean, the state API, like state API should never be used for anything you want to have later that can't be auto regenerated. So you're the first example you mentioned about the last time cron was run is what it's one thing it's used for. Right.



 But yeah, I mean, if, if, if, what if it goes away and then they have to retype in like, you can't reference anything in there safely.



 A lot of this is little content things like what's the label for the news that are set up link, right? So that there's defaults. So if it does go away, it just falls back to the default and they might have to tweak it again. I mean, what's the advantage of using state over config in that case? Cause it sounds like one thing that can actually would be good for. The thinking was they want to, well, now I'm questioning my assumptions there. The thinking was they might want to work with config too.



 Maybe it was just learn about a new tool and wanted to try it. New shiny hammer. Everything's a nail.



 Yeah. No, I have to revisit that. I mean, it's simple enough to convert because I mean, that's one of the cool things about the state API is it's pretty close. I mean, it's just the key value store. And that's where I wanted to mention, which it literally is a single implementation of the key value service within Drupal core. Um, a separate one. I don't know if you've ever heard of it or used it or talked about it as temp store temp store, right? Is a, uh, auto auto expiring key value implementation that's used for tracking the changes made in views UI and layout builder.



 And those are the two main places they're used. Um, so if you know, in Fuzzy, why you can go change a bunch of different things before hitting save, that's how that works. That's what it was built for the temp store, uh, implementation. And it's just, as I said, their state and temp store are both, uh, implementations of the key value store. There's also a private temp store, I think, too. I've written shared temp store. Um, yeah, they have to do with whether or not the owner, you know, someone else can access that or not. And that is useful for things like views where multiple people might want to make or collaborate on configuration changes. I've also, I've also used it on a form that has multiple steps that I don't really want to use kind of the built-in way of doing it. Like you just need to store a value for a page refresh or something. That's exactly what I think I mentioned at the beginning of the show about the field UI where we no longer try to save each step of the multi-step form until the very end that's going to, that's using temp store for the same reason. Awesome. I have a dumb dumb question or maybe, yeah, I think it's a dumb dumb question. Like, so if state API is just like the, the referencing, like another piece of Drupal, like a state API, adding some, some management for states in there, is, is that why it's, why it's different?



 Nope. It is, uh, as far as I know, unless something has changed dramatically, it is all key value storage is you, that you have a required column key or collection rather not column, a collection column in the database that says, this is a part of this collection state is the collection and the rest is just regular straight key value. So it just removes an extra parameter. So you don't have to say when you're pulling up a key value store, what collection it is, it's, it's a convenience wrapper around the key value store. I, I just remembered actually why one of the main reasons why I went with state API, the client wanted to be able to change it whenever they wanted. And I didn't, we didn't have like, yeah, we didn't have the config. Like, does the config ignore? We don't have that module on the site and I don't want to configure that. But if you say that it is possible to just go away at some point, then I'll just, it is not guaranteed to be there forever is, is intended for use with things that will be an inconvenience if they go away, but it can be regenerated. Yeah. Whenever you want. That's the way I set it up. I mean, there's defaults. If it does go away, they can just read it. So it's like, so I'll look at it though. One more side. What kind of situations makes state school away? Like what, I mean, it's already clear. It's like a manual, like you have to call it a state delete. Uh, well, it depends. I mean, yes, I believe so, but I, I.



 I mean, I think there's also some best practices about just clearing out state when your database gets too big. Like why not? It's supposed to be ephemeral data. Um, you should be able to just wipe it. Interesting.



 Okay. Um, and the other thing is I don't think it's usually traditionally synced between environments. I mean, probably people are probably doing it because they want to, but yeah. No, no, no, it's not. That was one of the features too. Cause then they could tweak it on a staging environment and see what it looks like and not worry about it getting it again, they, I want it. The reason, the reason why I went with state is because it feels a little bit more like content and that it's per environment, they can tweak it whenever they want and I won't overwrite it. But it sounds like the right way to do it is putting config and just set up the config and or rules, which in this case, it's not a huge deal to overwrite, um, and, and, or overwrite. It's not a huge deal to convert that. So I was just quickly add next for some of those use cases, like you've talked about in terms of storing things like social media links, I've found that the config pages module can actually be really good for that in terms of making it easy to spin up the UI and then you can access the values either through code or using tokens and those kinds of things. That's it. I, we've, we've used config pages quite a bit, uh, on the, uh, current project I'm working on and it, it is really allowed for us to create kind of, um, universal config pages for the, for a Drupal multi-site that allows folks to go to those pages and set kind of site specific configurations that they need. So that's a cool. The, yeah, the interesting thing about the config pages is the structure of the config page is actually part of your site configuration, but the values stored within it are really content. So in that use case of wanting to like tweak things between environments, you can definitely do that even with config pages. Yeah. That's what that, that's why we're using it as a, because we, we don't want the, a new site to have to have code changes in order to edit some of those things. Yeah. I wish I'd known about that last week. I would have used it. I have so many more questions about the state API, but, um, you know, we could, we could probably put those into a show at some point, I bet. Yeah. I mean, I have a lot of other stuff that I'm going to be converting to the state API over time, but I'll look at the config pages and report back. So Tim, I think you, you want to talk a little bit about, I know this new development process in Drupal. Um, typically every six months or so Drupal would just change what the head is pointed at. It's going to be the next minor version of Drupal, but with kind of, I think a lot, a lot of it has to do with the conversion. Finally to get lab, there's been discussion about 11 X being kind of the last switch, and then we're just going to be working from main as head in the future and just kind of tag things the way most projects do it. I'm curious a little bit. I remember reading some of the issues around it and realizing that there were some pretty, pretty gnarly, uh, things that made it a lot more difficult than you would normally think, especially with Drupal CI, I think. Um, I'm curious what you, what you think about that since you're kind of a core maintainer, how, how is that transitioned on? Yeah. Well, so you're absolutely right in describing it. Um, I think the biggest, but what you said doesn't really capture the, the impact it has on core contributors. Um, so when you file an issue, you pick a version that you're, you know, filing again, saying this bug is in this version of this of core. And so they had to go write a bot that moved the issue from one version to the other every, as you said, about six months. And sometimes now you go to an old issue and like the last 10 comments are just, it getting moved every six months for five years, um, which can be very demoralizing. Um, I think the second thing is that, you know, now with the reason that we need to even more is that when you go to create an MR on an issue, if it was, if your MR is sufficiently old enough, the new branches won't even exist in that issue fork. So when you do want to go move it to a new one, you have to know that you have to manually add the newest branches to the fork in order to change the target branch. And it's a, it's a mass for people. Um, so for the, for very many reasons, we wanted to make this change. Um, and yeah, you're right. There was a lot of engineering toil that's going on on the DA side to make this feasible. Um, the first thing was getting it onto 11 X just as a, for, so the release managers, so the triple core contributors could get used to the process of not having issues merge, uh, sorry, move every six months. Um, and the rest is like, for example, they couldn't in parts of triple CI, they couldn't have a branch name that didn't start with a number. Like it just, it just rejected it. And so main was not available at that time. So they knew all these problems were going to happen. So they moved to 11 X first so they could work out all the bugs and they're working on them. I think they've made, you know, I'd follow along loosely just to see the progress, but they've been making good progress. Um, I think the biggest concern of mine in this intermediary state is that people are freaking out when issues get moved to 11 X and they're like, we just got on dribble 10 and you're saying no one's going to care. We're not going to get this feature until 11 X. And they're not reading between the final print that says like, no, this is a placeholder, like 10, two X doesn't exist as a branch. Nothing's getting into 10, two. Yeah. Maybe it's getting the minute to 11. Maybe it should have been called 99 or something. So that would have, that would scare people even more. Maybe, I don't know. I don't, I mean, yeah, there were a lot of different ideas and I don't think we realized these, this, this sort of psychological ramification of the move. Um, and I've had to explain on many, many issues that like, no, it's, uh, it'll be intent to, because that's how it works. And like, you don't need to worry. We're not putting it off for some future version. Um, so I couldn't, the, the switch to actual main couldn't come any sooner so that we can stop, you know, laying, having to lay people's concerns. Um, but to the first, the first release using 11 X. Yes, it will be the first release using 11 X. Um, yes. So when it's time to tag 10, two, they will, you know, tag it from the 11 X branch. How nervous are you about that change in the process? Cause zero concern because I have a lot of faith in the release managers. Um, you know, catch and Jess and, uh, the quiet one who, first of all, I've been doing this for a decade and also have scripts that they work with. They've tested and adapted to this and whatnot. So now they're not going to have any trouble. Um, and if we do, we won't, if they do, they won't tell anyone and we won't see them sweat, the release will happen just the same for everyone. Maybe they might be a little bit more stressed, but, um, it will impact, you know, anyone outside of them. Um, they'll be fine.



 So if I'm hearing you correctly after the 11 X release, will it then switch to main? Oh, it might switch to main ideal. I hope we don't take that long. At some point we should be able to switch to main, you know, maybe during the 10th recycle, maybe during the 10th or cycle in the same way that we stopped doing 10, one 10 X 10, two X 10, three, you know, and switched using 11. I hope they're going to be able to migrate everything over to main. Well before D 11. Um, and then we will no longer have, uh, you know, new branches for new versions of Drupal, like the branch will only exist after it's time to, to make the, you know, make the release.



 Um, yeah, it just follows a standard development work.



 Exactly. We're going, we're just doing what everyone else does. And then you're relying on tags at that point for, for versions. Right. Is that, I mean, as far as I know, it's still. Standard.



 Maybe I don't know. Actually that's the wrinkle. I don't know whether or not there will continue to be a 10, two X branch. Um, that's a sort of, so you mentioned I'm a core maintainer. I'm not, I'm a subsystem maintainer of a specific couple subsystems within Drupal core. I am not a core committer. And so I'm not either privy nor responsible key, uh, for any of these actual discussions. So I'm not exactly sure what the back port policy and how they're going to do branches and tags and all that stuff will actually work. All I know is as a core developer, core contributor, that things will just continue to get easier for me. I think the most recent tweak they had to make was dealing with composer aliases to point out that 10, two X and 11 X and eventually main are all actually the same thing right now. And handling that, it was the most recent kind of, you know, uh, wrinkle that they were dealing with to make sure that it's transparent to anyone using composer so that no one else has to think about it.



 Hmm. Interesting.



 I imagine this is all like do or a pleasant by-product of the fact that like Drupal eight was a rebuild and now we're on this path of like just continually improving Drupal as opposed to like brand new versions and many breaking changes and all this other, and all this other stuff, kind of the, the, the work that's been done to improve the, I don't even know if it's called the wood. I would call it the development process, but like the, the kind of like roadmap around Drupal. Yeah. I would say that the, I mean, the Drupal eight dev cycle almost killed me, you know, and many other core contributors, you know, it was, it was brutal. Uh, it was extremely long and extremely painful and extremely demoralizing. And a lot of people didn't come out on the other side as core contributors. And it was, uh, something had to change and the biggest, I would say some semantic versioning, some of her is like the biggest change that was made, but that led to, or allowed to happen. Or part of that was the six month release games. You know, part of that was the strict back-core policy and, um, backwards compatibility and, you know, when can we make changes and pointing out that, you know, 10.1, 9.1, those were the biggest releases of Drupal, the nine, oh, the 10 oh, the 11 oh, or the boring ones. Um, because that's what semantic versioning means and trying to shift the community's focus around that. Um, all of those things came from the pain that was the Drupal eight development cycle, but I would say that, yeah, semantic versioning became sort of the vehicle by which we brought all these improvements, these process improvements. Um, and that all of that stems from it. And so I don't think a GitLab either empowered us or motivated us or anything to make these changes, you know, it's just that we didn't want to bother. And we, the DA, you know, didn't want to bother porting all these Drupal isms to a new system when we could fully embrace semantic versioning and move to the system. I think another big part of it too, is that. GitHub happened and GitHub normalized the pull request workflow and people started in people came up with best practices around that you got to remember Drupal started before all that stuff. Drupal started before Git, right? Yep. And so, yeah, exactly. So it's, I think a lot of it is that people getting into it now, it really just, it used to be the patch system was like, Oh, this is great. Is the breath of fresh air so much easier than like a listserv or like a newsletter for them, like emailing stuff back and forth, but at this point, there's better ways to do it. Um, but it's a mature project with millions and millions of issues. You can't just flip a switch and make that change. And it's, you know, millions of sites depend on it. So it's a multi-year project to convert. So, but, but I think a lot of one of the big drivers is people are just used to it and it's a better workflow. So we need to get to, and get to there. It's just a three year process to change it. For sure. And I think though that we have, because of the nature of our community and our contributor base, our processes, even more sophisticated or superior to the standard patch PR, MR, workflow, where in every MR is actually an issue fork. And then anyone can get access and push to those because, you know, typical development, you know, other software projects, you have a single author comes in, does the MR, maybe get some feedback and they fix it and then it's merged in. But this, you know, people will just drive by, drop off some contributions and never come back ever again. And someone else needs to then pick that up and carry that and our flow. And that was one of the biggest things I was advocating for, um, among many others. But when we were adopting that was to continue to enable that sort of collaborative workflow, even in the MR thing. So ours is way more complicated than it needs to be, but it is because we need it to be. Yeah. And it allows you to like get access to it and make changes. Absolutely. Yeah. So Tim, you mentioned being a subsystem maintainer and I think a lot of our listeners will naturally associate with you with layout builders. So can you tell us, are there things that are being worked on right now in the layout builder ecosystem that you're excited about? Yeah, I would say there's, there's two main things that are sort of layout builder, adjacent or direct, uh, contributions to it that I want to talk about. The first is the dashboards. So dashboard module Drupal seven, not that great, not that useful. Um, some people liked it, but it's been long gone now. Um, but the new dashboard module that, you know, some of the kind of people are working on like Pena Skito, uh, is utilizing layup holder to allow, you know, users or roles or percentage to customize the different, you know, different aspects of their dashboard. Um, and so there were also, this is a, the first time in court, at least that layouts are going to be used for something other than, you know, content. Um, so sort of just a different way to do it. The, the nice thing is they think they made a lot of great progress without needing any sort of major overhauls or changes to the layout system. So it kind of proved that the API works, um, which is very gratifying. Um, but yeah, I'll make sure that Lincoln, the show notes, that it's been some really cool, exciting stuff. Um, once again, like, just like the field joy work, they started with, you know, the user story and the persona and the research there, and then only picked up the code stuff later. Um, the other thing is just, you know, taking the layout filler that we do have that is used for content and sort of improving the editorial flow and, um, the, you know, the, the, for content authors as well as for, for site builders. Um, one specific example is with site builders. If you go down the route of, uh, inline custom box, you know, the native core version of kind of paragraphs, um, just like paragraphs, you can hit into, you can run into some nasty performance and scaling issues, um, when you have, you know, thousands and thousands of blocks. And so there's some proposals, um, to kind of tweak the way that those are created and generated, um, and only sort of make them more available on demand or upon request, I guess, and not just create all the possibilities for you up front, um, as well as allowing you to kind of pre-create blocks that then editors can use, um, that will both help, as I said, with the user experience, but also with the performance. Um, I think the other thing is sort of, there's an ongoing open-ended discussion about, you know, the future of the improvements to the editorial side between, you know, we have CK or five and it's fantastic and we have layout builder and it does its thing. And there's sort of a gap between them. And then there's Gutenberg, which kind of does a little bit of both. And so there's a lot of discussions in the community right now, um, especially coming out of the Pittsburgh, uh, you know, kind of elevation of, of Gutenberg to kind of see how we can have those things coexist and improve each other and work together. Um, so as I said, I'll make sure the links are in the show notes, but there's a lot of energy and excitement around, uh, this work, which has been great. Well, thank you guys for joining us. And thank you, Martin, for joining last minute. We appreciate that. Do you have questions or feedback? Reach out to Talking Drupal on the social network, formerly known as Twitter with the handle Talking Drupal or by email with show at talkingdrupal.com. You can connect with our hosts and other listeners on Drupal Slack in the Talking Drupal channel.



 You can promote your Drupal community event and Talking Drupal. Learn more by going to talkingdrupal.com slash TD promo.



 Get the Talking Drupal newsletter to learn more about our guest hosts, show news, upcoming Drupal camps, local meetups, and much more. Sign up for the Drupal newsletter at talkingdrupal.com slash newsletter.



 And thank you, patrons for supporting Talking Drupal. Your support is greatly appreciated. And if you're a listener and you're wondering what kinds of things you get as a patron, you get the before and after show. And if you are a patron for this week's episode, you will get an extra long show where we planned today's episode, uh, due to last minute scheduling conflict. So you get about a 45 minutes. And if there's any time after you get to hear anything that we chat about with the guests hosts and guests, uh, after the show, so if you want to become a patron, you can go to talkingdrupal.com and choose to become a patron button.



 Well, we've reached the end of the show. So if our listeners wanted to get in touch with you, Martin, it's the best way to do that. On various social and Drupal platforms, they can find me asmanclu and they can read some of my blog posts onmanclu.com or dev.aquia.com.



 And Tim, how about you? Uh, Tim Plunkett on most socials. With a period. Oh, and I have to mention that I was at giving credit to you and Tim Doyle for the Drupal association episode. And both of the Tim's have periods in their name as well, which, um, broke the credit form. Uh, I had to refresh it and do it again, but you're welcome.



 John, how about you? How can a listener get in touch with you? Uh, you can find me on, uh, most of the social, uh, networks at JohnPicozzi No period. And, uh, you could find out about, uh, E-PAM at EPM.com.



 And you can find me pretty much everywhere atNICXVANN-I-C-X-V-A-N



 And if you've enjoyed listening, we've enjoyed talking.