Smashing Podcast Episode 17 With Angie Byron: What’s New In Drupal 9?

About The Author

Drew is a Staff Engineer specialising in Frontend at Snyk, as well as being a co-founder of Notist and the small content management system Perch. Prior to this, … More about Drew ↬

Email Newsletter

Weekly tips on front-end & UX.
Trusted by 200,000+ folks.

In this episode of the Smashing Podcast, we’re taking a look at what’s new in Drupal 9. What are the major upcoming changes to this nearly 20-year-old open-source project? Drew McLellan talks to Drupal core committer Angie Byron to find out.

In this episode of the Smashing Podcast, we’re taking a look at what’s new in Drupal 9. What are the major upcoming changes to this nearly 20-year-old open-source project? Drew McLellan talks to Drupal core committer Angie Byron to find out.

Show Notes

Weekly Update

Transcript

Photo of Angie ByronDrew McLellan: She is Senior Director of Product and Community Development at Acquia, a company you’ll know from their software and services built around the Drupal ecosystem. She’s been a Drupal core maintainer for nearly 12 years, as well as being an author for O’Reilly and an open-source evangelist who just lives and breathes Drupal. Joining us from near Vancouver, British Columbia. She’s passionate about getting new people, especially women into open source. We know she’s a longstanding Drupal expert, but did you know she once taught a dolphin to make marmalade? My smashing friends, please welcome Angie Byron.

Drew: Hi Angie. How are you?

Angie Byron: I’m smashing, Drew. How are you?

Drew: I’m very good. Thank you. I wanted to talk to you today about something we’ve certainly not covered on the podcast before. And I’ve rarely actually touched on Smashing Magazine articles over the years, despite it being a hugely popular open-source project with a massive community. And that of course is Drupal. Now, I’ve deliberately not described what Drupal is in my introduction because I feel like there could be a whole generation of web designers and developers who’ve never really come across it. And there are those who might think, that we know what Drupal is all about, but that could be based off of a view formed 10, 15, 20 years ago almost. What is Drupal as it stands today?

Angie: We call Drupal a content management framework. And what that means is it’s a generalized framework that you can use to make websites, you can use it to make mobile apps, you can use it to make just about anything you can imagine. But it’s very content structured, content based central system. It’s used to power one in 35 websites in the world. It’s out there and people use it. It’s been used a lot for government websites, media websites, just about everything that you can imagine. It’s even been used to power say, the princess cruise ship schedules and things like that. It’s used in a lot of different capacities.

Drew: How does it differ from other content management systems that people might have used in the past, such as WordPress or static publishing tools like Hugo and Jekyll?

Angie: I like to say that if you know what you want is a blog or another thing that WordPress is really good at, WordPress is a great choice. Similarly, if you know that you need some highly customized software that can only work with one particular backend system or things like that, a custom CMF framework like Symfony or something might be a better choice. Drupal is great because it spans both. It has a user interface, so you can create content just by clicking and filling out forms. And you can extend it with its API, but it’s built to actually allow you to do a tremendously amount of powerful stuff just by being in your browser, clicking around forms and buttons.

Angie: I use it a lot because I often have customers who don’t really know what they want. And so, they think that they want to blog and then it turns out that, “Oh, but we also want an ecommerce component with this blog. Oh, and we also need like a forum with five star ratings and reviews and these kinds of things.” And with Drupal, that’s just a check boxes to start adding new functionality like that versus with WordPress, it might mean, putting a couple of different solutions together that you then have to integrate. And with custom code, that’s obviously custom codes what’s going to be a lot of work for you.

Angie: Drupal has a whole library of contributed modules. There are something like 10,000 to 12,000 of these add-on modules that can do additional features. And then out of the box, especially if you haven’t used Drupal in 20 years, Drupal is actually a really full featured CMS these days as well, where it shifts with media layout support, all kinds of different things.

Drew: You briefly mentioned some projects before that are using Drupal. What is the ideal project where somebody would reach for it over something else? Where does Drupal really excel?

Angie: I would say that Drupal is great if you have, let’s say a website or a web presence where there’s a lot of different sub-components and you all want them to maintain a consistent look and feel. Universities use it a lot, for example, because they want to have the consistent university branding across all of the different sub sites. However, they also want to give individual departments freedom to set up their own, say content types. So, say the art department might want to track artists and musicians and things like that. And tying those to works that they’ve produced versus the IT department might want to be contracting like these are the different people we do IT internships for, and these are the different people that work for them.

Angie: And Drupal allows you to model all of that content together and create a dynamic views of it and forms that you can just click together out of the box.

Drew: One of the reasons I wanted to chat to you about Drupal at this point in time is that there’s a major release around the corner. Isn’t there?

Angie: There is. Next, well, I don’t know when this will go out, but it’s June 3rd. So, currently a week from today.

Drew: And that’s Drupal 9.

Angie: That’s correct.

Drew: Now, a big new version of a mature software product always brings with it, big new features. Doesn’t it? What are the headline changes that someone would really notice about Drupal 9?

Angie: If you’re using Drupal 8 currently, the big news for you is that Drupal 9 is really not much has changed. And that’s a big deal for our community because in the past, when you want to move from say six to seven or seven to eight, it was a, I wouldn’t call it a harrowing process, but you could call it something like that where we used to have a philosophy that we’re going to break your code and not your data. We would always be on the cutting edge of the latest things and any major version upgrade would come with it. The needs, support modules and the underlying code with Drupal, and you’d always get the latest, greatest stuff, but it would come at an expensive, costly upgrade process.

Angie: From Drupal 8 to nine, what we’ve been doing is building Drupal 9 in Drupal 8 effectively. And so, Drupal 8, the whole way along has gotten the new APIs, the new features, all these kinds of things in a backwards compatible way. What Drupal 9 is going to do is cut out the backwards compatible stuff and put us all on the latest version of say, Symfony, PHP, MySQL all the newest stuff there so that we have security support for those things for the next three to five years to come. From eight to nine, not much, if you last looked at Drupal though from say Drupal 7, a tremendous amount has changed, because you not only get the innovations that have into Drupal 8, things like mobile experience, out of the box configuration, management, the views module, which allows you to dynamically assemble lists of things available out of the box.

Angie: But you also get the features that have come within the Drupal 8 cycles. Those are things like a media library, workflow management, layout building capabilities, better automated testing and all kinds of other things.

Drew: One aspect I am particularly interested in because there’s something that’s either lacking or patched on messily to many content management systems, is this concept of structured data. What do we mean when we say structured content? And what does Drupal 9 bring us in that regard?

Angie: Structured content is a really fascinating concept and it’s been built into Drupal from the early days. In a CMS like WordPress or Squarespace, something like that, you would say, I want to download the photo gallery feature and I’m going to enable the photo gallery feature, I’m going to get the photo gallery as the person who created it, envisioned it. In Drupal, you go at it a different way. What you do is you create your photo gallery feature from base components. And what I mean by that is you will create a content type called photo. You will add an image field to it for the picture. You will add maybe a caption field, you’ll maybe have attributes to the image and all these other tenets, number fields for the attributes, or sorry for the heightened width text fields for the old attributes, there’s many different kinds of things you can do.

Angie: And then you’ll create a view of photos and you can choose if that photo view is, say it lays everything out in a six by nine grid, or maybe it does it in two columns or whatever, and you can have full customizability over how, and in what way it’s produced. Structured content is interesting because not only can you make your website look like how you want it, but because the content is structured in a generic way through entities and fields, you can also say, for example, create a decoupled react application that talks to Drupal as a backend.

Angie: And have full control over how that’s done, and then take the same backend, make it your website, the same backend make it say a kiosk in the mall where people can select different items. A lot of people make use of Drupal as this general content store that can then be talked to by anything. And the way we can do that is because all the data that the CMS manages is abstracted. It’s not built into the presentation layer. If you use a Wiziwig editor to answer in your content, you’re going to get the images embedded in the body field, and that’s never any good if you want to then take part that body field and display it in a sidebar block.

Angie: Drupal by structuring everything into discrete fields and entities on the backend, makes it so the concept can be mixed and matched really easy.

Drew: That means you could use a Drupal as a headless CMS essentially?

Angie: Yeah.

Drew: That’s pretty much what you’re describing there, isn’t it?

Angie: Yes, absolutely.

Drew: If you’re working in the Jamstack say, or you’ve got a single page app, or you’re building mobile apps or have other less conventional ways of consuming content, you could use Drupal as a content management system just to literally manage the content and then to expose it to those other things via an API or something like JSON.

Angie: Exactly. Yep. JSON:API support is built in and this comes with its… everything about Drupal is modular. If you don’t want the theme layer, you don’t need to have it. Theme layer is what we call like the HTML presentation layer that’s generally generated by PHP. But you can throw that out and say, “I just want JSON:API output of all of my content.” You also get certain features that are built into Drupal built into your app. For example, Drupal has a really robust users, permissions and roles system. You can set up different roles with discrete permissions to do different things on the site or see different pages on the site even.

Angie: And those things will be respected by Drupal and will be enforced by Drupal so that by the time someone actually loads the application at a certain URL, you know that the person who is there is meant to have access to it. It’s really interesting. It’s a cool product to work on because, on the one end, it’s a product made by developers for developers. We started building it because we wanted an easier way to… We didn’t want to have to get called by somebody to change the copyright field at the bottom of the page every year or whatever.

Angie: We just make a box so that they can fill it out. But it’s also a tool made for a carving out a whole new area of people, which is like site builders. They’re like technical, but not necessarily know how to write all the backend code, but they know for example, how to click together these different concepts in order to make these really powerful sites. And so, at any point, when you’re developing a feature such as a media library, you have to not only think about how do we make this really easy to use for a marketer or a content author persona, who’s going to use it every day, but also how do we make it infinitely extensible from the developer side, how do we make sure we have automated tests that cover everything?

Angie: How do we make sure that the output is accessible so it can be translated by screen readers? And all these kinds of considerations. So, Drupal’s really interesting and kind of stands out in its field in that a lot of times you have to pick between a really easy to use front end that doesn’t have decoupled content or a very technical decoupled content thing that you need a fleet of JavaScript developers to work on. And Drupal sits in a middle and a sweet spot where it can be both.

Drew: Because Drupal is essentially traditionally a themed CMS, isn’t it? If you’re looking to build a site, a more traditional site where you’re using a theme to output HTML pages, CSS, a nice responsive web design is going serve your mobile devices, desktop devices, and so on. What templating capabilities would you be looking at in Drupal? What have you got available to use?

Angie: Drupal uses a Symfony library called Twig, and it’s effectively HTML templates with little special characters to do branching, basic branching logic, print variables, that kind of thing. That’s a default output that Drupal does. You have a callback that generates the output and that’s stored into an array. The array is passed to whichever output layer. It could be JSON:API, as I mentioned before, and just put big drop of JSON, or it could be passed to the theme layer, which will then translate those arrays into, this is the header, this is that and it’ll print it into the CSS and HTML variables like that. I don’t know if that answered your question though. Sorry.

Drew: No, you did.

Angie: Okay, great.

Drew: I think last time I used Drupal, it was using maybe Smarty. Is that right?

Angie: Oh, Smarty, yeah. Well, that’s like Drupal 6 days.

Drew: Yeah, it’s Drupal 6 or Drupal 5 even.

Angie: Yeah. Oh, that’s fantastic. Twig is a similar concept to Smarty, but the nice thing about Twig is it better enforces the separation between your business logic and your presentation logic. Twig is not really, you can do it, but it’s not set up as a best practice for you to sit there and start putting a whole bunch of functions and objects and classes and all that stuff in your actual HTML files. Your HTML files, more or less stay HTML files with just the little special placeholders in them. And then your business logical happens behind the scenes in a module or in a pre-process function or something like that.

Drew: That separation actually makes things a little bit more straightforward and safer for developers who aren’t so used to working in the backend world maybe be even more comfortable with doing front end development, but a lot of the hard logic is separated from the HTML and CSS?

Angie: That’s right. And the other thing that you get as a benefit out of that is Twig is really good about auto XSS vulnerability escaping. A common thing that can happen when you’re writing your own theme from scratch is you start printing variables directly. And then someone creates a username like ‘Little Bobby Tables or whatever, that kind of thing and messes your whole site up. Twig is great because it has auto escaping of variables like that. As long as you’re sticking to the APIs and you’re using them directly, you won’t accidentally introduce either a JavaScript or SQL vulnerability in your site just by trying to make your theme look nice.

Drew: And in terms of the content authoring experience, I know a lot of people in the web design industry have seen some of their business go away, particularly at the lower end to these extremely user friendly services, things like Squarespace. How does Drupal compete with that authoring experience that people get from these very polished and sleek services?

Angie: I will say we’ve come a long way. We’re definitely not at a Squarespace level. I’ll just say that flat out. Squarespace has the advantage where they are not building structured content in that round or they’re building pages. And so, the pages are self contained and they can have full control over the HTML in there and use nice front end tools to get at them. Drupal by nature being structured content, I mentioned the benefits are that the content could be mixed and matched. It’s easy to output the content of variety of different fashions. But the disadvantage is that, our front end tools are not, they respect that structured content nature. So, you don’t see like a take over the page in place editing experience with Drupal as it stands.

Angie: However, I will say that there’s a bunch of people doing a lot of work. And so, core itself shifts with in place editing, which is the ability to click on a field and edit it right in place without having to go to the backend. There’s also the settings tray, which if you want to make a quick configuration change to say the site name or the location of a block or something like that, that’s built in there. The layout builder has some drag and drop capabilities in there as well. We’ve really made a concerted effort to improve the content authoring experience in Drupal. We did user testing back in, we started in 2008, Drupal is an old project that you mentioned it’s been around awhile, but we started in 2008 and 2012, 2015.

Angie: We keep doing these every few years, we sit down and the University of Minnesota has helped us with this. We sit down and we go to a real life usability lab with one way glass and eye tracking the whole thing. And through that process really saw that while the backend of Drupal is amazing and people love it because it’s flexible, it’s well documented, it’s architected amazingly, all these kinds of things. People really did struggle with the front end. I made it my personal mission. I know that Dree has made it his personal mission, the project lead, as well as the community as a whole to really bring that quality of Drupal to the front end as well.

Angie: And so, we’ve added a whole bunch of capabilities since then, like a backend admin theme. Some of these content author friendly features like workflows, media, that kind of stuff, and putting it first and foremost in people’s hands so that they don’t have to hand write HTML tags or this kind of thing, which was like the case many years ago.

Drew: One of the things that often attracts developers to simple publishing systems rather than the full stack CMSs is this concept of having everything managed in a gate repo. So, the changes to a life site can be atomically deployed and that gate repo is a single source of truth for the project. You don’t have multiple copies of a database representing different versions of a system gets around this issue of developing a new site feature in one environment, and then trying to figure out how to build that up and deploy it to the live environment, which goals may have changed since they started working on the feature. Does Drupal offer any way to manage that particularly difficult process?

Angie: Yes, starting with Drupal 7, in fact, we had a concept called the features module and what features were, where the ability to combine both module functionality as well as configuration changes and deploy those as one chunk of logical code between environments. In Drupal 8 and nine, we’ve improved upon that ability by building it right into the core system. There’s something called the configuration management system. And what it does is every bit of configuration that you do. For example, what is my site name called, what’s the email template that I’m making, these kinds of things. All get stored into a centralized system and that system has everything else and Drupal is infinitely flexible.

Angie: It can be exported as YAML files, for example, that can just be migrated back and forth between environments. And then it’s really easy to also do a get, diff and find out, “Oh, okay. There’s been changes between the last time that I saw that and I can look them over and make sure they look okay, great import them in.” And there’s both gooey tools for doing that as well as command line tools for doing that because again, Drupal’s always trying to serve both of those audiences.

Drew: There’s always this great opportunity when you make a new major version of a mature software project to deprecate and remove pieces that have had their day maybe features that never caught on in the way that you hope they would and to resolve tech debt and that sort of thing. What changes have been made in Drupal 9 in terms of cleaning house?

Angie: Yeah, we did take the major version bump as an opportunity to really clean house. What we’ve been doing throughout the Drupal 8 cycle is envisioning new ways of doing things. Better, clearer APIs, for example, managing entities or configuration or that kind of thing, or like a more modern JavaScript library for handling drag and drop or that kind of stuff. And during Drupal 8, what we did is we left all the old stuff in place because we didn’t want to break anyone’s site between 2015 and today. But Drupal 9 gave us the opportunity to say, “Okay, as we went along the way, we just marked all these things as like at deprecated.”

Angie: And so, we could find them later and be like, “That’s the stuff we need to clean up.” And so, Drupal 9 went through wholesale and got rid of all of the deprecated functionality. And then there’s a Drupal 8.9 version that’s coming out at the same time as Drupal 9, which has all the BC layers in there, but it’s fully compatible with Drupal 9 to give people a release to move everything up to where it needs to be. But yeah, among the things we did was we updated to the latest versions of all of our dependencies. We have a bunch of JavaScript dependency, some PHP dependencies.

Angie: Those are all on the latest sort of LTS releases. So, we stay on that for a long time. We also took the opportunity to raise the system requirements, which I know people are like, “Oh my God, why my Eskimo 5.7.” But the advantage is that a lot of these older versions of PHP, particularly at PHP 5, there has still hanging around, haven’t been security supported in ages. And so, we’re trying to make sure that our users that are on Drupal 9 are staying secure, not only today, but going forward into the future. We’ve updated those and then we’ve gotten rid of any deprecated APIs that we’ve created along the way. When you start a site with Drupal 9, you’re starting with a fresh slate, no deprecated code on the latest stuff and should serve you for many years to come.

Drew: That sounds like quite a complex development workflow. The fact that you’ve been working on a Drupal 9 compatible version of Drupal 8 and working on Drupal 9 at the same time, getting them ready to release together. How did that work in practice?

Angie: Yeah, it’s worked well because we effectively write Drupal 9 in Drupal 8 over the past five years, starting at Drupal 8, we use a concept called semantic versioning. In the past, when we released Drupal 7, for example, we just left it alone more or less, except for a few bug fixes and maybe keeping it up-to date with the latest versions of PHP that come out and that sort of thing. With Drupal 8, we made the shift to semantic versioning. And what that means is that every six months, we have what’s called a minor release of Drupal and that’d be like an 8.1 and 8.2, as opposed to an 8.1.6 or something, which would just be a bug fix release.

Angie: And every time we do one of these minor releases, we have the opportunity to add new APIs, to add new features and to change the way that Drupal works with the caveat that we always need to leave a backwards compatibility shim in there so that existing sites don’t stop working. All the way along, we’ve been improving Drupal 8 since its initial release. And so, we’ve added features, we’ve deprecated APIs, that kind of thing. So, when we get to Drupal 9, it was a lot of work. I don’t want to mitigate the word there or deprecate that word that the team has been doing because there’s like this whole burn-down chart of all the deprecated things that we needed to get through and all of these contributed modules that needed to update their stuff too.

Angie: But the effort was much lower than prepping for any other major release, because it really was just honing in on those deprecated things, the libraries that are no longer supported that we need to find alternatives for and making sure we’re on the latest versions of stuff and all this stuff works with it. And so, that’s the Delta between 8.9 and nine will be, I think it’s something like 12% reduction in code or something like that is what we managed to do, but otherwise they’re identical because they’re all using the same stuff.

Drew: Wow. It’s just like Drupal 8, but the shackles have come off.

Angie: Yes. That’s a great… I’m going to quote you on that. That’s great, I love it. Have you thought about joining our marketing team? No, I’m just kidding.

Drew: Historically, and Drupal is certainly not alone in this, but there has historically been quite a lot of pain in moving sites from old major versions to newer major versions of Drupal. It sounds like maybe with process of developing a Drupal 9 inside Drupal 8, maybe that has been resolved slightly. So, should moving from Drupal 8 to Drupal 9, actually be fairly straightforward?

Angie: That’s right. Yeah. I think there’s basically three scenarios, so one is if you were running Drupal 8 and every time a new minor release of Drupal 8 came out, you upgraded it to a right away and you started making use of the new stuff. Your path is going to be basically nothing like you’ve already been doing all the work and you’re fine. If you moved to Drupal 8 awhile back and you haven’t been keeping up with the BC changes, there is a little bit of work for you. It’s definitely the easiest upgrade in over a decade of our software anyway. And we have a ton of different tools to help you with it. There’s a dashboard that shows all of the contributed modules and what their Drupal 9 situation is, there’s automated tools for going through and checking your code and flagging any deprecated functions that you have.

Angie: And there’s tools for automatically, going up and finding, “Oh, this is the latest version of your module and it’s Drupal 9 ready? You should go download it,” that kind of stuff. From Drupal 8 to 9, I would say that that part’s pretty well covered. If you’re coming from a prior version of Drupal, say Drupal 7 or below to Drupal 9, that does start to look a little bit trickier, like among the changes that we made in Drupal 8, where for example, we moved entirely to object-oriented PHP and we started utilizing design patterns that were found in other software project, which is a really smart thing to do architecturally, but it does mean that if you had a ton of custom code in your old life, that in Drupal 9, you’re going to need to find alternatives for that.

Angie: Acquia is a product and development called Acquia migration accelerator which is aiming to solve that problem where we’re creating like a nice, react to find application, which reads in your old Drupal 7 data creates equivalent Drupal 8 data for you along with all the modules that you’re going to need that mapped to your old Drupal 7 modules where possible to try and expedite that process quite a bit because we want to make sure that everybody who’s on older versions can still make it over to the new world order where everyone’s on the same version and we’re all working together.

Angie: And then in addition, we’ve also extended the Drupal 7… The community like the opensource community of Drupal their end of life in Drupal 7 as of November of next year. Currently, anyway, we need to discuss whether COVID impacts that or not. But there’s a number of different companies and Acquia is one of them that offers extended support for Drupal 7 beyond that, to 2024 at least. And so, that makes it so that people who have an easy upgrade have a year and a half to get it done. People have a less easy upgrade, have potentially like three and a half years to get it done or longer if they need to. And we’re trying really hard to make it possible for everybody to move over and then building tools like Acquia migrate accelerator to help speed up the process.

Drew: I’m intrigued by the sound of this functionality to scan your code and find out if it’s going to be Drupal 9 compatible. Is that essentially a static analysis tool?

Angie: It is. Static analysis has its limitations. We’ve built a little bit… It’s a library called Rector PHP and you can use on any generic PHP code. It’s not specific to Drupal, but we’ve built a wrapper around it called Drupal Rector, which my understanding is that it adds a little bit of extra things where… There’s certain stuff that we know when something’s dynamically loaded up in the argument that it’s looking for might not be present at that wouldn’t be necessarily addressable, when it’s just in static codings reading dollar signs and stuff like that. And so, there’s been a little bit of extra wrappers to look for some of the most common issues that we find there. And the other cool thing I’m sorry, I got those two confused.

Angie: PHP scan is the thing that scans the code. Rector is the thing that can automatically apply changes to code. And so, we’ve been using those in tandem. PHP standard do the static analysis, plus a wrapper for some Drupal specific things to catch some of the dynamically loaded problems. And then rector is a thing that’s used to say, used to be Drupal_set_message of procedural function. And now it’s this arrow Drupal message or whatever it is and it automatically can make those changes for you so that you’re really only honing in on a couple of tricky your API bits that can’t be automated for you, but we have a dashboard on dev.acquia.com that goes through all of the contributed modules.

Angie: And I’m going to get the numbers wrong, but it was something like 50% of projects are either done already for Drupal 9, or they just need like one or two line changes that can be done with this automated tool. And then there’ll be good to go. The two of those tools together in tandem have been excellent. What I’d like to see is when we make API changes going forward in Drupal 9.1 and 9.2. and so on that we actually couple them with a rector room that will automatically fix them in modules going forward, because then we can cut this transition period down even further in future releases.

Drew: That sounds really smart. Is this something that users with Drupal 8 sites currently can start using in preparation for Drupal 9?

Angie: Yep, absolutely. We’ve been recommending people start doing this since beta, which was a couple of months ago. Yeah, there’s a couple of I don’t know if it’s the best to send you links or something like that, but there’s a project on drupal.org called upgrade status and that’s a nice jumping off point. That’s the thing that gets you the dashboard overview, it looks at all your modules tells you a red, yellow, green, whether or not it’s ready for Drupal 9 and can point you off to the tools that either can help upgrade your site for you or help you upgrade your own code in cases where you’ve extended Drupal beyond its normal capabilities.

Drew: So, say somebody listening to this has got a WordPress site, which they’ve built over the years. They’ve got maybe multiple themes and child themes, dozens of add-ons, it’s draining, it’s bursting at the seams, it’s beginning to sweat and they’re looking at Drupal, they’re thinking, “I like the sound of this. This sounds like it’s built for more of the project that I’ve got here.” What would the process of moving a site on something like WordPress over to Drupal look like?

Angie: One of the features of Drupal 8 is the migrate API, which is something we’re making use of an Acquia migrate accelerator as well. And the migrate API is generic. It doesn’t care what you’re moving to or from, we happen to use it to move from Drupal 7 to Drupal 9, but you could also use it to move from WordPress to Drupal or from Drupal to WordPress for that matter. Please don’t but you could. There are a bunch of plugins for the migrate system and one of them does add WordPress specific knowledge to the migrate system. And so, it sets up WordPress as a source, Drupal as a destination, and it moves things over there. That worked for the data of your site, the actual functionality of your site, you’d have to do some research to figure out if you say I was using this plugin and WordPress that maps to this module in Drupal.

Angie: One future plan we have for Acquia migrate accelerator actually is, once we got the seven to nine problem leaked to try and open it up so we can move people from anything to Drupal because it’s the same basic problem where you’re doing a major upgrade from an external system to another external system. There’s no reason we couldn’t theoretically throw in WordPress, Adobe experience manager, Sycor those kinds of things into this as well and work on migration tools for those because yeah, the more on the Drupal boat, the merrier.

Drew: Drupal has been a project for nearly 20 years at this point, it’s obviously got a healthy ecosystem loads of committers, loads of support. It’s got companies built around it. But obviously a project this big has to keep evolving and keep bringing in new blood. Are there any initiatives to bring new developers into the Drupal family?

Angie: There is. There’s a couple of those. I would say the one that I’m the most excited about that is very ambitious and so we didn’t get it done in Drupal 8, but we’re calling it, the admin UI initiative would be probably need to split that up into several smaller initiatives, but effectively it’s an initiative to modernize the JavaScript of Drupal. And that means a number of different things. Number one, we’re using jQuery because that was the hottest thing back in 2006 or whenever we made that decision. And moving it more to like generic ES 6 or I don’t even know, I’m sorry, I’m not a JavaScript person, so I don’t know what there is to list there, but whatever the latest ECMAScript is, we’d be using that.

Angie: But it also means, drilling down… Drupal 8 in particular already went a long way to making Drupal really accessible for decoupled builds. Having a JSON:API output, there’s a distribution called Contenta that is get you up and running on a Drupal site, catered to headless, if that’s what you want. There’s a bunch of stuff in that area, but I would love to do even more. Knowing that that is more or less a best practice now, it’s like, sort of build this decoupled front end to a backend and really honed Drupal for that purpose.

Angie: I think that’s part of the JavaScript modernization. And then the other part is a lot of our admin experience tools are still in that PHP client server model, or like a person who clicks a button, there’s a request to the server or something churns, and then you get output. I would love to bring in more of the dynamic instant feedback, that react view angular, some of those libraries make possible. I would love to get some of that in the actual admin interface, both just so the code interface looks nice, but also because if we could develop a set of components, say react components or something like that.

Angie: All of the Drupal modules that plug into Drupal could also make use of those. And it wouldn’t be like reinventing the wheel every time. I think that’s going to be a major focus for Drupal 9 is modernizing the JavaScript and the whole overall developer experience of Drupal for JavaScript developers. And then in addition to that, we’re also trying to minimize the amount of work that people who are developers and already know Drupal have to do through the automatic updates initiative is another big one that I’m excited about where right now, if you want to update your modules, that’s pretty straightforward, but updating core requires some manual work.

Angie: And we would like to get rid of that so that everybody can stay on the most secure version and that kind of thing. If it hasn’t come across, Drupal’s very concerned about security. We run some major governments in the world. We are running the Grammy’s or whatever. A lot of people depend on Drupal for being rock solid. And so, we spend a lot of time being very concerned about the security of the software, making sure the security team is responsive, not only to core issues, but anything that happens in our contributed module space. We take a lot of care about accessibility. We make sure that any change that goes into core goes through a series of gates and make sure that it’s WK compatible and uses the correct Aria attributes and all that kind of stuff.

Angie: We really have spent a lot of time making sure that things are good. And now I think the next phase of things where he’s going to be opening up all of that effort that we’ve put in to make it more accessible to more people.

Drew: It sounds like Drupal takes longterm support very seriously.

Angie: That’s correct.

Drew: How do you balance having a modern code base, you mentioned updating the style of JavaScript using having something that’s attractive to developers yet still having something that’s stable and isn’t following fads, isn’t bringing in dependencies that are going to quickly go away, that you can rely on and it’s going to be a bit boring and keep running and be supportable?

Angie: That is a fair question. I think a couple of different ways. As I mentioned, Drupal is very modular. One thing that has led to success in the past, so JSON:API is a good example. There was a lot of contention about what format are we going to standardize on for Drupal itself to output. And we settled on JSON:API for a number of reasons. It’s an open protocol. It’s not backed by one particular company, blah, blah, blah. There’s a bunch of stuff. When we did that, we actually prototyped that in contrib first. We created a contributed module, which can iterate very fast and easily.

Angie: And we can even just say, “Oh, that didn’t work out, delete it.” We were able to innovate really fast out in sort of this contributed module space. We started there and saw that, “Hey, this thing has some legs. Like people are actually making use of it. They’re providing really great developer feedback. We’ve got Drupal people on the JSON:API spec writing team, like this is actually really good. Let’s bring that thing that we already know works into core.” And then we did so, but it’s still just a module. Let’s say that, next year XMLRPC comes back from the dead and that becomes the thing that everybody uses.

Angie: It’s still possible that we would just leave the JSON:API module in there. We would get a new XMLRPC module. We would enable that by default, but still leave the old thing in there. And then when Drupal 10 came out, we’d take the old JSON:API module, move it back to contrib and people could still use it. But what shifts in the core software itself would just be following the latest trends. This way we get the best of all worlds because we’re able to innovate quickly. We’re able to make the best decisions possible for what the default Drupal user experience will be and developer experience. But then we’re also able to backtrack on decisions if necessary to do different things instead.

Angie: I think what would be get really tricky would be like, if we wanted to throw out the entire theme system and replace it with angular, for example, that would be hard. It’s really hard to make… All of the modules have to write four different ways that they could do their templates and that kind of stuff. That one, we would need to think through more, but that general approach of figuring out a way to plug into the system, leaving the old way in there as a crutch for the people who still need it. And then when we retire things, we retire them gracefully, so they’re still available to people, but just not part of the core product, I think that’s generally how this goes.

Drew: And I guess it’s that continuing process that’s brought you to this point where you’ve got Drupal 8 with all the backwards compatibility, I’ll call it baggage, baggage that you’re now shedding and moving forward with Drupal 9.

Angie: That’s right. Yep. And we’ll do it again in Drupal 10.

Drew: It sounds like a very important release for Drupal. Is there anything else we should know about it? And when is it landing?

Angie: It lands on June 3rd. You heard it here first, or maybe you didn’t hear it here first. We’re going to be doing some kind of like… It’s a little sad that it’s happening during COVID times because when Drupal 7 and eight came out, for example, were user groups all over the world doing like Drupal parties with cakes and all this kind of stuff. And so, we’re going to try and do a virtual version of that, but it won’t quite be the same. But what’s really cute is people bake little Drupal cupcakes and stuff like that, or showing the Drupal can on the side of a building or these kinds of things. And so, it’s a really creative and innovative community, so I’m sure they’ll figure it out some of the cool stuff.

Angie: But no, in terms of things to cover, I think we covered a lot of it, I think, if you’ve looked at Drupal before and held your nose at it, I would say, please give it another look. We’ve done a lot of work and over the past years to really, really hone in on that user feedback, really hone in on the usability piece, make it much easier for marketers. And also much easier to maintain for developers too. We have done that and we’ve managed to do those feature changes without horribly breaking things for the Drupal 8 people because we kept the backwards compatibility stuff in place. But it means if you haven’t looked at Drupal, even in five years has changed significantly as well because we’ve kept adding features, including API headless stuff, workflow, layout builder, all this kind of stuff.

Angie: And I’d say it’s a great way to build, it’s future-proof, there’s structured data under the hood, so you can… Whatever the new front end trend that ends up being you’re well positioned to jump on that. It’s got a great community full of awesome people. I hang out at open-source communities a lot and some of them are like, “Oh, you don’t know about blah, blah, blah?” Well, whatever, kind of thing. And Drupal is more like, “Oh, you don’t know about blah, blah, blah? Well, let me tell you about it because it’s awesome.” It’s just like a really welcoming cool community, I think, because we come from all different backgrounds and we’re just here to make the web rock.

Angie: So, yeah. Anyway, I hope something in there was helpful. And thank you very much for the opportunity to speak with you.

Drew: It would be remiss of me not to ask you about your involvement in open-source more generally, and especially the hurdles that are very real for getting more women to participate in open source. That’s something that you’re very passionate about, isn’t it?

Angie: Yeah. My background is, I was an open-source zealot back when I was even a teenager, I heard about opensource. I was like, “That is so cool. Everything should be open source.” But I always had this vision that you had to be a genius to work on open source because the people who were big names and open source back then was like Linus Torvalds and Eric S. Raymond and I don’t know. For some reason they carry this glow of like, “Oh, those guys are so smart.”

Angie: And so, I was self taught, I was going to community college at the time. And so, I just figured out this is not for me. But then Google announced a program called Google Summer of Code, which was where you get paid over the summer to work on an opensource project. And I was like, “Well, that’s really interesting because if they know we’re students, they know we don’t know everything yet. Maybe I’ll and just see what happens.” And I picked Drupal because I’m one of those people that just use source on every website I visit, just because I’m curious about what’s happening. And back in the day, there was a website called Spread Firefox that was built on Drupal. And it was really interesting. It was basically the community site where anyone could upload like a Firefox installed Fest or event having their campus, or they could upload a poster that they made or like whatever.

Angie: And I was just like, “That’s really neat. That’s cool. I’ll just file that away for later.” Because I long since given up using actual CMSs because I use PHP nuke and I was like, “No, I’m never doing anything like it. My cat could write better code than this anyway, I’m sorry. Sorry, PHB nuke.” But anyway, I had filed that away and I saw Drupal on listers and I was like, “All right, sure. I’ll give it a go.” And then it was amazing because from this side of things, once I got in the community and was actually contributing, I realized like, “Wow. A, first of all, the people that I thought knew all these things don’t actually know that much. You know what I mean?” They do. But like everyone has strengths and weaknesses. And what I saw happening was there’s people who are really good at certain aspects of the code.

Angie: People who are really good at documentation, people who are good at design. People who are good at explaining things to people, whatever, all of these people collaborating on these changes and all contributing the little bit that they know. And I was like, “Man, if I had known that like 10 years earlier, I would have gotten hit on this, I could have had a whole decade of software experience by now.” And so, I made it my mission to try and break down that barrier, particularly for women because women are socialized from a very young age to not get into tech, to begin with. And then once they get into tech, there’s a lot of like, “Oh my God, it’s a girl,” kind of thing. And it’s just like, if you’re in tech, you’re already dealing with a certain amount of crap.

Angie: And it’s like, why don’t we cut the crap and show people how awesome this is. I love talking to anybody who wants to get involved in open source, but particularly the women because I ran a group called Drupal Chicks for a few years there, which was women in Drupal to get together and talk. And the meetings were so funny because a girl would be like, “Well, I’m not a developer but,” and then she’d go on to like describe all this complex CSS stuff that she does or whatever. And I’m like, “You know that’s development, right?” I see women in particular though, everybody can struggle with this, but women in particular struggling with that feeling that even if I’m a perfectly capable person, that I’m just not as good as everyone else and so yeah.

Angie: I tried really hard to break down that barrier. I also tried to break down the… For my own self like people go, “Who Is Web Chick?” And I’m like, “No, I’m just like a moron.” I was like, “I did the stupid thing last week.” It was hilarious. And just to kind of break down that rockstar idolatry stuff, because we’re all just humans and we’re all just here trying to make it work and yeah. I am passionate about it because I just feel like if there’s someone out there who genuinely loves open source and the ethos of open source and the idea of it, that they shouldn’t be held back just because they think they’re not as good as other people because I can tell you right now, you’re good enough and you should just do it.

Drew: That’s so, so important. I’ve been learning about Drupal 9. What have you been learning about lately, Angie?

Angie: At the beginning of the whole pandemic thing, a friend of mine who teaches guitar, posted like, “Crap, my music school closed. Does anybody want to do Zoom lessons?” And I was like, “Yeah, I have a guitar. Just been hanging out here.” And just because I collect musical instruments just in case of the off chance my daughter wants to get into music. I’m like, “Great, I have all the things.” But I have no idea how to play it. I play drums. And so, I was like, “Sure, I’ll try that.” Actually, for the past two months I’ve been taking guitar lessons online from a friend of mine and I’m learning like take it easy by the eagles and stuff like that and a little bit of blues stuff and I’m so far very terrible, but I’m trying and it’s fun.

Angie: It’s just a completely different thing that it wouldn’t otherwise do. And yeah, it’s been really fun.

Drew: Incredible. If your dear listener would like to hear more from Angie. You can follow her on Twitter where she’s @Webchick, find her personal site at webchick.net. And of course, find out all about the current and upcoming versions of Drupal at drupal.org. Thanks for joining us today, Angie, do you have any parting words?

Angie: No, I’m really grateful to have the opportunity to speak with you. You’ve been around the block like, “Holy cow.” I was looking at your resume. It’s like, “Oh my gosh.” Speaking of people that are up on pedestals, but honestly, that’s amazing. I really appreciate the opportunity to talk with you, especially about the little open-source project that could. And hope that people take the chance to try it out.

Further Reading

Smashing Editorial (il, mrn)
Explore more on