Talking Drupal #419 - Drupal 7 EOL & Backdrop CMS

• When is Drupal 7 EoL
• If someone is on Drupal 7 what are their options
• If someone does not have the resources to upgrade to Drupal 10 what can they do
• Can someone stay on Drupal 7 after EoL
• What is Backdrop CMS
• Listener question - James: Some people have mentioned that Backdrop has changed significantly since forking, does this affect upgrading from drupal 7
• Listener question - James: Will there be another fork
• How can Backdrop help people get off of Drupal 7
• Tell us a bit about Backdrop’s annual online event
• Is Backdrop negatively affecting Drupal 10 adoption
• How does someone get involved with Backdrop
• What are some big features on the Backdrop roadmap

 [MUSIC]



 This is Talking Drupal, with the chat about what designed development from a group of people with one thing in common, we love Drupal. This is episode 419, Drupal 7 End of Life and Backdrop CMS.



 On today's show, we are talking about the Drupal 7 End of Life, Backdrop CMS, and an upgrade strategy from Drupal 7. With guests, Jen Lampton and Laryn Kragt Bakker. We'll also cover Acquia Migrate Accelerate as our module of the week.



 Welcome to Talking Drupal. The guests today are Jen Lampton and Laryn Kragt Bakker . Jen is an open source advocate, web team, and project lead. Drupal provisional security team member and backdrop CMS co-founder, an expert avocado surgeon and loves animals and likes house plants as well.



 Laryn loves applying his creativity and technical know-how to web projects that are focused on social justice, peace, the environment, and the common good, and has been doing so for 20 years. He's a firm believer in the open source model of collaboration and open sharing of tools and knowledge. His focus in recent years has been on backdrop CMS as a tool, that provides much of the traditional power and flexibility of Drupal, with a focus on end user experience and affordability for groups that may have budget constraints.



 Jen and Laryn, welcome to the show and thank you for joining us.



 - Thanks for having me.



 - I'm Nic Laflin, I'm founder at Enlightened Development and today my hosts are, as usual, John Picozzi, Solution Architect at EPM.



 - Hello everyone.



 - And now to talk about our module of the week, let's turn it over to Martin Anderson-Clutz a senior solutions engineer at Aquaa and a maintainer of a number of Drupal modules of his own. Martin, what do you have for us this week?



 - Thanks Nic. Have you ever wanted to add a layer of automation to Drupal's Migrate API to simplify the process of migrating content and site architecture from Drupal 7 to Drupal 9? There's a module for that. It's called Acquia Migrate Accelerate and it was created in July of 2020 by Erin Winborn Award winner Webchick, AKA Angie Byron.



 It has a 1.8.0 release available, which works with Drupal 9. And it is actively maintained. In fact, that latest release, its first as an open source project was in the past week. It officially has three issues open, none of which are bugs and all of them are labeled as fixed. And it also has test coverage. Now, because it's so new, it officially has no sites that are reported as using it. And the most current release is by Wim Lierz, a long time Drupal contributor and core subsystem maintainer. The goal of Migrate Accelerate is to make Drupal cores Migrate API something that can be used by less technical users to migrate a Drupal 7 site to a modern version of Drupal. It relies on an Acquia CLI command to analyze your Drupal 7 site. So it can generate a composer.json file using an existing matrix of hundreds of mappings from legacy modules to modern Drupal equivalents, including patches. That composer file then becomes the basis for your migrated site into which it will begin to migrate your content architecture. Now it provides an interactive dashboard that lists out the various kinds of content found on the origin site with an ability to control the order in which the migrations will be performed. At any point, it's possible to see a live preview of the content that's been migrated, all within the same UI. There's also a dress command to trigger the same process, which actually runs more efficiently, but also allows for the live preview. Now, if you want to get an estimate on how much of your Drupal 7 site can be migrated automatically, there is also a flight path report you can generate using a dress command, which is an HTML file that will sort of visually summarize how much of your Drupal 7 site can be migrated automatically.



 Migrate Accelerant used to be available only to Acquia customers and partners, but with this new release, anyone in the community can use it to help them migrate their Drupal 7 site forward. So let's talk about Migrate Accelerant.



 - So that last point kind of is my first question. So you mentioned that this is now kind of open in the community, but you need the Acquia CLI. So is the Acquia CLI that something that's available to people outside of Acquia customers too?



 - Exactly, yeah. Anyone can install Acquia CLI. It's definitely not restricted in terms of who can sort of install that on their local machine.



 - So cool. - Does this have to be installed? So I would imagine this is installed on your new Drupal 10 site. Does it also have to be installed on your Drupal 7 site in order for you to get kind of those Drupal 7 statistics?



 - So certainly the FlightPath report is something you would want to run on the Drupal 7 site. So to get that estimate in terms of how much the automation kind of layer can help. But in terms of actually doing the migration, it's probably gonna work best on more of like a server environment where you can actually have both the Drupal 7 site and the modern Drupal site in kind of a single environment, but as sort of separate websites because it is sort of reading from one database and then posting content into the other.



 - So going back to the first bullet point, for less technical users, you still probably need to be a technical user in that you can use the command line and kind of like move around in Drush



 as opposed to like a more site builder type of user who may not necessarily feel comfortable on the command line. Is that accurate? - I would say that's accurate in terms of getting it up and running, but I think the idea is that once that modern Drupal site is spun up, that becomes the place where the less technical user can go in and sort of use all of the point and click functionality as opposed to sort of having to like write out migration scripts. - Got it, so you could have your developer



 or development team if you had one kind of install this, get it up and running, and then you could kind of manage the migrations. Also, I imagine this probably reduces or eliminates maybe the need to write migrations yourself. So that's definitely super duper helpful.



 - Yeah, exactly. I think it's meant to be sort of a layer that sits on top of that very robust, migration suite in Drupal, and yeah, it makes it much easier to use more accessible.



 - Cool. - I have to check it out. I mean, it looks powerful. I'm also interested in kind of the flight path stuff. Is flight path like a separate tool too for generating that report?



 - Correct, so it's sort of a standalone project, actually a completely different author for that one, but they work together in the sense of the flight path report, and there is actually a link to that in the show notes of where to sort of download that if you were interested in running it,



 but just more of an analysis tool that can run, as we mentioned earlier, directly on the Drupal 7 site. - Awesome. Thank you, Martin. As always, really on topic, module of the week, I'm actually gonna have to look into this because anything that can kind of help automate that is a huge benefit to time,



 and I'm sure over the next year or so, as we'll talk, a lot of sites are gonna be looking to upgrade.



 A lot of people have been delaying a long time, so this is definitely an option.



 See you next week.



 - Thanks, Dave. - So, Laryn, let's start off with maybe an easy question. When is Drupal 7 gonna officially be end of life?



 - Yeah, so January 5th, 2025, and I know it's been kicked a bunch of times, and everybody's saying it's not gonna get kicked again, so as far as we know, that's a pretty solid date,



 and like you were saying, I think in the next year, hopefully we'll see a lot of those 400,000 Drupal 7 sites move to something that'll be more stable long term. The thing that makes me believe this time that it is a pretty stable date is that they've already begun to sort of phase things a little differently, and the certainty things are not gonna be treated the same, and modules that become unsupported won't be able to get a new maintainer, so they're kind of making baby steps towards that date already, I think.



 - Right, and I think it's been, I think it's been, you used the term kicked, punted, moved, however you want to address the shift in the date, I think it's been shifted two or three times at this point, right?



 I guess the feeling there, or would you agree, me ask the question, the feeling there is that it's been shifted because there are still so many sites on Drupal 7? - Yeah, I also think it's noteworthy that the way security issues are gonna be handled for Drupal 7 is gonna change at the previously stated end of life of Drupal for the end of this year, and then from then until the official end of life, there's gonna be more limited security coverage. So even though the end of life has been moved, and you'll be protected from major problems, it is still a good idea to move sooner if you can, because things are gonna be changing.



 Larry mentioned, Kintrip's based, but also for Drupal 7 core support.



 - So Jen, let's dig a little deeper into this. If somebody is currently on Drupal 7, I'm wondering, what do you see as their options for moving off of Drupal 7? - Well, the obvious one is to move to a newer version of Drupal. I think Drupal 9 is also end of life at the end of this year, so I recommend moving directly to Drupal 10. If people wanna do that, there's a lot of work involved in that, and there's a lot of things that need to be managed really differently for a modern Drupal site than for a Drupal 7 site, so it's important to understand the ramifications of that move.



 And then if you wanted to do things sort of the same way you managed them for Drupal 7, Backdrop is a really great option for that. It has the same kind of technical requirements, the same hosting requirements. You don't really need to do anything differently than you're currently doing. There is always the option of moving to anything else, and anything you wanna move to, you would move to, literally, how you would move to a modern version of Drupal, where you need to take all of your content out of your old site and migrate it into whatever your new platform's gonna be if you wanna maintain the content. If you're considering a complete rebuild, then it doesn't matter, you can do that in anything. And it's gonna be the same regardless which platform you choose.



 - Larry, and you mentioned at the top of the show, you know, budget is one of the factors for Backdrop. Can you talk a little bit about how, if somebody's looking to get off of Drupal 7, how Backdrop is more budget-friendly?



 - Yeah, sure, of course. So it's by design because the sort of backward compatibility and the direct upgrade path we're putting place specifically for this reason for groups. I mean, you know, many groups who have the budget and whatnot wanna go to Drupal 10 for a variety of reasons, but there are many groups as well who have a site that's working well for them. And it's kind of a hard sell to say, we need to rebuild everything. And so to be able to have that direct upgrade path with similar requirements and similar API and so on,



 reduces I think not just the upgrade path. So you can actually do an upgrade instead of a rebuild and a migration,



 but also the kind of the total cost of ownership of the website goes down.



 If your site is small enough and you need less server resources to run, then that adds up over time.



 And I think the fact that your site is already,



 if it's already working well for you and you have an option where you can take that and replicate it on a system that is, you know,



 not just backwards compatible, but also like future facing and stable, then I think that's clearly a win-win.



 And if it costs less to develop on, it costs less to upgrade, it costs less to maintain. For many groups that don't have huge budgets, that's an enormous benefit.



 I don't know, Jen, do you think of anything I missed on that, that kind of spectrum of cost?



 - No, I think that's good.



 Cost less to develop on, I think, is because you don't need to have sort of the same specific expertise as a current modern Drupal developer needs to have. So you can often find people who are a little more affordable, a larger audience to pull from. And then updates, like ongoing updates, there's like built-in features to help manage that. So you don't necessarily even need a developer to handle your updates anymore, which is a big improvement. So yeah, I think giving the site owners more tools that they can manage things on their own is really good. And then also making sure that when they do need developers, those are gonna be less hours or less expensive developers at the same time. Tell you. - Yeah, so I wanna dig in a little bit to the funds and the cost around upgrading, right? And I think, Lauren and Jen, you both raised really interesting points there. Is that like backdrop to me, and correct me if I didn't hear correctly or understand correctly, but backdrop kind of reinstates that upgrade path for Drupal 7, right? So it gives you the ability to say like, oh, I have a Drupal 7 site, I can upgrade to backdrop as opposed to what the current landscape is in Drupal. If you were to go to Drupal 10, right? You would have to basically rebuild your site in Drupal 10,



 which at an economy of scale is a good thing. You can clean up content types, you can refine your content. There are a lot of positives that come with that. But sometimes the one negative is that for smaller organizations or some nonprofits that are on Drupal 7 right now, they may not have the funds to be able to support that kind of effort.



 Would you agree? Would you agree with that? Is that what I heard? - Yeah, I think so. - I just really quickly, Laryn has some more hands-on experience with this ad and has done like cost comparisons between the two options, which is really interesting.



 But for me, there's like two primary use cases for something like backdrop. And one of them is the sort of lower end,



 we don't have very much budget, we need to maintain what we have, we don't have very much staff, we don't have on-hand development and all of that. But the other end is also the people who really heavily invested in Drupal 7. So people who have spent hundreds of thousands of dollars on their own custom infrastructure, their own custom module stack or whatever it is, those people are also looking at a huge cost in order to move to modern Drupal. Whereas moving to backdrop, you can keep all of the customizations you've already invested in and move them onto the platform. So there's sort of both ends of the spectrum. I think backdrop is gonna be a much more affordable option. - I agree with what she said completely. And you were talking about the benefits of being able to sort of rebuild from the ground up and that's an important consideration. And I think the way that that happens, at least in my experience with backdrop is more of a like do the upgrade and either before or at do some of that cleanup. So if you don't need a content type, get rid of it. If you're gonna rearrange things, get rid of certain content, it's more of a, I mean, you still have to do that work if you want it to be done, but it can happen sort of outside of the exact upgrade process itself. - It's like a home remodel coupled with a spring cleaning sort of. - There you go. - The other thing I wanted to kind of touch on there, and this kind of talks to the other, the previous question as well, right, about moving off of Drupal 7.



 There are other options, right? So for some of those organizations and scenarios, you're kind of referring to Gen where you might not have in-house developers, you might not necessarily need that full featured CMS, right? There's also other options, static site options, maybe even a hosted service, dare I say something like Squarespace, right? That may be more economical for you. So, you know. - Yeah, that's a really good point that like most of those services didn't exist when a lot of these groups chose Drupal 7 in the beginning. In Drupal 7 has been around for a very long time. You could go back to that part, there was no Squarespace. We were in a very different world with WordPress, and now there are a lot of much better low end options.



 What I'm finding with the sites that I'm working on, I've maybe told two people, "Hey, you know, you don't really need this anymore. This is gonna be kind of expensive. You could do a Squarespace site of the sites that I have previously worked on." But a lot of them chose Drupal because they could get the extra functionality with this like super rich CMS that they couldn't get with something like Squarespace or WordPress at the beginning. Like even if they didn't have those as options, they still chose it because of its flexibility and its ability to give them the customized experience that they needed. And so for those people, it's like, yeah, a lot of your site could have been done, but you built this one tool that you really lean heavily on now, and that can't be built in WordPress without really custom development. And maybe even if you have a custom development, you're not gonna get the same tool. It's not gonna use that. It's not gonna be as usable.



 And so yeah, there are a bunch of people who may have had that option originally, but now they're coming to depend on something that really needs a CMS. They're gonna keep using it.



 - I keep having conversations with folks. And I think Nic, Steven, and I have this conversation every so often of like the numbers for Drupal 7 are large. And people are like, oh, everybody needs to migrate. And I'm kind of like, well, does everybody really need to migrate? I think there are a lot of people out there that,



 as you said, could go to something like Squarespace, could move to Backdrop, but there are also probably, there's probably gonna be some sites that just kind of fade away, unfortunately. But that feels like maybe a topic for another show.



 Let's talk about staying on Drupal 7, right? So top of the show, we talked about Drupal 7 end of life being January 5th, 2025.



 After that date, Drupal is not gonna just magically stop working, right?



 Your site will still run. Things will still work the way that they did on January 4th. But you're not gonna get those crucial security updates.



 So Jen, let me ask you, would you recommend that somebody stay on Drupal 7 after end of life? And if somebody decided to do that, what actions would they have to take? - I would definitely not recommend staying on software that is known end of life and could have any number of security exploits actively being taken advantage of in the wild. That seems like a really big risk. That said, there are lots of sites still on Drupal 6, maybe not lots. There are sites still on Drupal 6 and some still on Drupal 5 that are out there. And those people have just sort of accepted the risks that somebody may get in at some point. And at that point, they might choose to retire the site.



 Some people may never notice that their site has been hacked and taken over and is now Bitcoin mining or whatever people are doing with it. So I would definitely don't recommend it. But if that is the most realistic option, I would say look into long-term support vendors. And I don't know if there are any official long-term support vendors for Drupal 7 right now, but I would imagine come January, 2025, there will be agencies that pop out of the woodwork that have their own clients that need to remain on Drupal 7 and they need to figure out how to support that in a way that is secure and realistic for those people. And so I would say you definitely want to get on some kind of plan where you have access to updates, security updates after end of life.



 I don't know what that's gonna look like, but that would be my first recommendation.



 And then another one would be if you can think of it as like a temporary stay. Like if you have to be on Drupal 7 after end of life, say, okay, we need to save money for six months in order to afford an upgrade. But maybe also consider like limiting what you're allowing people to do on that website after that point to sort of protect as much as you can against somebody's password getting leaked and that account now having access to do stuff that most security exploits, really bad ones,



 require some level of permission on something. They're not usually all anonymous attacks, right? And so if you can limit the number of people who have admin access, you're gonna be setting yourself up for a little less risk long-term. Don't let anonymous people use the rich text editor, just like stuff like that. You could lock it down a little bit if you know you're on an insecure platform.



 - The long-term support thing is interesting to me because I think like Pantheon has already at one point said they're gonna be, anybody who's on Pantheon with Drupal 7 will have access to long-term support through them.



 But I think I've only ever heard that in terms of core and I don't know what that means for all the contrib modules that sites inevitably have. I've never heard of long-term support that includes like any number of contrib modules. So I think that's probably a big red flashing sign too in terms of going to long-term support is the contrib support.



 - Yeah, that's a good point. And also for people who are considering staying in Drupal 7 even past the end of this year, keep in mind that the activity on the contrib space is very, very slow in the Drupal world right now. So even if these modules are supported, they're not getting regular updates. They're not getting attention because most of the Drupal community is really focused on modern Drupal now. So we're gonna see that continue to slow down just like anything you have a feature you're waiting for in a module, you're probably not gonna get it in Drupal 7. It's gonna go into modern Drupal and no one's gonna move it back. So being on a platform that is like actively maintained is definitely gonna be better for you.



 So something like Backdrop, right? We have copies of all of these Drupal modules and you see a lot more activity in the Backdrop queue than you do in the Drupal queue just because everyone's still contributing to those projects on a daily basis. So yeah, just keep an eye out for the contrib space. You'll also start to see, I imagine more of those modules becoming unsupported. There are active maintainers on them. They're gonna fall out of security coverage in Drupal as well before the Drupal 7 core end of life. So just keep an eye on contrib, good point, learning things.



 - Yeah, and I think there's one other thing too, which is like PHP support, MySQL support, that kind of thing. Like as PHP upgrades, Drupal 7 won't be updated to manage that either. So it's not just Drupal that will slowly get out of date on your server, it's all the other services too. - That you have to worry about.



 So we've mentioned Backdrop many times throughout the show already, but we haven't defined it, Laryn. Can you tell us a little bit about Backdrop CMS? What is it?



 - Yeah, so Backdrop CMS is the Drupal fork, which was forked technically from a space slightly in between Drupal 7 and Drupal 8. So it has some of the improvements that went into Drupal 8, but the largest portion of its base is Drupal 7.



 And I wasn't around at the very beginning, but it was built by people who love Drupal, people who work at Drupal, have spent a lot of time building Drupal.



 And so Backdrop builds on all of that stuff that people love about Drupal and sort of keeps the flexibility and the power that Drupal brings, but it does it in a way that doesn't break APIs and change things as dramatically underneath the hood so that we could have that direct upgrade path that we talked about earlier and that it can run on servers that don't need as much power and things like that. So it basically is a,



 obviously the word fork kind of visualizes that for us, but it's taking Drupal from a certain point and improving upon that base.



 So I think that Backdrop has done a pretty good job of emphasizing the backwards compatibility and the stability and the base of Drupal and that kind of thing. But I think that the other part that maybe isn't highlighted as much that I would love to see highlighted more is the future direction and the improvements that have been built upon that base.



 So I think it's, at this point, it's diverging to some degree, even if it retains a lot of that base that it's built upon, but it's an alternative to Drupal, especially for people who've got Drupal 7 sites.



 I think it should definitely be part of the conversation as you're considering what to do with that site.



 I've heard more than one person describe it as kind of trying to hit a sweet spot between the complexity of Drupal and the user friendliness of WordPress and finding a spot in the middle that gives you the power and the flexibility, but it's also very user friendly and doesn't have a high barrier for entry.



 So we have a listener question here.



 And previously we talked about how backdrop, you know, provides kind of an upgrade path for Drupal 7, but James has a question saying, "Some people have mentioned backdrop "has significantly changed since it forked. "Does that affect migrating from Drupal 7?



 - It does not affect upgrading from Drupal 7 because every time we add a new feature, we make sure that it still has an upgrade path as part of it. So for example, backdrop core has about 70 contributed Drupal 7 modules in it. Some of them are just the modules you enable it the same way you did in Drupal 7 and a whole bunch of them have been integrated into the system, so things like token impact, auto are no longer modules.



 Token is part of the system module, path auto is part of path module. So you don't turn them on anymore, but you have those in there. But when we do that, we also include the upgrade path for people who are running token impact, auto and Drupal 7 so that their move into backdrop is still going to be seamless and the upgrade path will handle any conversion of variables to configuration or database changes that are required in order to do that. So we're adding a bunch of stuff, but we're not breaking the upgrade path. And we have automated testing that helps the upgrade every time we add something, so we'll find out something, put it in there doesn't work right, we're going to fix it and we're going to make that upgrade path as seamless as possible. So backdrop has a list of principles, and the number one principle is backwards compatibility is important, so we don't ever do anything without considering how it's going to affect the upgrade path. So we're going to do that. We don't ever do anything without considering how it's going to affect currently running websites or people coming from Drupal 7. - So I have a follow up question to James's question there around the backwards compatibility.



 When you guys are developing upgrade paths and thinking about backward compatibility, is there additional cruft that kind of comes into backdrop because you have to think of all of that backwards compatibility? I know, and this is probably not a great comparison, but it's the best one I got.



 WordPress, right? Everybody's like, oh, WordPress is backwards compatible to like the beginning of time, and it makes it big and kind of complicated.



 Are you guys thinking about that when you're developing the backwards compatibility with backdrop and how you can kind of minimize that footprint?



 - Yeah, definitely. So as far as the upgrade path goes, you're only ever going to run that once, so having that code around isn't really going to affect the way the rest of your system operates. So if you need to do a database query during the update, that's fine. We don't consider that a problem.



 But for ongoing backwards compatibility,



 we have changed API changes in backdrop. What we've done is a lot of the code is object oriented, but we know that there are a bunch of Drupal modules that call like node_save. So we have a Drupal compatibility layer, which is just one file that contains wrapper functions in it, essentially. And each one of those functions is like a wrapper around node arrow save, right? So you can still call these older functions. You can pass in whatever parameters they had before, and it's going to leverage the new API in order to deliver the same result. So we're not supporting two APIs, which I think is where people would be concerned if there's a lot of corrupt. We're just making sure that any module that was using the old API will get the same result as a module that's using the new API.



 And that Drupal compatibility layer is also something you can turn off. So it's on by default right now when you install your backdrop plate. But if you don't want that code to run, you can just go into your settings file and disable the Drupal compatibility layer. That file won't be loaded, and you won't have any of those wrapper functions.



 Oh, that's cool.



 That's clever.



 In terms of the other example that popped to mind was recently, you know, jQuery was updated to the most recent version.



 But for compatibility reasons, the older version is still there, and it doesn't get changed automatically for older existing sites. Newer sites by default will use the newer version. And I assume at some point that older version will be deprecated or completely unremoved, but at the moment it still has an option for either of those for that type of reason.



 So, Laryn, we have another question from James asking about if there will be other forks.



 Because as we talked about in the pre-show,



 the backdrop fork was 10 years ago. Not the release date, but backdrop itself was 4-10 years ago. It's been a long time. A lot has changed in the world. Do you think there will be other forks?



 I mean, my first reaction to that question was, you know, it's open source, so who can say? It easily could be. And then I remember there is actually, is or was already a fork of backdrop called Silk Screen, which I haven't looked in on it in years now, but I think it was initially forked because it was, Jen, was it the database abstraction layer was removed in backdrop, and that was one of the things that they wanted to keep in Silk Screen? So it was, I mean, the developer who forked Silk Screen,



 you know, I think I would say it was friendly in that he would go back and forth and do things for backdrop that would then get pulled into Silk Screen, and that kind of thing. I don't know if you have any more comments on that, but yeah, I haven't heard of any other plans besides that for forks, but who knows?



 Yeah, Silk Screen is great. John Franklin is the guy who is primarily working on it, and he's been co-releasing security releases every time there's a backdrop release. There's usually Silk Screen release. He's been in our issue queue making recommendations, arguing for why some things might be important where we might have said, oh, that doesn't apply to our audience. So it's really helpful to have that fork push back on our project a little bit to sort of make us think things through. We consider Silk Screen like the press flow of backdrop. Like it takes backdrop, which is intended for every man sort of thing, and push it a little bit farther into the enterprise space. So the same way Silk Screen did that for Drupal, or Press Flow did that for Drupal, Silk Screen is doing that for backdrop. So we're sort of saying, we aren't focusing on that because it's not our primary audience, and Silk Screen is saying, we can do that. We're going to focus on that audience to help give them features they need. So yeah, I think it's been really beneficial to backdrop as a whole, and forking generally is a good thing.



 I don't know of any other forks of backdrop. I also don't know of any other forks of Drupal, which I'm not sure which questions I was asking there. But yeah, I would imagine at this point,



 the reason for forking Drupal is probably because modern Drupal is so different from older Drupal, and backdrop has already done that. If there is another reason that comes up for forking Drupal, something about, you know, I want Drupal 10, but without composer or something, that would be a whole other direction, right? It has nothing to do with what we're doing, you know, and it would have to be another completely different project. I haven't heard of anything like that happening. I think it's sort of going the other way where they're trying to move more things into being composable rather than less. So yeah, I don't know. I don't know. It could happen. Open source, crazy world. People do lots of things they want to do. So we'll see.



 And I hope nobody takes the idea of removing composer from Drupal.



 That feels dangerous.



 Okay, so let's talk specifically. We've talked about backdrop. We've talked about what it is. We've talked about how it can help you kind of upgrade or get away from Drupal 7 before end of life. But I want to get kind of specific on how backdrop can help people get off of Drupal 7. Is there automation built into it? Is there, you know, what are kind of some of the benefits that people have been seeing, realizing, actualizing, moving from Drupal 7 to backdrop? Sure. So there are a lot of things about backdrop that are sort of aimed at the people coming from Drupal 7. Obviously, that's what backdrop is most similar to, and it's what we've sort of envisioned backdrop being like Drupal 7 plus whatever improvements we need to make to it. So having built-in upgrade path, I think, is number one. The biggest benefit to people coming from Drupal 7, knowing that everything that's currently in core in backdrop, which is, you know, most of what was in core for Drupal 7 plus those 75 contrived modules, all of that upgrade is going to be handled for you. It's going to be really great. And then there's a bunch of other stuff like once you're on backdrop, we're also going to continue to make that long-term maintenance process much easier for people. So sort of the when you do cost benefit over time, like our goal is to make long-term website ownership also more affordable. So if you're already feeling sort of constraints of your Drupal 7 project and you're fearing what you might get from, you know, moving to something completely different, whether that's Drupal 8 or, you know, Node.js or whatever it is, backdrop is trying to make that path much easier for you, built-in upgrade. And then there's also a bunch of people in our community who are working on, like,



 one-click migrations as an alternative to upgrade. If you do want to completely rebuild your site, that's an option to backdrop to.



 So, yeah, just trying to make that process easier. There is also one module I would like to promote a little bit, which is called backdrop upgrade status. And it's a module that will generate a report on your current site. It will tell you which modules already have versions available for backdrop or not. It will tell you all of your content types if they have no notes in them. It will indicate that it will help you do the cleanup task before you do the upgrade. And it can also be really useful for trying to get an estimate of, like, what is it going to look like to move this exact site onto backdrop. And so that's the Drupal 7 module. You can get it on Drupal.org. But, yeah, it's just trying to make that transition as easy as possible for people in terms of visibility into what's going on their current site and then getting from their current site onto backdrop. So, Laryn, I'm actually going to adjust that question just a little bit for you, because I think it's, you know, working it at an-- at an, you know, works on backdrop projects.



 How are you guys seeing the backdrop help, you know, your clients? And when do you guys typically recommend, like, oh, you're on Drupal 7? Well, maybe instead of going to Drupal 10, let's go to backdrop.



 Yeah, I mean, that's a good question. And I think it's honestly under discussion quite a bit in terms of when to recommend backdrop and when to recommend Drupal 10.



 But in terms of the first part of that-- I'll get to the second part. But in terms of the first part, one of the things that I've found super helpful in terms of sites that are coming from Drupal 7 and going to backdrop, because there are, you know, there are elements that need to be developed. You know, the theme doesn't work automatically because backdrop has this layout system now and the theme and the layout are broken up into separate pieces and so on. So as you're, you know, working on the upgrade process, the other-- another huge piece of backdrop is configuration management. And so what I've found really helpful in terms of the upgrade process is to just take a current snapshot of the current site and, you know, figure out what I need to do, what modules I need to get all that taken care of, run the upgrade locally, and then I can do all kinds of stuff locally and export my configuration, save that in staging.



 And then, you know, whatever-- however long it has been since I took that first database dump, get a new one, run that upgrade process, and then sync the configuration and all those configuration changes that I've been working on just automatically come over.



 And honestly, it feels like magic sometimes how well that works. The-- one of the recent projects that I did, we ended up-- I mean, we scheduled a day for content



 from the time I took the final database dump on live and had it upgraded and in backdrop and configuration synced and everything was, you know, half an hour, maybe slightly more.



 And so the fact of how quickly that can go and capture or keep all the development work you've been doing locally and then apply it all in one big lump sum is one of my favorite things about the upgrade process, honestly.



 And then in terms of when to recommend, I'm not in sales. I'll start with that. And that's my-- I'm not a lawyer. I'm not in sales. So I don't know exactly what the conversations are like there. But I think part of it is, is there a push factor? Is there something in Drupal 10? Is there something in modern Drupal that you are really attracted to, that you really need? You know, Atten does Mercury Editor, obviously. And so that's a big thing. That's not available in backdrop. That's not on the roadmap that I've ever seen or thought of for backdrop, that type of Mercury Editor interface. And so that's one big push factor that Drupal 10 instead of backdrop, things like that, things that are only available in D10.



 And then budget is obviously another big one. If a group comes and says, this is our budget, that can help make that decision pretty easy.



 But, you know, if there's no big push factor, if you don't have a whole ecosystem built on modern Drupal that this new site needs to fit into, I think backdrop should definitely be part of that initial conversation.



 Before we move on, I kind of have a question about the scale of these types of upgrades, right? So just to kind of put this in perspective, I have, let's say I have a moderately complex Drupal 9 site that maybe uses 15 modules and has two small custom modules, right? Updating that Drupal 9 site to Drupal 10 probably is going to be 20 to 25 hours, right? And a lot of that's just going to be updating modules to the Drupal 9 and 10 compatible version, doing some testing, maybe creating a couple of issues or testing some patches to help move along.



 But yeah, we're looking at, you know, maybe maximum 30 hours, unless it's a very, very complex site. So if we're taking like a site that's medium complexity, so Drupal 7, you know, Drupal 9 has 15 modules, that same equivalent Drupal 7 site probably has 50 modules, if we're being honest.



 And maybe, you know, five custom modules to do little tweaks here and there. What kind of timeframe are you looking at for an update for those? Is that, you know, 30 hours, 100 hours? Like, what kind of timeframes are these upgrades taking?



 So I can speak to that a little bit, Laryn, and I think it would be better on the bigger end of things, so for smaller sites like that.



 I have done one of those in less than one day, so less than eight hours. And in that case, that included doing the layouts in the theme. It included removing an e-commerce component and including reporting one contributed module and adapting one custom module. And I think there was more than 15 modules on that site in Drupal 7. I think in backdrop, there were something like 10, again, because they're all, you know, in core now.



 But yeah, that was sort of a challenge to myself because this is the site where they were thinking about moving to something like WordPress. And I was like, well, because of your data structure and your existing content, I think it would be better for you to be in a CMS. Let me see what it's going to cost to do it. I did it today. That was really exciting. For a slightly more complicated one, it usually takes, like you just described, it would be like a week, probably. It does depend what those 15 modules were, right? Like if one of them is commerce, that's going to be a very different scenario than if all of them are just providing custom blocks or specific types of blocks or something like that. But there are lots of the API that is entirely unchanged, and so you don't need to touch them at all. There are some, you know, variables to configuration changes that you can sort of find replaced to get through. And then there's like a little QA on the upgrade itself, and it's generally pretty quick.



 Just to tell you curiosity, you can do commerce with backdrop or is that not not supported?



 So we do have a version of the commerce. You can do commerce.



 Yeah, I don't think anyone's running it.



 No, I don't think it's fully supported. So a lot of people are running Uber cart with backdrop. Yeah, and I was going to just tag on to the earlier question about the timeframe for upgrades. I think maybe D9 to Dparson to a D7 to backdrop is not quite right. But I think the one of the other developers at Adden did a I can send you the link later. I don't have it handy or remember the specific numbers, but I want to say did an analysis of an estimate to move a particular very complex site from D7 to modern Drupal or D7 to backdrop. And I think it was a quarter of the cost to go to backdrop, something like that.



 Interesting to see where the costs came in, whether it was just like development time of like troubleshooting or if it was like refactoring code. Right. And that one, it was a lot of custom code. And so since it could largely work on backdrop, that saved a ton of time. Yeah. Okay, that makes sense. Yeah. So it sounds like at least in the beginning, going from Drupal 7 to backdrop versus Drupal 7 to Drupal 8, rebuilding was one of the considerations, but also kind of like support like Drupal 8. Just a lot of modules never made the leap. Right. In the years since the Drupal community kind of has made either workarounds or found solutions to those or made those modules. Right. So really, I think there's some exceptions. But in general, module coverage is no longer an issue.



 It's rebuilding and refactoring code and refactoring large, complex code bases is always, always complex.



 It's always going to take time. So it sounds like backdrops.



 Real value at here now at this point has changed and that's you don't have to port that custom code. Right. Yeah, I think that's definitely one of the one of the things I think the other the other thing, another thing is because it's not built on a on a stack of dependencies that are each have their own end of life and their own things that are sort of driving them. End of life for certain versions of Drupal or whatever. There's going to be less of those. You know, now you need to pay us another 30 hours to go D9 to D10 because we're not actually we're just getting up to the current dependency stack requirements. That kind of that kind of idea. So in terms of the total cost of ownership, it should be less over time as well because of those types of considerations.



 Good point.



 It might also be worth mentioning, especially for people who aren't familiar with backdrop that we changed the way external libraries are managed a little bit so you know Drupal decided to use a dependency manager. You know, if you're a composer to handle all that, that's what like the PHP community at large was doing and is still doing, which I think was a good move. But we went the other way with backdrop and said that backdrop is going to be our dependency manager. And so all of the contributed libraries that you are running will be part of a module and that module will work with that version of that library. And so you can use the project browser in our in backdrop is called the installer module. You can use that to install anything and it'll bring over the module in the libraries that it needs. And you know they're guaranteed to work together. And so it's not that we don't have dependency management the way Drupal seven didn't you had to use like libraries module and you still had to go download your own libraries and figure out where to put them and hopefully you get the version that works because it's not newer than when the module is written in the API. We sort of took that burden of dependency management that was in Drupal seven and put that on the module maintainers instead of the site owners and now the site owners can use backdrop itself to handle the projects and their dependencies. So it's a it's sort of a very same same problem solved in very different ways for the two different projects and you see that a lot in you know we've got the same solutions in a lot of times in modern Drupal and in backdrop but they were implemented very differently. Configuration management is another one where like in backdrop this and Jason files and the triplets and the ammo files and we did that because one of our principles is making sure that your site runs fast and Jason was just significantly faster option that allowed your active configuration to remain on disk, which is much faster than having it in a database. So there's just a bunch of stuff that.



 Decisions were made based on our principles that were solving the same problems that existed in Drupal but for backdrop audience and.



 Awesome so shifting gears slightly Larry can you tell us a little bit about backdrops by annual event online event.



 Yeah.



 So backdrop live it's built on built around an unconference model which I wasn't familiar with before backdrop live started using it but I is pretty cool.



 I think I used the phrase earlier and I totally stole it from someone else who used it because I think it fits so well but you know this idea of a low barrier to entry.



 In terms of using the software I think also applies in this unconference model so there's a couple days depending on your time zones where backdrop users all around the world have time slots that have virtual sessions and you know this hour might have three rooms available and if you have a topic that you want to talk about. You can claim one of those claim one of those rooms and put the topic up and then anybody who's interested can come and it's it's you know sometimes it's by people that are working deeply in that topic and want to share something and hear what other people think or.



 feedback on something and sometimes it's people who have no idea about the topic but want to know more about it and so they post the topic and whoever's interested comes and it's more. I would say it's more conversation based sometimes you know there are short demonstrations or presentations.



 But a good portion of each of those blocks of time is set aside for conversation and. You know just getting getting community.



 Commentary and discussion around a particular topic sometimes I think hearing what other people are doing can be super beneficial whether or not they're quote unquote the expert.



 You know the the subject matter expert or whatever I think it's it's pretty cool to get people of all different stripes in a room talking.



 So I have a question and this this actually came to mind Jen earlier on when you were saying. You know that there there are folks that are you know have you know custom modules that they built for Drupal Drupal 7 and you know features that they really liked in Drupal 7.



 I'm wondering do you think that you know backdrop and being you know being the fork at this point a very different fork of the Drupal 7 project.



 Do you think it's negatively impacting Drupal 10 adoption.



 My instinct on that is to say probably not. I think that the kinds of people who are coming to backdrop couldn't or don't want to move to Drupal 10. I don't think there are a lot of people who are feeling ambivalent about whichever way it could be and choosing backdrop over Drupal 10. I feel like usually the people who are moving back to have a reason for being there. Pardon that because we're not super well known. You have to do some hunting to figure out what are the Drupal alternative to find out that we exist.



 But yeah I think if your company has already has a Drupal development agency that's maintaining your site. They're going to be able to take you to Drupal 10. If you are really involved in the Drupal community and you're doing it yourself you're going to be able to get yourself to Drupal 10. It's only the people who can't find a way there who are going to be looking for alternatives and those are the people who are probably going to find backdrop.



 So I agree with what you just said. I'm just curious as to the we all know that developers can sometimes be stubborn or resistant to change.



 I'm wondering what or have you seen maybe this is not accurate but are you seeing people that are kind of adopting backdrop because they're like Drupal 7 was great. We don't need to move to Drupal 10 and I just like it the way it was.



 There are definitely a few of those people but I feel like in the Drupal community it's a lot more of like everybody else is doing it than it is like I don't want to change. And that might just be because open source community sort of self select for that sort of mentality. But I've seen a lot of developers like sort of power through the pain of the learning curve to get to Drupal 10 because everybody else is doing it. A lot more of that than people who are like I don't want to learn anything new.



 Yeah I know most of the people in the backdrop community are still interested in learning new things but there are new things that are solving the problems they're facing not like how to build a CMS because that sort of solved problems. Right. There's lots of different ways to do that and they might just choose this one because it's a better fit for their projects or they enjoy it more.



 Yeah, so we have a lot of people who've been in the Drupal community for a very long time. A lot of them have been very active in the Drupal community for a very long time. A lot of them have never been active in the Drupal community because they didn't feel they were needed because there's plenty of active developers for Drupal. And then they show up and back up and they're like, oh, I'm needed here. I'm really grateful for those people getting involved. So yeah, I don't know that I've ever had someone say I don't want to learn it. Usually the people we get have tried to learn it, decided they don't like it and then come back to backdrop and saying this works for me. I'm going to stick with it.



 Just so I curiosity, has backdrop maybe not resolved but contributed to issues in the Drupal issue queue? Oh, for sure. Yeah. We have an organization on drupal.org and at any time Core collaborates with something they put the backdrop in as a supporting organization so you can go and see which issues it's credited on.



 Yeah, there's a lot of collaboration. I'm on the Drupal security team. There's a lot of collaboration on security issues because those problems affect both projects. So there's a lot of sort of, hey, we're not going to tell you what this problem is but test this thing and let us know if you can hack in or whatever. So using each project to help find solutions is really great. Also, there's a lot of usability improvements that have gone into backdrop that people have seen and said, oh, I want that in Drupal. Same thing the other way. People will see something in Drupal. Oh, I want this in backdrop and it goes into backdrop. So I think both projects are sort of pushing each other forward, which I think is really good.



 Cool. I think if I can just tag on to your question earlier about whether backdrop is negatively impacting Drupal 10 adoption, I think maybe that was a concern. I'm guessing maybe that was a concern early on, but it's been so long and these,



 whatever it is, 400,000 Drupal 7 sites that I think at this point, people are just like, they're not all going to go to Drupal 10. We need this. There's this whole soft landing initiative that's let's get let's help them get somewhere and I've seen



 backdrops included in that and WordPress is included in that and Drupal 10 is obviously included in that. So I think that's been a good warning that I've seen recently. Yeah, we're going to have a show in a couple of weeks talking about there was a recent blog post about the future of Drupal and some of those points I think kind of are going to be covered in that show where people are very aware of the fact that there are a lot of Drupal 7 sites and I think there are some people that would like to see all of them move to Drupal 10 and it's



 a great way to kind of, you know, I don't know that it's realistic or feasible based on some of the things that we talked about today. So I think we have to kind of realign what our expectations are and I think, you know, I think backdrop is a great solution for some of those folks who are kind of struggling with making the leap off of Drupal 7. So, Jen, if somebody does want to get involved with the backdrop project, they're just hearing about it. They think maybe they would be good candidate or they have a client that might be a good candidate. How can they get involved in backdrop?



 We have a contribute page on the website, backdrop. PMS.org slash contribute that lists all of the ways where we would love to have people getting involved. Obviously, if you write or maintain code, we love to have some great information.



 Coder, there's a lot of places you can get involved on GitHub with core or contrib. If you don't write code and just use code, we have a forum and a live chat where you can jump in and start talking with people and sharing ideas. We have a need for designers and people who have an eye for aesthetics and user experience and we want them to get involved. We have a need for maintaining documentation. We have a really rich user guide, but core is changing all the time. Getting people to keep the user guide up to date with that would be really valuable. There's just so many places that we could use help. So our online chat is backdrop.zoolabchat.com, I think, and that's a good place to jump in right away and say, "Hey, what can I do?" And there's going to be someone there that would like to answer your question. Also, I would say if you're not familiar with backdrop, give it a try. See if you like it. What we find is that if you liked Drupal 7, backdrop will be very familiar to you. And if you didn't like backdrop or didn't like Drupal 7, you'll probably find many of the things that annoy you have been resolved.



 So definitely have a look at it and see what you think. And if you really want to get involved, we would love to have you.



 All right. So, Laryn, last question. I'm sure backdrop has a roadmap. And I'm wondering what are some of the big features or maybe the feature you're looking forward to the most that are on said roadmap.



 Well, actually, the things that I'm most excited about are not on the backdrop core roadmap. They're more personal things I'm working on. Right. There's a couple things that come to mind.



 One of the projects I've been working on lately is actually bringing the Gen Admin theme to backdrop. And it started out as a bit of just a thought experiment. Like, could this happen? Could a modern Drupal theme be ported to backdrop?



 And then I started it and I had good success out of the gate and started getting excited.



 I wasn't sure I was going to do it sort of one to one. And so I thought maybe I'll rename it and I was calling it tonic for a little while. And then I sent a message just like I think it's nice to send a message to people working on the other end of an open source project if you're using their material.



 I sent a message to Sasha Eggenberger and said, like, you know, Jen is awesome. Thanks for all your work on it. And FYI, I'm trying to carry the work you're doing into another venue here and bring it over to backdrop.



 And then he got excited about it and he's ended up actually helping me do it. He's signed on as a co-maintainer on the backdrop version of the theme. And he's done some some really big commits to do that to do that work. So that's been really awesome.



 And that's part of the beauty of open source that really gets me excited and makes me feel good.



 So that's currently in an alpha state, but it is available for people to download and test out.



 And the other thing, once I'm a little further along with that one, I have plans for the paragraphs module to tap into backdrops core layout system and do kind of a backdrop version of paragraph layout paragraphs. You know, to use the same before that Jen mentioned earlier answering the same question, but in a different way. So it's not going to be identical to what is it in modern, you know, tapping the paragraphs module into a layout system that's specifically backdrop-esque. And that's the two other things that I'm kind of excited about right now. Cool, Jen, what about you?



 I can talk about a couple of things I'm excited about in core.



 We added this self update feature a couple of years ago where if you want to update core, you can push a button and say update core and it'll update core and then you can run the database updates and you're done. You don't have to worry about downloading and unpacking and all that stuff. We want to make that process automatic. It's obviously a lot easier for us than it is for Drupal and we have an initiative or an issue.



 We're currently working on like package signing between where the code comes from and where it goes just to make sure that if we're going to make that process automatic, we want to make sure it's as secure as possible. So that'll be fun. And then for backdrop two, I'm looking at a couple of things that I'm going to talk about. For backdrop two, I'm looking at all of the deprecated stuff that's been deprecated through the 1.X lifestyle getting removed, which is also exciting. So that's the clean up part that we get to get to where you can remove some of the crust. So that'll be nice. And that's pinned to Drupal 7 being the end of life, I imagine, because you've committed it. No. So we set the backdrop to date back when the very first Drupal 7 end of life was announced and we wanted to give two years between the Drupal 7 end of life and backdrop next release so that anyone who was still on Drupal 7 after the end of life would have two years to get off of it before they needed to move to the next version of backdrop.



 And then when Drupal 7's end of life moved, we moved back to the end of life. And then when it moved again, we're like, we don't need to keep moving. Backdrop two is released. So it's been January 2025 for the last number of years, and it just happens to be that that's when Drupal 7's new end of life will be. So I don't know if the Drupal community knew that that was our release date. Drupal 7 end of life is going to be the fifth of January backdrop releases on the 15th of January. So it's going to be like 10 days. We chose January 2025 before it was cool. Yes.



 Well, Jen and Laryn, thank you for joining us. This has been a wonderful update on the backdrop community.



 It's always fun to have you guys have you on and chat about how things have changed.



 Thanks for having me. It was fun.



 Do you have questions or feedback? Reach out to Talking Drupal on 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.



 And you can promote your Drupal community event on Talking Drupal. Learn more at TalkingDrupal.com slash Tdpromo. 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 newsletter at TalkingDrupal.com slash newsletter.



 And thank you, patrons, for supporting Talking Drupal. Your support is greatly appreciated. You can learn more about becoming a patron at TalkingDrupal.com and choose "Become a Patron." Well, Laryn, if our listeners had questions for you, what's the best way for them to get in touch?



 I think that email is fine. I'm also available, and my email address is Laryn. That's L-A-R-Y-N at atton, A-T-E-N dot I-O.



 I'm also available on Mastodon, and either of those is fine.



 Sounds good.



 Jen, how about you?



 I'm Jen Lampton, various places on the internet, drupal.org, Twitter, various Mastodon places.



 But yeah, the easiest way to get a hold of me is on Backtrap Chat, which is in Zulip.



 How about you, Jen?



 You can find me on all the major social networks, drupal.org, at johnpicozzi, and you can find out more about EPM at E-P-A-M dot com.



 And you can find me pretty much everywhere at NICXVAN and N-I-C-X-V-A-N.



 Thanks, everybody. If you've enjoyed listening, we've enjoyed talking.



 See you guys next week. Thanks, everyone.