Upgrade Your Drupal Skills

We trained 1,000+ Drupal Developers over the last decade.

See Advanced Courses NAH, I know Enough
Nov 09 2020
Nov 09

[embedded content]

Sarah Durham (00:02):

Hey everybody. Welcome to today’s webinar. I am Sarah Durham, and I am going to briefly introduce my colleagues. They will talk a little bit more in a minute and also we’d love you to introduce yourself as people start to arrive. If you are comfortable doing so, you’ll see a chat panel. And if you could chat in to us your name, the name of your organization, your pronouns, and where you are, where you are geographically, so who you are and where you are, would be great. Theresa, you want to say hi. 

Theresa Gutierrez Jacobs (00:50):

Hi, I’m Theresa Gutierrez Jacobs. I am a project manager at Advomatic. And for today, I’m going to just quickly chat my email. If you have any, I don’t know, tech issues or questions or anything like that, that is more tech related to this webinar. Feel free to reach out to me via my email. Otherwise, you can always chat or ask questions, particularly for this webinar here. And Dave, you want to say a quick hi, before we get rolling.

Dave Hansen-Lange (01:18):

Hello. I’m Dave Hansen-Lange and where I am, I’m about an hour from Toronto. I’m the director of technical strategy at Advomatic. I’ve been with Advomatic for about 13 years. And I’ve been doing work with nonprofits in the web for maybe about 15 or 17 years.

Sarah Durham (01:42):

Okay. So we’ve got a bunch of people who are already with us, a few more people who might join us in the next couple of minutes, but just to keep the ball rolling and use your time thoughtfully, we’re going to dig into our content for today. And as I said a little bit earlier, I will reintroduce myself. I’m Sarah Durham, I’m the CEO of Advomatic and also Advomatic sister agency, Big Duck. Some of you may have noticed that the Zoom we’re using today is a Big Duck/Advomatic shared Zoom. So if you’re wondering what the connection is, there’s some common leadership across both companies. For those of you who might know Big Duck, but don’t know Advomatic, Advomatic builds sturdy sites that support change. We build, and we support websites in Drupal and in WordPress. And Advomatic has been around now for, I think almost 15 years, although it’s partnership and collaboration with Big Duck and my coming into the company is relatively new.

Sarah Durham (02:43):

It’s about, I’ve been in it about two years. And so Dave is going to really take us through our topic today. And Dave, you could advance to your next slide, if you would like, which is this, what should you do with your Drupal 7 website? So Dave’s gonna talk us through why this is an issue and a few other things in a minute. What I am going to do throughout this conversation is I am going to be monitoring both the chat that you can see in the bottom of your screen, a little button that says chat. And if you click on that, you have the ability to either chat privately to the panelists. So if you want to ask a question confidentially, or you don’t want everybody who’s here to see it, just chat to the panelists and only Dave and Theresa and I will see it.

Sarah Durham (03:26):

If you want to chat to everybody and share who you are, like shout out to Rick, who’s already done that. He’s from the National Council of Nonprofits and he’s in the DC area. If you want to share your information with the panelists or to everybody, you can chat to all attendees. Also, you have the ability to specifically ask questions. There’s a Q&A feature in Zoom Webinar. And that will give me the ability to keep an eye on your questions. And some of them I can type back to you and others will be addressed verbally. So throughout the presentation, I’ll be monitoring all of that and we will address your questions perhaps as we go on, certainly at the end if it doesn’t make sense to do so in the webinar. So don’t hesitate to chat, don’t hesitate to ask questions. We are recording today’s session and Theresa will be sending out an email with a link to that recording and the transcript and the resources we’re mentioning later this week or early next week. So you will have all of this and you can share it with any colleagues if that is useful. So with that, we are going to get rolling over to you, Dave, and thanks, Theresa.

Dave Hansen-Lange (04:44):

Okay. Thank you, Sarah. All right. So to kick things off before we get into the details of all the different things that you can do with your website and what might be best for you I thought we should start with some backstory about like, why we’re at this spot and like, what does end of life even mean? Like, it’s software, how can software… and it really all comes down to security. And just to explain a little bit about how security in Drupal works, there is the Drupal security team, and that’s a team of about a dozen people all across the world. And then there’s a group of people even wider than that who contribute things to the team and say, Oh, this could be a problem. We should look into this. And people on the security team, you know, a lot of their time is paid for by their employers or their clients, but a lot of their time they’re just volunteering for free.

Dave Hansen-Lange (05:50):

And you know, there’s a lot of commitment there. Like, they have weeks on call and stuff like that, because security is very important to the Drupal community. And so we don’t want to have those people working forever for free. So the Drupal community at large has decided, okay, thank you for your time of service, people on the Drupal security team, we will let you go after this date. Some of those people work on AAA too. But people are generally committed for like Drupal 7. And so the original date for the end of Drupal 7 was going to be November, 2021. But then COVID happened and the Drupal community decided, okay, there’s this extenuating circumstance. We’ll give everybody one more year to figure out what they’re going to do. So now that the end of life date for Drupal 7 is November 2022, two years from now. 

Dave Hansen-Lange (06:56):

Drupal 8, just as an aside, it’s not really what we’re talking about today. Drupal 8, the end of life is November 2021, a year from now. That’s not what we’re talking about today. And thankfully, if you do have any AAA sites, the situation is a lot simpler. And if you want to get into that a little bit more possibly we could at the end of the presentation. Okay. So today we are going to first cover: these are the options that you have in dealing with your Drupal 7 websites. Then we’re going to look at some example scenarios. And by that, I mean like, okay, here’s an organization, they have a website like this, and because of that, they might consider scenario x. And then I’m going to pass things over to Sarah. And Sarah is going to dive into more of the organizational things, like, how do you plan for this and how do you work with this within your organization? All right. 

Sarah Durham (08:15):

Hang on one second, Dave, before we dig into this, I also just want to remind everybody feel free to chat in questions and comments as you go, and we’re going to take pauses in between each of these sections. So if you have, as Dave goes through the options, if you have a specific question about one of the options, and it seems like it’s universal to some of the other people who are participating today, I’ll probably pop in and ask that otherwise we’ll save Q&A for the end. Alright, sorry for the interruption.

Dave Hansen-Lange (08:41):

No, no, all good. I’m also going to be muting every now and then to take a sip of tea. I’ve got a sore throat. It’s not, COVID, it’s just a cold. And yeah, so I’ll be pausing too, as I go. Okay. So what are your options? So I’ve grouped these into four main options, and these are listed in terms of most expensive, to least expensive, most expensive option being start from scratch and build a new website for most people with a Drupal 7 website your main options are move to Drupal 9 or create something in WordPress. There’s some other options that you might consider, but those are the two that are applicable to most people. Option B is upgrade to Drupal 9 and immediately you’re probably thinking what is upgrading to Drupal 9? How is that different from building a website and Drupal 8? And I’ll explain that when we get there, another option is to switch to something called Backdrop. Many of you have probably never heard of Backdrop. And so I’ll start us out by what exactly that means. Or you could just stay on Drupal 7. And even though it has end of life, that there still are ways to keep going on, on your Drupal 7 website.

Dave Hansen-Lange (10:15):

So moving to a new website like I mentioned the main options for most people are Drupal 9 or WordPress. And so just by saying those two names in the same sentence, we immediately get into the topic of like what’s better Drupal or WordPress and what is right for me? I will touch on this a little bit now, and sort of back up a little bit and say that for starters, it’s really hard to make an unbiased and fair assessment of the two. But in a general sense, Drupal 9 is really great for people that, or on websites and organizations that want to do something a little bit more complicated, a little bit more ambitious, a little bit more technological, with more moving parts. And WordPress is generally more applicable to the organizations whose website, in many ways might be similar to other websites. And yeah, that is a little bit vague. I don’t want to dive too deeply into this topic right now. 

Dave Hansen-Lange (11:54):

If you want, we can come back to this in the Q&A at the end. And we also have another webinar that we did a couple months ago on this topic more generally. And if you’re just, if you can, we can send along a link to that as well. One last thing on this, though, I will say that when most people compare Drupal and WordPress, they’re not really comparing Drupal and WordPress, they’re comparing the website that someone built for them in Drupal or the website that someone built for them in WordPress. And because of that, they’re often comparing the skills of those people who built the website and not necessarily the underlying technology. And that’s part of the reason why this is such a sticky, thorny issue with a lot of people being on one side or the other there about moving to a new website. You don’t have to do the whole entire thing. You can find ways to do this in bits and pieces. I’ll show some examples of that later, but we’re at this point of rethinking what should we generally do with our Drupal website. It’s a great time to think, okay, this section, do we need it anymore? Should it be here? Is there a better way to do this then when we created this website however many years ago?

Dave Hansen-Lange (13:30):

Since many of you may not have seen modern Drupal I’m going to show you, or we’re pressed, I’m going to show you some slides here. So on the left, what we see is I am editing a page on a website and I want to add a new component which is a common term that we use these days, a new component to the page. I can browse through this library of available components and then add one.

Dave Hansen-Lange (14:00):

Or how it’s going to appear on the page. There’s many ways to do this in Drupal. Drupal is kind of known for having many ways to solve a problem. What we see in this screenshot is a tool called paragraphs. That’s a tool that we’ve been using for this problem pretty successfully on several websites. There’s other tools within Drupal 9. You may have heard the term layout builder and there was a couple of smaller ones as well on the right side. We see the administrative listing of all the content on your website for each site, it’s going to be a little bit different, what you decide to list here. But this is just one example of how it looks and comparing this to WordPress on the left. This is also how WordPress looks when you want to add a new component to the page. And so the right column there, we see, the available components that you have, again, on the right, a screenshot that’s WordPress of a list of all the content on the website.

Dave Hansen-Lange (15:20):

Looking at these two sets of screenshots, there’s a couple things that might sort of immediately come to mind. WordPress, the administrative interface generally looks a little bit more polished.

Dave Hansen-Lange (15:39):

In some ways WordPress can be a little bit all over the place in that each plugin or each new thing that you add to your website tends to design things its own way and do its thing its own way and it’s WordPress. Compared to Drupal, each new thing works in a very consistent manner. So it’s easy to move around from section to section on the website. All that to say is really either is probably a big step forward from where you are with your Drupal 7 website.

Dave Hansen-Lange (16:18):

All right, so which Drupal 7 website is this going to be most applicable to, or maybe you shouldn’t at all consider this option? If you are really frustrated with any part of your website, be that like how the content of this is organized, or just the general backend experience the design of the website, if there’s anything about it that you’d just want to just toss and start again fresh, this is a good option to consider. But like I mentioned, when I listed these four main options, creating a new website is going to be the most expensive of the options. And in the age of COVID, many of you are probably dealing with some tight budgets. So one of the other options may be the better choice. Also, this might not be a good choice for you if your existing site is very complex. And one way to think about this is like you built your website so many years ago, let’s say it was five years ago. And you put all this work into doing that initial build, but then over those five years, you’ve also put in some work, to make the website more and more better. And in this new version of the website that you’re gonna create, you want to encompass all of that. 

Dave Hansen-Lange (17:52):

It’s going to be a pretty big project. And so it’s just one way to consider looking at your options.

Okay. Option B, I don’t have a handsome, single flat you can upgrade to Drupal net. So how is this different from just creating a new websiteIn AAA? Drupal 9 has these built-in tools that can take your Drupal 7 website and take all those, all that content, all the content structure all the menus, everything that’s stored in the backend of the website and upgrade it and make it work in a new Drupal 9 website. But what you don’t get is any of the, how that content is presented to visitors, all of that stuff. If you go through this upgrade process, you still need to come up with or you still need to rebuild the way that it’s presented to visitors. Maybe, maybe you’re happy with the design of your Drupal 7 website. And so you can just redo that same design in Drupal 9 or another option since we’re here and we’re creating a new website and Drupal 9, you might want to take advantage of that and do a new design.

Dave Hansen-Lange (19:31):

And so, because of all those things, it’s going to be still a big chunk of work, not as big as just doing a clean slate and starting from scratch. But still a lot of work involved. One thing you do need to look into before you get too far down this road is like, are there any ways in which we solve the problem in Drupal 7, that just there’s no equivalent in Drupal 9. And that has sometimes happened because the Drupal 7 way of solving a problem, one example would be locations. Let’s say you got a content type in Drupal 7 called offices of your organization and they’re storing their address and location. That’s almost certainly done in a very different way in Drupal 9. And there isn’t a way to directly go from one to the other, at least not directly in the same sense of this upgrade process that I talked about before. There may be these situations like that, and you’ll have to do something custom or something else. That’s a little bit more complicated. It’s just important that, you know, these things happen upfront before you get into moving down this road.

Dave Hansen-Lange (21:00):

So who is this good for? I mentioned, you’re going to get the same stuff in the backend as you have now. So it’s, if you’re happy with that, great, consider this option. I mentioned that the visual presentation, you’ve got to redo that. So if you want a fresh design, this might be an option for you. Again, avoid if budget is tight, like I mentioned, it’s still a fairly complicated procedure. All right. A third option is to switch to Backdrop.

Dave Hansen-Lange (21:39):

So Backdrop, I said earlier that your main options are WordPress or Drupal. What’s this, what’s this new Backdrop thing? Backdrop is kind of like a different flavor of Drupal. And in the technical parlance, Backdrop is a fork of Drupal 7. And what does cutlery have to do with software? Absolutely nothing. So by fork, we mean fork in the road. You may know that Drupal and WordPress are open-source software. And that means that anybody, anybody really who has the time available to do it, can jump into the project. You got a problem with the way something works, you want to make it better, you can just do that and you can contribute something and get it rolled into the software. But what that also means is that if you don’t like how something works, you can just take it, copy it, and roll with it.

Dave Hansen-Lange (22:42):

And that’s what’s happened with, with Backdrop so well. Drupal 8 was being developed. There were many people in the community who thought, “Oh, no, like Drupal 8 is looking great and all, but it’s going to be really hard for websites that are on Drupal 7 to get to Drupal 8 and whatever it comes in the future. And they were right. That’s, that’s why we’re here. That’s why we’re having this webinar. And so what they did was they took Drupal 7, copied it, called it Backdrop and started to evolve it and evolve it in some of the same ways that AAA has evolved only keeping with the Drupal 7 way of doing things and the Drupal 7 styles. And so you have an option to take your website and sort of just take that fork in the road and start moving down the Backdrop trail.

Dave Hansen-Lange (23:42):

What this is going to look like for your website is that you’re still gonna have the existing content structure things in the backend of the website, just like that, upgrading to Drupal 9 option. It’s all going to look very similar, if not identical, but different from that upgrade to Drupal 9 option. You can still keep the visitor-facing portion of the website. If it’s going to need a little bit of tweaking to get onto that Backdrop fork in the road. But that is going to be relatively much smaller, a much lighter lift. Not to say that you must keep your existing design, you can make some changes and revisions. You might even consider doing a full redesign. But yeah, you don’t have to, as you’ve heard me describe this, you may be thinking fundamentally that the steps involved, it’s pretty similar to the upgrade to Drupal 9.

Dave Hansen-Lange (25:00):

It is, but still, it is almost certainly cheaper than upgrading to Drupal 9. And mainly the reason is because like I mentioned, it is just Drupal 7 evolved. So the changes that you have to make to your existing website are just immensely smaller, some increased risk. So what I mean by this well, like anybody who works with websites for a nonprofit is probably going to know WordPress, and probably getting to know the word Drupal, probably not going to know the word Backdrop, because it is such a much smaller community. Where there might be that there’s about half a million Drupal websites out there. There may be like a few thousand Backdrop websites out there. And because of that, there’s enough momentum in the community that we know that Backdrop will be here for two years, maybe four years, but it’s harder to sort of see deeper into the future. Whereas Drupal, you know, half a million websites. We know it’s, there’s a lot of people working on this, a lot of organizations, big and small, it’s going to be here for probably at least another 10 years, if not longer. Backdrop, much smaller community. There’s just not as much certainty about the future. 

Dave Hansen-Lange (26:44):

But with that said, Backdrop has committed to like the same sort of upgrade structure that Drupal 8 and Drupal 9 have committed to being. We’re not going to do a huge change again in the future. We’re going to make all these incremental changes that will make it much easier for you to stay up to date and evolve your website over time.

Dave Hansen-Lange (27:12):

Great. I thought it important to show some visuals about what Backdrop looks like and looking at these, you might be thinking, “Oh, this looks pretty similar to my Drupal 7 website, but the colors and fonts are more contemporary”. And you are a hundred percent correct in thinking that like I mentioned, it really is Drupal 7 evolved. But there is more to it. There are some easier things on the technical side of how to work with Backdrop compared to Drupal 7. There’s some different ways of managing page layouts. There’s other new features in Backdrop that Drupal 7 doesn’t have. But the thing is, if you take this sort of upgrade from Drupal 7 to backdrop trajectory, you’re not going to get those things all of a sudden. If you want to take advantage of Backdrop’s fancier ways of laying out content on a page then you’re going to have to have a small project to enable that feature. At first, you’re still going to be working in the same paradigms as you are with Drupal 7. So who is Backdrop great for? Anyone who has a lot of custom code. I was talking earlier about like, why you might want to avoid building a new website and Drupal 9 is if you’ve got a lot of custom stuff. Here in this option, and this would be a good option for you because all that custom stuff probably doesn’t need to change very much, probably needs to change a little. But if it’s not going to be all that significant, this is a good option for you.

Dave Hansen-Lange (29:16):

If you are happy with your existing design that’s going to need a little bit of touch-ups to move to Backdrop. I was trying to be consistent here and come up with a reason why you should avoid Backdrop. I couldn’t really come up with one. I think everyone should at least consider this option. It’s kind of like the middle of the road option. You might not choose this option if you’re wanting to do a full redesign, but if all the rest of the things line up for you, then you could do a full redesign in Backdrop. It would be fine. I guess the only reason that I can think of now is that if you are super concerned about keeping the website that you have the same fundamentally as it is now, four, five years into the future, 7 years into the future—because the future is a little less defined for Backdrop—you may want to avoid it in that case.

Dave Hansen-Lange (30:35):

All right. And the last option stay on Drupal 7. I mentioned even though Drupal 7 has reached end of life, there are ways to continue on with it. If you had any websites that were on Drupal 6 and you were in this sort of situation for Drupal 6’s website, when it reached its end of life, there was a program started called the extended support for Drupal 6. This Drupal 7 version of that program is fundamentally identical. And what this is is that I mentioned that many of the security team are volunteering their time. And so this program gets around by trying to force people to volunteer their time by saying it’s a paid program. The Drupal community has vetted several Drupal agencies to offer this extended support service. And what that means is that as security issues come up, maybe there’s a security issue that comes up in Drupal 8 that might also apply to Drupal 7 this, this team of extended support people work on fixing that problem in Drupal 7.

Dave Hansen-Lange (32:11):

And so there’s kind of two ways to take advantage of this: Number one, you sign up with one of the extended support vendors. You’ll be able to find that list through some links that we’re going to send at the end. One of the mandates of this is that they release all of their fixes publicly. It’s happened for Drupal 6 as well. And so if you are technically savvy or you’ve got someone at your disposal who’s technically savvy and can sort out the details and apply these fixes as they come up, this could be a good option for you, too.

Dave Hansen-Lange (33:08):

I think it’s important though, to like, take a step back at this point and talk about why you might think about security in different ways. And one way to think about security is kind of like two groups of websites on the internet—those who security is really important for, for whatever reason. Maybe they’re doing something that some people find controversial and they have people who are trying to hack into their website. Maybe you are processing credit cards on your website and you, you know, someone might want to try and break in and steal those credit cards. Maybe you are a news outlet and you get hundreds or hundreds of thousands of people viewing your content every day. And if someone could break in and get some sort of message out to those people, that might be an incentive as well. So that’s like one group of websites, people who have some sort of special security concern. And then there’s kind of everybody else—everybody who knows that security is fundamentally important, but it’s not more important than it is for everyone else in this group.

Dave Hansen-Lange (34:33):

It’s just the nature of how I described that most organizations are going to be in this group where security is important, but not more important than anyone else. Some are going to be in this heightened group of security. And for those people, they need to think about things more than just like, am I getting the bare necessity basics? Or am I really doing all that I’m responsible for ensuring the security is as good as it can be. And for those people, this may not be the best option in that you’re not on the most recent and currently secure thing you were on, this thing that’s on extended support. And whether that rationale is purely technical, or if it’s purely optics in that if something were to ever happen to your website and it was discovered, “Oh, they’re running this version of Drupal that was created 10 years ago”. 

Dave Hansen-Lange (35:38):

How can that be responsible? And then there’s all sorts of politics involved. I mean, it’s a situation you want to completely avoid, but for those of us who are in the group of security as important, but not more important than anyone else, this can be a very reasonable option to consider. So stay on Drupal 7, if you have a really tight budget. And I admit that budget is in the eye of the beholder. For some of you a roomy budget would be a tight budget and vice versa. Like I was talking about, if you don’t have any special security requirements avoid, if your site needs a facelift or if you’re frustrated with the backend. So like I mentioned, this is keeping the same website and keeping it the same. And so if you want to rip something out and try again, this is probably not the option for you.

Sarah Durham (36:56):

Okay. So, Dave, I’m just going to jump in here for a second before we continue with your sample scenarios. We’ve got about 20 minutes left in our time together, so we’re going to need to move pretty quickly through our sample scenarios and through the make a plan section. But we did get a really good question that I’d love you to try to answer for us before we continue on. It’s from our friend, Rita, and Rita asks, if you choose to migrate or upgrade to Backdrop, what would that mean for your future options to upgrade to Drupal 9?

Dave Hansen-Lange (37:29):

I don’t think it really changes the landscape for that at all. Whether you’re upgrading from Drupal 7 or from Backdrop, it’s fundamentally the same thing. It is technically almost identical and that’s because well, Backdrop has gone on this new trail at a foundational level. The way the content is stored, it’s fundamentally the same. And so if you want to pull that content out of either version of those websites into a new Drupal 9 website, it’s going to be the same process. That could change though, as it’s a fork in the road. So Backdrop could go further one way, while well, Drupal 7 is not moving anywhere at this point, but it could continue to move on in a way that’s more different from Drupal 7. But in my opinion, it’s unlikely to change all that much for the foreseeable year or two.

Sarah Durham (38:37):

Okay, great. So, so back over to you.

Dave Hansen-Lange (38:40):

Okay. So like I mentioned, those options, they were great in theory, but now let’s try and put some of this to practice. I’m going to show, I think, four, maybe five example websites and what is unique or different about those websites and why they might choose one option over the other. As you’re looking through this, you might think, “Oh, that’s nothing like my website”. But I’m going to try and pull some things out here that hopefully are going to apply or at least show some things that you should consider. And you also might recognize some of these websites. Don’t focus on that. We’re going to focus on what is it about these websites? I’m also not going to tell you anything about these websites that isn’t something… Sorry, everything that I’m going to tell you about these websites is something that you could just go to the website, look at and figure out for yourself.

Dave Hansen-Lange (39:45):

So there’s not going to be any sort of like private information here that I’m gonna show either. So in this first example, we’re going to look at the ACLU. On the left here, we see what their website homepage used to look like. On the right side, we’re going to see what the homepage looks like now. And the prior version of the website, that was Drupal 7. The homepage, and I say that specifically, the homepage, is now WordPress. You may remember back when I talked about the option of creating a new website that you don’t have to do the whole thing. Here’s just the homepage. And they’ve actually done the same thing with the blog section. It used to be Drupal on the left. Now it’s WordPress on the right. You don’t have to do with everything.

Dave Hansen-Lange (40:44):

So this is an example of a case on the ACLU website. And like, this is just one really long page here that is cut up into three pieces. See at the top, this is all just fairly straightforward content. But then in this section, things start to get more complicated. Like there’s all these other bits of content elsewhere on the website that are related to this case. That’s something that you can do in WordPress, but the more complicated those relationships get, the more awkward it gets to do in WordPress. Then down here at the bottom of the page, things get super complicated. Visually it doesn’t look too bad, but that’s because I think the design was done well. There’s hundreds of legal documents that relate to this case, all in these groupings and hierarchy and get super complicated. WordPress is not the best tool for this kind of job. And so this part of the website is still on Drupal. It’s still going to be on Drupal for now. It might evolve in the future, but that’s where it is for now.

Dave Hansen-Lange (42:03):

Another section of the website, there is this sort of intermediary thing where you could show an action within like an article or a blog post or something to say, “Okay, come take this action”. And during the redesign or in moving bits to WordPress, you know, if you’ve stepped back and thought, is this useful? Is this complicated? Is there a way to do this simpler? And this sort of intermediary thing was just checked and now there’s just links to actions and there’s other ways to show actions without this complicated section of the website. Please consider for your website: What should I get rid of? There’s almost always something. 

Dave Hansen-Lange (43:11):

Looking at a different organization, here is one that’s a Drupal 7 website. But you might be thinking, “Oh, this design, it looks fairly current”. And you’d be correct because this organization went through a redesign, I want to say, like, two years ago. And so because of that, looking at those four main options, they can probably throw the create-a-new-website option out because the design still looks great. As long as they’re happy with how the content works on the backend, they could really choose any of the other three options. And, yeah, so consider that.

Dave Hansen-Lange (43:47):

Next, we have a municipality. When I was talking about the option of staying on Drupal 7, that’s maybe not the best option for a municipality in the news all the time. We hear stories of like such-and-such municipality, their website has been hacked, or their computer systems have been taken over by ransomware. And so just the optics of staying on Drupal 7 might not be the best choice for them. The design looks, doesn’t look as fresh as those first two options that we showed. But let me guess a municipality kind of has different requirements in that the number one goal is not a flashy design, it’s getting information out to its residents.

Dave Hansen-Lange (44:32):

And so there may be a way for them to choose one of the non-design related options. And at the same time, maybe consider how it can do any sort of restructuring to better present the information that people need to find. Here’s another organization. In looking at the screenshot, you might be thinking the same things that this organization thinks about this website and that the design is very text-heavy, and it is not quite as engaging as they would really like it to be. And so for this organization, one of the first two options is probably the best choice: creating a new website completely or upgrading this to Drupal 9 with a new design.

Dave Hansen-Lange (45:43):

Lastly, we’re going to look here at, this is not so much a website, but a web platform. AFT has 1,300 websites on this one platform for States and Locals within a state. And the center one up top here, this is for a campaign website. And this is an example of a few things: One, it’s not their primary website, it’s not aft.org. And so if you’ve got more than one website, you don’t have to choose the same option for all of them. You can choose different options. Number two, there’s a lot of custom stuff involved here, as you might imagine. Some stuff around creating a new website, around connecting the information altogether. So because of that, you might lean more to one of the options that works better for custom stuff and doesn’t require recreating all of their custom stuff in a brand new website.

Sarah Durham (47:07):

Thank you, Dave. So a quick question, before we talk about where you go from here. Just want to confirm the ACLU, the sections of the ACLU site that are still in Drupal, or are those WordPress? 

Dave Hansen-Lange (47:22):

That is in Drupal. Yes. 

Sarah Durham (47:26):

Okay, so Dave is going to be advancing some slides for me. So I will ask you, Dave, to go onto the next slide. And basically, before we flip over to your questions and discussion, and in the remaining time we have together, what I want to get you thinking about is how to make a plan. And it’s interesting we’re doing this today because actually I had a call with somebody at a higher ed institution this morning, who’s got an old site and they are debating what their options are. They were describing a lot of feelings of being overwhelmed. I think that, you know, these days with the reality of what’s going on in the world with COVID, with elections, all that kind of stuff, tackling these kinds of big projects is feeling pretty daunting. So I wrote an article about planning and we’ll share links to that article and a bunch of other things.

Sarah Durham (48:20):

Dave has also written a really helpful post about Drupal 7’s end-of-life. At the end of this webinar and also in the follow-up email, we’ll send you one of the things I wrote. The first step is to make a plan and you don’t have to have all the answers. You’ve just got to begin by getting your team on the same page about the implications. I think that’s one of the big barriers that a lot of people are facing is that they’ve got these Drupal sites and there is a real challenge coming up, a real cliff coming up for many of you that you’ve got to begin to get your team aligned around so that you can budget and plan appropriately. Next slide please, Dave. So I recommend that you come up with a plan, which you could do in five slides or in two pages.

Sarah Durham (49:05):

And the intention of this plan is actually to give you an internal document you can use to get your team on the same page and build some buy-in. So you can see first you’d start by outlining the situation. I think we’ve given you some of the ammunition for that conversation and in today’s session or in the articles we’ll share with you, and what the risk is to your organization. You might want to outline some options if it’s clear to you and the people on your team where you should go from Drupal 7. You might go forward with outlining some options or making a recommendation, but honestly, if you’re not sure which way to go, a good partner should help you get there, too. So if you don’t have the answers already in mind, if it’s not clear to you which way to go, it might be that you map out a few options.

Sarah Durham (49:52):

But your recommendation might be more to find a partner to help you navigate that. Of course Advomatic can do that. We would love to help you make a decision about this, and we do regularly do that as part of our work. There are many people you could work with who could do that. I think one of the things that’s also really important in your plan is mapping out a timeline, not so much for the build or the upgrade that you might do, but all the things leading up to it. If you are looking ahead and thinking what you really need to do is rebuild your website or do a significant upgrade, that’s going to take time and a lot of work, and you’re going to want to get your team on the same page about when the budget needs to be approved, and when you’re going to get rolling so that you’re doing it hopefully well in advance of some of the deadlines that are going to be important within your organization and within the Drupal 7 end-of-life timeline.

Sarah Durham (50:49):

You know, in the non-profit sector, one of the key pieces that is in my experience kind of do-or-die for many big projects is building buy-in. So with that plan in mind, I would encourage you to have some conversations, share it, get it into the budgeting process and kind of keep it alive because very often you know, you mentioned these things once or twice, but there’s so many things going on that are taking up so much attention and energy for the leaders of organizations today that I think you’re going to have a little bit of work to do to keep it alive, which is the next step. My next slide. Also, keeping it alive is about not just writing this plan and sending it to people, but keep nudging and keep bringing it up. If you know what your milestones are when people are talking about budgets or budgets are getting approved, you know, those are great opportunities to research, collate your plan and go from there.

Sarah Durham (51:47):

Now, many organizations that we work with and talk to are already doing this, and they’re already talking to us and other people about what they’re doing. And a partner can also help you figure out your timeline. So there are a lot of ways to do this. You don’t have to do the heavy lifting on your own. But what you don’t want to do is you don’t want to wait until you’re, you know, a couple of months away from these deadlines if they pose significant risks or implications for your organization. So we have a few minutes left to go before the top of our hour. And I want to hear a little bit from you. So if you’ve got questions or comments, you can either use the Q&A feature, which you will see at the bottom of your screen, or you can chat them in to Dave and I, as we go. And we’re going to stop sharing our screen. Now we’ll take a few questions and while you chat those in, I also want to just remind everybody that we are going to be sending out a follow-up link to the recording here. And Theresa is also going to chat out a couple of the articles we mentioned. Dave has written a really helpful article about D7 end-of-life. He’s also written an article about D8 and there’s an article I’ve written that’s about how you, how you plan for this change. So Theresa will chat those all out.

Sarah Durham (53:17):

Okay, Dave, first question for you. Somebody is chatting in about administrators and they’re thinking, well, actually, this is sort of a double-barreled question. Let’s take it in two parts. First in option A, you talked about building a new site as option A. You specifically talked about WordPress and Drupal. Both of those are open source technologies. Why are you talking just about WordPress and Drupal and not any other systems?

Dave Hansen-Lange (53:46):

One of the things that I also talked about was like, kind of the momentum of these projects, like Drupal is large. WordPress is ginormous. And there’s lots of movement in those projects. There’s lots of momentum as soon as someone has a new idea or a new technology pops up on the internet, like things move quickly. And there’s a way to do it on your website in short order. And I also talked about the security group, that’s not the official title, but like there’s ways like that in which you’re getting the benefits of someone else volunteering their time for your website, which you just don’t get in in some of the other options that you have.

Sarah Durham (54:37):

Okay, thank you. And the second part of this question was about comparing WordPress and Drupal about administrators and the options there. This person is talking about how there’s lots of different people in their organization, who right now have different layers of access in Drupal 7. And they’re wondering if there are any recommendations you have for new platforms based on that kind of complexity.

Dave Hansen-Lange (55:01):

Yeah, so like the area of editorial permissions and controls, like that’s one of the big differentiators between Drupal and WordPress. WordPress has some basic systems around this role can do this, or this role can do that. In Drupal, we can make things a whole lot more complicated, like people who manage this section of the website, they can upload images. Other people can use those images, but only the original group of people can edit them or ways of more complicated things that you can do in Drupal.

Sarah Durham (55:38):

Okay, so there’s a question here about the difference between a Drupal new build and a Drupal upgrade in terms of cost. And actually, would you mind just bringing it up again, cause somebody chatted to me that they arrived a bit late and they didn’t see your slide. I think it’s your slide number six, which outlines all the options. Let’s just quickly go back to that slide for a second and share that. And I think that the question that just got chatted into me relates to this. So on slide six, you mapped out a bunch of different options ranging from building a new site to staying on Drupal 7. And those were ranked, as you talked about them from most expensive to least expensive. So you said building a new site is the most expensive, staying on Drupal 7 is the least expensive, and then the upgrade or the switching to Backdrop were in between. So the question is about the cost differential between building a new site in Drupal 9 and upgrading in Drupal 9. I assume that there are additional costs for design, for UX, things like that, and building a new website, but how significant is that differential? What other variables inform the cost difference there?

Dave Hansen-Lange (57:06):

Yeah, so I talked about sort of in any of these higher options… well, no, let me rephrase that. In the two middle options, you have the option of how much redesign you want to do, of course. And that’s probably the biggest thing that affects how big or small upgrading to Drupal 9, that project is going to be. But let’s say you wanted to redesign and compare upgrading to Drupal 9 versus creating a new website in Drupal 9. It’s difficult to be put on the spot, but I don’t know, 80%, 90% since you’re doing a full redesign. Upgrading to Drupal 9 and moving to a new website, they start to become more similar. The more you’re redesigning, the similar in cost.

Sarah Durham (58:01):

Okay, thank you. That sounds like what we were expecting. So I am just skimming through your questions and it looks like a couple of other questions that we have here are pretty unique to specific organizations, so I’m going to follow up directly with those organizations since we are just about out of time. I want to thank Theresa and Dave for joining us today. Dave, thank you for imparting your wisdom on this topic. And I want to thank everybody who took the time to log in and watch this. I hope this has been helpful for you. If you have specific questions or concerns or things you want to pick our brain about, you can always email us at [email protected] or [email protected]. We’d be happy to get on the phone with you, talk a little bit about your situation if that is of use to you. And again, Theresa will be sending out a link to these articles and the recording to you in just a few days. So thank you, all. And thank you all for the excellent work you do to make the world a better place. Be well, thanks.

Oct 22 2020
Oct 22

A common frustration for Drupal 8 (and 9) site builders is the inability to change text fields from plain text to filtered text through the administrative interface. This was something that was easy to do in Drupal 7 by editing the field’s settings and changing the value for Text processing.

Sometimes requirements for a field change, both during the build phase and long after a site has been in production, and it would be convenient to toggle on a rich text editor and text filtering with minimal effort.

In Drupal 8, there are five types of text fields in core:

  • Text (plain)
  • Text (plain, long)
  • Text (formatted)
  • Text (formatted, long)
  • Text (formatted, long, with summary)

The first two are actually string fields and don’t allow any formatting. If a user enters HTML tags, they are ignored and displayed as plain text.

The last three will allow HTML tags, depending on the settings for the Text Format that the user chooses when entering content. However, only the last two will show the WYSIWYG editor (if it’s associated with the selected text format).

But what happens if midway through your build process, or months after your site has launched, the requirements for that text field change? Your client or designer decides they now want to allow some formatting in a field that was originally Text (plain) or Text (plain, long). And they want their editors to be able to use a WYSIWYG, so they don’t have to deal with HTML code. What do you do?

The long way: create new field, migrate data, reconfigure

One solution is to write an update hook that will create a new field, migrate existing data to it, and delete the old field. If the field is renamed, you also have to consider reconfiguring any views, entity references, display modes, etc. that referred to the old field. Changing a field type this way is entirely possible, but more time consuming and error prone.

Wouldn’t it be nice if you could simply enable a WYSIWYG on that plain text field and be done with it? Especially if your client is on a tight budget. It’s actually possible to do this in a custom module, with a few lines of code.

The short way part 1: add a form alter

First you’ll need to add a form_alter function in your custom module, most likely in the .module file. There are many ways to add a form_alter in Drupal 8, and those are documented elsewhere. See the entry about hook_form_alter in the Drupal API.

You may also need to add some conditions so that the field is only changed on certain forms or for certain content types–this is also beyond the scope of this article.

In this example, I’m adding a general hook_form_alter() that will apply to all forms regardless of entity type. If you have a Text (formatted) field, you may want to enable a WYSIWYG on it to make it easier for editors to create the content. Because it’s already a formatted text field, the form alter is very simple.

use Drupal\Core\Form\FormStateInterface;

function mymodule_form_alter(&$form, FormStateInterface $form_state, $form_id) {
  if(isset($form['field_myformattedtextfield'])) {
    $form['field_myformattedtextfield']['widget']['0']['#base_type'] = 'textarea';
  }
}

We are only changing one value associated with the widget: we change the base_type to textarea. The editors will see a WYSIWYG, and the data will be saved and displayed as formatted text.

If you want to add a WYSIWYG widget on a Text (plain) or Text (plain, long) field, it’s a little trickier. There are a few more widget attributes to alter.

use Drupal\Core\Form\FormStateInterface;

function mymodule_form_alter(&$form, FormStateInterface $form_state, $form_id) {
  if(isset($form['field_myplaintextfield'])) {
    // Fetch the entity object.
    $entity = $form_state->getFormObject()->getEntity();
    // Get the current value stored for the field.
    $value = $entity->field_myplaintextfield->getString();
    // Change the base type for this field to a textarea.
    $form['field_myplaintextfield']['widget']['0']['#base_type'] = 'textarea';
    // Change the type of field to formatted text.
    $form['field_myplaintextfield']['widget']['0']['#type'] = 'text_format';
    // Recommended: set a default text format. When rendering
// you’ll have to manually set this to make the field use
// formatting (see next section).
    $form['field_myplaintextfield']['widget']['0']['#format'] = 'full_html';
    // Set the default value to the currently stored value.
    $form['field_myplaintextfield']['widget']['0']['#default_value'] = $value;
  }
}

This will give us the WYSIWYG where we want it, but the value is still stored and displayed as plain text. We need to add another function to transform it for output.

The short way part 2: let the fields render as formatted text

For Text (plain) or Text (plain, long) fields, we have to tell Drupal to run the stored value through one of the Text Format filters and render it as formatted text. This involves two functions and a configuration setting.

In your custom module, add a hook_field_formatter_info_alter to allow the plain text field types to use the default text formatter:

function mymodule_field_formatter_info_alter(array &$info) {
  // Let the string field types use the text formatter.
  $info['text_default']['field_types'][] = 'string';
  $info['text_default']['field_types'][] = 'string_long';
}

Then, add a template_preprocess_field function to tell Drupal which text format to use when that field is displayed as filtered text. Since this isn’t a regular formatted text field, Drupal doesn’t store that information the way it does for the standard formatted text field types. Be sure to use the same text format that you used in the hook_form_alter().

function mymodule_preprocess_field(&$variables, $hook) {
  if ($variables['field_name'] == 'field_myplaintextfield') {
    $variables['items']['0']['content']['#format'] = 'full_html';
  }
}

Lastly, we go to the “Manage display” configuration for the field in question, and tell Drupal to use the “Default” format for that field. If you are using Configuration Synchronization, you’ll notice this affects the “type” in the “Entity view display” configuration for this field.

...
  field_myplaintextfield:
    weight: 100
    label: above
    settings: {  }
    third_party_settings: {  }
    type: text_default
    region: content
...

Voila! That should be it. View your content and check that the plain text field is now being rendered with HTML formatting.

Conclusion

With just a few lines of code, we added a WYSIWYG editor to a plain text field and enabled Drupal to display its contents as formatted text. This technique will work for both Drupal 8 and Drupal 9. You can refine this approach depending on your needs to display formatted text only for certain view modes, entity types, field instances, etc.

Want to add this functionality to your site? Contact us if you’d like to hear more about our services.

Sep 29 2020
Sep 29


Image credit: Aaron Deutsch

I just started the process of preparing my Drupal 6 (!) site for migrating to Drupal 9. One of the first steps of my migration process was to figure out where to host my Drupal 9 site. Right now kristen.org is on Pantheon. Yes, Pantheon supports Drupal 6! Maybe they don't want me to advertise that though. :)

In this post, I'll discuss my initial impressions of surveying some of the biggest Drupal managed hosting companies. If your favorite hosting provider isn't covered here, let me know and I might do a follow up post.

Drupal 9 support

I've almost always used Pantheon or Acquia hosting for client Drupal projects. If the client was already using something "cheap" like InMotion or Bluehost, I would try (usually in vain) to get them to switch to a more robust managed hosting provider. When I started on this, I looked at 4 of the most popular Drupal managed hosting companies: Acquia, Amazee.io, Pantheon, and Platform.sh.

When I checked the status of Drupal 9 support by these "Big Four", I found that Drupal 9 was officially supported by Acquia, Amazee.io, and Platform.sh. Pantheon has a way to test Drupal 9 on a "multidev" (testing site) but doesn't have official support yet.

At the time of writing, Pantheon Co-Founder Josh Koenig said via Twitter that Drupal 9 should be supported by Pantheon within the next few months in time for Drupal 9.1. If you have an existing site, Pantheon's advice is to upgrade your site to the latest version of Drupal 8.9 and make sure your site is completely compatible with Drupal 9. Then, it will be very simple to jump to Drupal 9 when they flip the switch.

First impressions of Drupal 9 support

I went to each of these "Big Four" hosting companies websites to see if: 1) they supported Drupal 9, and 2) there was a free trial for me to test it. Unfortunately, I found each of the providers had some user experience (UX) or developer (DX) issues when attempting to evaluate Drupal 9. I reviewed companies in the following order.

Pantheon

Source: Screenshot of Pantheon.io Home Page

Of these "Big Four", I have the most experience with Pantheon, and I've always enjoyed their workflow and tools. Since I already have a Pantheon account and my kristen.org site is hosted on Pantheon, I logged in and went to create a new "sandbox". Pantheon allows a small number of free sandboxes to be created for each account.

My thought was that I would create a Drupal 9 sandbox and also create a "migration multidev" for my Drupal 6 site. Then, I would try to migrate directly from the Drupal 6 multidev site to the Drupal 9 sandbox site without using my local machine.

The issue I had on Pantheon was already mentioned previously. It doesn't yet officially support Drupal 9. I found this pretty surprising given that this is one of the oldest Drupal managed hosting providers.

One UX/DX issue I had was that it didn't mention Drupal 9 at all on the page where you choose a CMS. It only had WordPress, Drupal 7, and Drupal 8. I found out via Twitter that Drupal 9 wasn't officially supported yet, and that it would be probably couple months before it would be ready.

My advice to Pantheon is to add text on the CMS-selection page with Drupal 9 information or a link to a Drupal 9 page. That page could explain the Drupal 9 roadmap, including workarounds, so that others don't have to poke around to find out what to do. This would be very simple, but they said it wasn't something they typical do. Seems like a pretty obvious yet easy UX/DX improvement.

Acquia

Source: Screenshot of Acquia Home Page

I already knew that Acquia supported Drupal 9 because I saw that information fly by on Twitter. This is not surprising since Drupal is the only CMS Acquia supports. But, I wasn't sure if they had a trial version and, if they did, how long the trial was good for.

I searched for "acquia drupal 9" which went to acquia.com/drupal9, but I didn't find that page helpful. So then I searched with "acquia drupal free trial" which had "Create a Free Acquia Cloud Site" that sounded promising.

Side note: I didn't see any mention of a free trial on Acquia's site when I clicked around. Even if I used their internal search. The only way I could get to the free trial was searching via a search engine and finding the correct form. I assume this is by design as they probably want people to contact them and work with their sales team.

I went to the "Create a Free Acquia Cloud Site" page and filled in the somewhat long form asking for the site name, first name, last name, email address, password, and even phone number. Along with, of course, the obligatory and ubiquitous "I'm not a robot" and terms of service checkboxes. In my opinion, this is too much to ask for when I just want to try the service out. I'm wondering how many people drop off here.

So I filled in the form and it asks me if I want a try a free application and there's another checkbox to check (hmm…). Then it created my application and when I clicked the "next" button, it LOGGED ME OUT of the Acquia site to have me log back in. :(

Okay, so I try to log back in and it doesn't work. Since there was only one password field, I was wondering if maybe I typed the password wrong in the original form. (Yes, I know, I should use a password manager, but I haven't set that up yet.) I checked my email to make sure I didn't get an email with a confirmation link I needed to click but I didn't see one anywhere.

So, I reset my password with their form (with another "I'm not a robot"). Then I try to use the password that I thought I had used and get "Passwords must contain at least 1 special character." Ugh. This isn't going well.

At this point, I get back in but am a bit discombobulated (I like that word though not that feeling). I'm on my account page and not sure where to go. I haven't worked on an Acquia site in awhile and when I did it was mostly on the command-line for several sites that are part of a very large multi-site infrastructure. Mostly what I did in the UI was download a copy of the database because drush didn't work for those sites.

I see "DEVELOP", "MANAGE", and "ENHANCE" so I pick the first one. Under "DEVELOP", I see my new "application" (with a typo in its name, whoops). I click on it and get to a more familiar "Dev", "Stage", "Prod" workflow. But now I'm wondering if this is even Drupal 9. Since Acquia only does Drupal (unlike the other providers), I assume it must be. One thing I notice is that it's using PHP 7.3. It would be nice if it was using 7.4.

I clicked on the application link and get a very uninspiring "Welcome to Acquia Cloud" page. The Marketing department needs to help the Engineering team here to make this better. But, what's worse is that the page isn't helpful at all.

At this point, unfortunately, I'm just tired and annoyed and decide to move onto Platform.sh. One side note though was that I had tried this about a week prior to this test. I forgot to take screenshots, so that's why I did it again. It seemed a lot easier the first time around, but I'm not sure what the difference was.

That first time, I did have an issue with that application-creation process where it *appeared* to be hung up, but it really was just taking a *long* time. I gave up waiting for it after about 10 minutes. It took somewhere between 10 and 30 minutes to provision the application. It would have been good if the screen would have told me it was going to be awhile and to go get a drink or go for a walk.

Platform.sh

Source: Screenshot of Platform.sh Home Page

I've been curious about trying Platform.sh ever since I saw their first demo at BADCamp many years ago. The fact you could spin up an entire copy of your site by just creating *any* git branch seemed like a dream come true. Pantheon has "multidevs" which I love that are similar to this but are limited to a small number. This feature is much more commonplace these days with services like Tugboat.qa (which is pretty awesome).

I knew Platform.sh supported Drupal 9 and saw the eye-catching "Free trial" call to action (CTA) button at the top of their site so I started there. In my mind, this was the most compelling CTA of the four. Both Acquia and Amazee.io have "Request a Demo" which sounds like I'm going to have to talk to a sales person. Pantheon does have a "Get Started" CTA at the top as well as a "Start a Free Trial" CTA that's lower on the page but that one is overwhelmed by the bright yellow "Watch the Demo".

The biggest issue I had with Platform.sh right away was I got a "white screen of death" (WSOD) during the registration process. I think it was right after filling in my password. I was still able to go to my account after getting the fatal error and then everything seemed fine. But, this was a huge deal, obviously. Fortunately, Platform.sh fixed the issue right away which I confirmed today by trying the registration process again.

One nice thing I liked about their registration process is that I only needed to provide an email address to start with (or you can connect using Github, Google, or Bitbucket which I didn't try). Fill in your email address, an email is sent, you click on the button in the email, and it brings you to the form to fill in your password.

When going through the registration process again (to check it was fixed), I saw a lot more fields on the multi-step form with all but one required. In my opinion, username, country, and company shouldn't be required fields. Even the first and last name fields shouldn't need to be required. The only required field on the account settings page is username which could probably be defaulted based on the email address if it is really needed.

The other couple UX issues I found were 1) not knowing the password requirements and only finding out after submission, and 2) the multi-step navigation was not working properly (my data would get wiped when I used it).

Once I had an account, the process for creating a new project was very straightforward and I didn't have any major issues. I followed the process below. There is also a quick link on the Platform.sh Drupal 9 template page that will choose the template for you.

All-in-all, other than the WSOD, I was pretty happy with the Platform.sh process. I found it to be pretty straightforward. I was able to look around the page to figure out what I should do next. I appreciated the fairly simple workflow and the wizard to help with dealing with CLI and SSH key configuration. I hope to have a follow up post soon discussing the CLI and setting up Drupal 9.

  1. Click "Add a project" button
  2. Click "Use a template" option
  3. Enter "Project name" and "Region"
  4. Select "Drupal 9" template (you can filter by type of "Drupal")
  5. Wait about a minute
  6. Voila! You have a new Drupal 9 project to configure
  7. Click on the project, click URLs, and choose first URL
  8. Go through the site install
  9. Follow the "wizard" on the right of the project to set up CLI, SSH key, etc.

Platform.sh UX/DX feedback

One minor issue I had was when I looked at the templates. At first, I didn't realize you could scroll for more templates because the scrollbar doesn't show up unless you hover over the template region. Maybe this is obvious to everyone else, but I think it would be best to always show the scroll bar even if this isn't as "pretty".

One other thing was that the project placeholder image shows Error 502 which doesn't instill a lot of confidence. Maybe show the cute rabbit mascot or something more friendly and/or informative.

My final bit of feedback is that when you are on the "Projects" page, it has a link for "Back to projects". This is confusing, so it would be good to change the wording so this is clearer.

Click "Add a project" button

Click "Use a template" option

Enter "Project name" and "Region"

Select "Drupal 9" template (you can filter by type of "Drupal")

Wait about a minute

Voila! You have a new Drupal 9 project to configure

Click on the project, click URLs, and choose first URL

Go through the site install

Follow the "wizard" on the right of the project to set up CLI, SSH key, etc.

Amazee.io

Source: Screenshot of Amazee.io Home Page

I heard via Twitter that Amazee.io could do a free trial by request which they call a "demo". When I saw "demo" on their site, I assumed that meant I would sit on a call with a sales person and they would show me their platform. That is not something I was interested in. I just wanted to play with it on my own.

Amazee.io's Founder, Michael Schmid, said he'd hook me up with a free trial. At the time of writing, I haven't seen an email for that, so I'll have to report on that later. I am empathetic here—I know Michael is a busy person—so no judgements! Also, now I'm wondering if I was supposed to fill in the contact form to make trial that happen... hmm...

Regarding the do-it-yourself nature of the other platforms, the Amazee.io founder said it's called Platform-as-a-service, not Platform-do-it-yourself. So, after thinking about this more, since Amazee.io isn't "do it yourself", then it probably shouldn't be included in this "Big Four" list. My goal, for now, was to find SaaS where I could easily create Drupal 9 sites for my personal, contribution, and small business use.

11 takeaways for Drupal hosting companies


Image credit: Aaron Deutsch

It's vital for EVERYONE in the Drupal space to do the best job possible to convert users to Drupal and keep them happy. There are many good alternatives to Drupal. Every hosting provider, freelancer, agency, and service provider needs to put their best foot forward to prevent Drupal going the way of the dinosaur. Even as competitors, we must all try to shine or Drupal can get bad reviews and lose market share.

I had UX issues with all platforms I looked at, some small and some large. Here are some generic and obvious takeaways that apply to any Drupal hosting company:

  1. Have a trial option that lasts at least 30 days
  2. Make it super simple to make an account
  3. Make it obvious how to create a new trial site
  4. Searching for "[company] drupal 9" & "[company] drupal free trial" should get me there
  5. For slow installations, add expected wait time (and a video to watch might be nice too)
  6. Make it easy to find your new trial site and understand the next step to take
  7. Have contextual help text/videos where appropriate
  8. Do user testing to see where people get hung up
  9. Use Lucky Orange, Hotjar, or similar heatmap software to see where people are looking and drop off
  10. Add automated testing for the entire registration and application creation processes
  11. Be very responsive on social media

Regarding that last point, Amazee.io, Pantheon, and Platform.sh responded quickly to me on Twitter, and engaged with others who commented on the thread. From what I could tell, Acquia did not respond, so possibly missed a marketing opportunity. Note that Amazee.io responded even though they weren't even in the original Twitter thread which was a smart marketing move.

I probably could go on and on, but that's good enough for now. For this exercise, the clear winner was Platform.sh BUT, if I had been completely new to Platform.sh as a vendor, then I may have just walked away when the white-screen-of-death (WSOD) came up during registration. For what it's worth, the fact that Platform.sh fixed the issue right after I reported was another good sign.

So, my final takeaway is to always assume your potential users might walk away at any point in your conversion funnel, and test and optimize each piece as if your business depends on it. Because it does.

Side note: I (unfortunately ;) did NOT get paid by any of these companies to review their services. But, if any of these or other vendors want to hire me for focused testing and evaluation, feel free to ping me on Twitter, LinkedIn, or at drupal at kristen dot org. :)


Image credit: Aaron Deutsch

Jul 01 2020
Jul 01


Image credit: Aaron Deutsch

DrupalCon Global 2020 is in a couple weeks and there are a lot of amazing sessions. Hope you can make it! While preparing my own DrupalCon Global session, I reviewed the other sessions and made a list of ones you might want to watch to help you prepare for upgrading from Drupal 6 or 7 or 8 to Drupal 9.

In some cases, it was very hard to choose just one on a particular topic. For example, there are 3 great layout builder talks! So, while these are some of my top picks, don't forget to check out all the DrupalCon Global sessions and add your favorites to your schedule.

If you are upgrading from Drupal 8 to Drupal 9 and don't need to make any website improvements, then you can focus on the Drupal 9 sessions. If you will be doing a redesign and/or upgrading from Drupal 6 or 7 to Drupal 9, check sessions for dreaming up your new site, planning your new site architecture, and implementing your new site.

Everything you want to know about Drupal 9: the upgrade process from Drupal 6, 7, and 8, making upgrades faster with a new Acquia migration tool, the nitty gritty details on what makes Drupal 9 special, and new features coming in Drupal 9.1.

Discovery, design, and project management are critical for your web projects. These sessions cover how to manage your team, user stories and user experience work, and other important aspects of designing a great website.

Drupal is a great framework for building the website you want by customizing to your needs. These sessions cover foundational features of the Drupal system: media, layout builder, components, admin tools, SEO, and migrations.

If you are new to Drupal 8 and 9, these sessions will help you understand how to work with composer, configuration management, and Twig as well as create custom modules and migrations.

Hope to see you at DrupalCon Global!

Apologies, my old website is still on Drupal 6 and looks particularly bad on mobile. I've only started posting here again after many years and I've been very busy reviewing Drupal 9 patches and surviving a pandemic. :) Please ignore the cobbler's old shoes for now, thanks!

Jun 26 2020
Jun 26

Drupal 9 was launched on June 3, 2020. Given this, it would be necessary for enterprises to upgrade to it later or sooner to acquire complete functionality and retain the ability to receive security updates within the bi-yearly cycles.

In the past, migrating from one version to another has been similar to moving from another CMS to Drupal, bringing in more time and fatigue.

However, the upgrade from D7/8 to D9 is much easier and painless. Let’s dive into more details and understand as to why moving on to Drupal 9 would be a better choice.

Why Should You Upgrade?

With the end of life approaching for Drupal 7 and 8 soon, operating the website on them securely and with complete functionality won’t be a feasible option.

At the same time, it might also be overwhelming for Drupal 7/8 site owners to know that their website will need the upgrade, especially when their site is running absolutely fine; thereby, resulting in confusion among them.

Here are 3 reasons why you should consider upgrading your site to Drupal 9:

  1. The Drupal security team will soon no longer provide support or security advisories, wavering your website’s and its users’ cybersecurity
  2. D7 and 8 releases’ on all project pages will be flagged as ‘not supported’. D7/ 8 may be flagged as insecure in 3rd party scans making the integration with other third-party tools and systems challenging
  3. Leading hosting services providers like Acquia and Pantheon will also soon withdraw their support from D7 leaving you without many options but to assume hosting responsibility for maintaining your application and server level configurations

The good news for Drupal 7/8 site owners is that even when it goes out of official support in November 2022, remaining Drupal 7/8 sites won't stop working at that point.

Should an Existing Drupal 7 Site Be Upgraded to Drupal 8 or 9?

One of the major reasons that more than seven hundred thousand Drupal 7 sites still haven’t migrated to Drupal 8, is due to the known challenges in the migration process. And with the majority of people on Drupal 7, it is quite likely that most of them did not want to upgrade their CMS twice in the span of one year.

A safe bet seems to be migrating from Drupal 7 to Drupal 9. But will the site be secure? Let’s get to know a few facts.

Since D8 and D9 are similar except for deprecated codes removed and third-party updates in D9, it would be a feasible option for enterprises to migrate to D9 instead of D8 - to save them from constantly going through the same process and investing time, money, and efforts unnecessarily.

What’s New in Drupal 9?

There are innumerable capabilities added in Drupal 9 which further will be consistently updated biannually to help enterprises stay up-to-date.

Now once you upgrade your system to D9, you won’t require to make major changes the next time you plan to update it to a newer version. 

Here are some of the new capabilities that are added to D9-

  1. Backward compatible

    Drupal 9 is backward compatible, i.e., it is compatible with its predecessor, Drupal 8. That being said, D9 will be able to use modules, configurations, and data created on D8 of the same software, unlike the case with D7 and D8.
    Additionally, preserving this functionality won’t burden Drupal with historical baggage and so the performance of the system will remain unaffected. The Drupal community has also focused on breaking code and not the data.
    This way, Drupal will remain fast, clutter-free, and yet an up-to-date technology.

  2. Faster and Better Performance

    Drupal 9 has taken it further to extend its support for responsive images, wherein mobiles can display the best-sized images and hence, consume fewer amounts of data.
    In a recent webinar by Dries, he mentioned that Drupal 9.1 onwards versions/updates will witness the innovation and pave the way for faster and better performances of the websites. Drupal 9.1 update is just six months post the release of Drupal 9. Meanwhile, here are some of the features of D9 that you can leverage for efficient workflows-

        A.  BigPipe increasing page view performance and supporting faster initial page loading

        B.  Content Workflow allowing you to define multiple workflows

        C.  Multilingual capabilities

        D.  Structure Content- Drupal 9 comes in with an array of available fields, encompassing phone, email,       data, and time.

  3. Cleaner code base

    Drupal 9 has removed the support for deprecated codes in D8. This implementation will ensure that the code marked as deprecated will no longer be supported and used in the Drupal ecosystem. 
    The motive behind this is to make D9 a cleaner version so that whenever the modules in D8 want to become compatible with D9, they need to first eliminate the deprecated code. 
    Thus, the end result is clear- to make the code more nimble and improve the website’s performance.

  4. Newer Major Versions of Symfony and Twig

    Symfony 3 will be replaced with Symfony 4 or 5 after November 2021. Also, the Drupal community can introduce an upgrade to Twig 2.0. These upgrades will only result in enhanced performance, improved developer experience, and enhanced security.

  5. Panelizer will be removed and replaced 

    What’s new in Drupal 9? Well, the panelizer will be replaced with the Layout Builder, the “star” module of the moment.

  6. Headless CMS

    Drupal 8 and 9 both come with an API-first approach. Dries also mentioned in the webinar that the Drupal community is vigorously capitalizing on Headless CMS so that it can enhance users’ experience with the powerful front-end of the website with Javascript framework like React or Angular. 

The essential features of Drupal Headless CMS are-

  • Front-End Freedom
  • Create Once, Publish Anywhere
  • API-First Approach
  • Easier Resourcing

Drupal 9 is more usable, accessible, inclusive, flexible and scalable than previous versions, with the following updated features-

  • It will be significantly easier for marketers to use D9
  • Simple than ever to maintain and upgrade for developers
  • D9 is experimenting with its headless or decoupled capabilities

Additionally, you can also learn from our previous blog where we have explained how to find and fix the deprecated code - Site Owner’s Guide to a Smooth Drupal 9 Upgrade Experience.

Why Remove Deprecated Code in Drupal 9?

To ensure that the D8 modules remain compatible with D9, it’s typically essential to remove deprecated codes- 

  1. The all-new Drupal 9 ready code gets deployed on Drupal 8 sites and issues can be tested.
  2. It is a continuation of the fully-tested and stable codebase of Drupal 8

With time, the effort is being made to make Drupal better. There are functions that have been around for a long time but will not be a good fit in the latest release. Most were deprecated in Drupal 8.7.0, which will be removed in Drupal 9.

To sum it all, the key to achieving this smooth transition to Drupal 9 is to rollout your migration plan within deadlines and save yourself from any unnecessary hassle later on.

Srijan is working with leading enterprises to help them migrate their digital web properties to Drupal 9 for better user experience. 

If you are also looking for a smooth upgrade/migration process for your enterprise’s system, we are all ears and excited to assist you. Contact Us!

Jun 15 2020
Jun 15

I was researching Drupal 9 content and decided to collect some data. I gathered information related to the authors and the organizations whose content showed up in the top 100 Google results for "Drupal 9" (as of June 12, 2020). Check out the infographic with the data in a pretty format or skip to the plain text.

This is the first infographic I've created. I used Piktochart based on a Twitter recommendation from @akmalfikri. I liked the tool pretty well but was hoping for more mapping options based on region rather than country. If you have a favorite infographic tool, let me know.

#

Drupal 9 Authors

For the content that had authors listed, I looked at the type of content they contributed, their job titles, and for their drupal.org profiles, if any. If they had a drupal.org profile, I checked if they work on any contributed projects, how long they've been on drupal.org, how many issue credits they have, and how many core issue credits they have. I also grabbed their location, and if they are a Drupal Association member and contributed to the #DrupalCares campaign.

Author Content Types

For content with authors listed, I looked at the type of content they contributed which was lumped into the categories: Blog Post, Video, Code, or Other. The Code category is for Github code that was in the search results. The Other category includes documentation and training material.

  • Blog Post: 90%
  • Video: 5%
  • Code: 2.5%
  • Other: 2.5%

Author Job Role Types

I grouped the job roles into categories: Developer, Executive, Marketer, Writer, and Other. The Executive category includes Founders / Co-Founders, C-Levels, VPs, and Directors. The Writer bucket includes journalists and media outlet content writers as well as in-house writers for larger organizations. The Other bucket includes product managers, project managers, and people without roles listed.

Some people had multiple roles but I picked one. For example, if someone was a CTO & Architect, I used Executive even though they might be doing development.

  • Developer: 31%
  • Executive: 30%
  • Marketer: 23%
  • Writer: 8%
  • Other: 8%

Author Locations

For content with authors listed and drupal.org profiles, I looked their locations which were grouped: USA, Europe, UK, India, Australia, or Other. The Other category includes Canada and profiles that did not have a location listed.

  • USA: 60%
  • Europe: 14%
  • UK: 10%
  • India: 7%
  • Australia: 5%
  • Other: 5%

Author Profile Data

Here's profile information from the 67% of authors who had drupal.org profiles:

  • Have contributed projects listed: 71%
  • Average years on drupal.org: 10.2
    —max was 19.2 for Dries
  • Average issue credits (for past year): 61.3
    —max was 575 for catch
  • Average core issue credits (for past year): 22.1
    —max was 538 which was also for catch
  • Donated to #DrupalCares campaign: 50%
  • Drupal Association member: 60%

Drupal 9 Organizations

For the organizations that published the content (other than drupal.org), I looked at the type of content they contributed, type of organization, and for their organization drupal.org profiles, if any. In some cases, the organization had a personal drupal.org profile rather than a organization profile so those were ignored. If they had an organization drupal.org profile, I checked if they work on any contributed projects, how many people they have on drupal.org, their location, how many issue credits they have, and how many core issue credits they have. I also looked at if they are a Drupal Association member, supporting sponsor or premium/signature sponsor, and if they contributed to the #DrupalCares campaign.

Organization Content Types

I looked at the type of content that was contributed which was lumped into the categories: Blog Post, Video, Landing Page, or Other. The Landing Page category includes topic-specific landing pages as well as registration pages for webinars, training, and guides. The Other category includes documentation and training material.

  • Blog Post: 73%
  • Landing Page: 8%
  • Video: 6%
  • Other: 13%

Organization Types

I grouped the organizations into categories: Consulting, Hosting, Media, Themes, and Other. The Consulting category includes agencies, support companies, and specialty consulting though the bulk was traditional digital agencies. The Themes category is for sites that sell themes (many of these are for WordPress). The Other bucket includes training, specialized software, and technical libraries.

  • Consulting: 73%
  • Media: 6%
  • Hosting: 5%
  • Themes: 5%
  • Other: 11%

Organization Headquarter Locations

For content with organization drupal.org profiles, I looked their locations which were grouped: USA, Europe, UK, India, Canada, or Other. The Other category includes Australia, Ukraine, and profiles that did not have a location listed.

  • USA: 51%
  • Europe: 13%
  • India: 11%
  • UK: 8%
  • Canada: 8%
  • Other: 9%

Organization Profile Data

Here's profile information from the 82% of sites who had organization drupal.org profiles:

  • Have contributed projects listed: 90%
  • Average number of people on drupal.org: 52.7
    —max is 693 for Acquia
  • Average issue credits (for past 3 months): 90.4
    —max is 683 for Specbee
  • Average core issue credits (for past 3 months): 19.5
    —max is 285 which was also for Acquia
  • Donated to #DrupalCares campaign: 44%
  • Drupal Association organization member: 16%
  • Drupal Association supporting partner sponsor: 28%
  • Drupal Association premium or signature partner sponsor: 25%

Organization Anti-Racism Statements

My last blog post discussed Drupal for Justice. While reviewing the top 100 "Drupal 9" search results, I checked all the organizations for any recent blog posts on Black Lives Matter, racism, and social justice. I found a few companies with related statements that are listed below in chronological order. If you know a Drupal organization who has taken a stand on this pressing issue, let me know and I'll add them to my blog post.

Apologies, my old website is still on Drupal 6 and looks particularly bad on mobile. I've only started posting here again after many years and I've been very busy reviewing Drupal 9 patches and surviving a pandemic. Please ignore the cobbler's old shoes for now, thanks!

AttachmentSize drupal-9-look-whos-talking-header.png422.69 KB drupal-9-look-whos-talking-infographic.png897.11 KB
May 18 2020
May 18

As you may have heard, Drupal 9 porting day a couple weeks ago was a huge success! Gábor Hojtsy wrote up a great summary on the event including all the money that was raised for the Drupal Association. And, you can read my porting day recap as well. Thanks again to all who helped out.

The April porting day was so successful that Surabhi Gokte and Gabriele Maira (gambry) encouraged Gábor to organize a repeat performance and, like magic, we have Drupal 9 porting weekend coming May 22 and 23. This is scheduled during the time we had hoped to contribute at DrupalCon Minneapolis. Now we'll join each other virtually in a few days to make Drupal even better.

The goal for Drupal 9 porting weekend is to make more Drupal 8 contributed projects (modules, themes, and distributions) compatible with Drupal 9. As of May 16, 2020, there are 1,617 out of 8,982 projects that already work on Drupal 9. So, during the porting weekend, we'll work on the 7,365 that don't. While that might seem like a daunting number, about half of those (3,405) likely only need a one-line change to make the project Drupal 9 compatible!

There is a wonderful effort underway right now to automate Drupal 9 compatibility issue and patch creation for contributed projects. Even with this effort, we still need your help during porting weekend. We hope you can participate!


Image credit: Aaron Deutsch

I've listed some useful Drupal 9 porting resources you can review and information about collaborating in Slack during the event. I've also added specific sections for preparation depending on the type of contribution you are hoping to do:

There are a lot of Drupal 9 resources, but here are some that are particularly helpful for preparing for patch weekend:

  1. Drupal 9 readiness (#d9readiness) channel on Slack
  2. Drupal 9 compatibility contribution quickstart guide
  3. Drupal 9 Deprecation Status
  4. Drupal 9 compatibility ContribKanban board
  5. Drupal 9 porting weekend ContribKanban board (to be filled in :)
  6. Upgrade Status
  7. drupal-rector
  8. Upgrade Rector
  9. Running PHPUnit tests
  10. simplytest.me
  11. dreditor Chrome browser plugin
  12. Drupal 9 porting day recap
  13. How to prepare for Drupal 9 Porting Weekend
  14. Drupal 9: Status, Resources, and Ways to Contribute

We'll be collaborating in the Drupal 9 readiness (#d9readiness) channel on Slack. If you don’t have access to Drupal Slack click here to get an invite.

When you are ready to join the porting weekend, announce yourself in the Slack channel with something like "I'm here to contribute and will be helping for the next X hours. [insert what you are hoping to do or if you need help here]", e.g.

  1. I will be working on my personal Foobar module and don't need any help but will post status updates here.
  2. I will be working on my personal Foobar module and would like help reviewing/testing.
  3. I will be finding my own issues to work on and will post them here as I work on them so others can collaborate.
  4. I don't have an issue I'm working on but am open to creating patches.
  5. I don't have an issue I'm working on but am open to reviewing/testing patches.
  6. I'm not sure what to help with and need guidance.

We will be using Slack threads extensively during porting weekend. Each project or issue that is being worked on should ideally have a Slack thread associated with it in the channel. Also, if you are responding to questions in the channel, please respond via a thread unless the answer is a simple yes/no type response that won't have other people chiming in. It's best to err on the side of creating threads in order to keep the "chatter" organized so that it's easier for people to understand what's happening and being worked on.

There will be mentors available to help match people with projects and issues. The mentors are listed on the Drupal 9 porting weekend event page. If you have questions, please do not send direct messages to the mentors unless there is a Drupal Code of Conduct issue that you need help with. You can send questions directly in the #d9readiness channel. You don't have to be a mentor to answer questions. If you know the answer and have time to respond, please do so.

Do you want to help out during porting weekend but don't want to think about it until then?

No worries! Show up in the #d9readiness Slack channel and announce your arrival along with what you'd like to help with. If you don't know how to help, that's okay too. The mentors can find something for you. :)

Do you like the idea of helping but haven't done it before and you're not sure you'd like to participate?

No pressure! Join the #d9readiness Slack channel and watch in real time as people contribute together. It's okay to just hang out and see how it happens. You won't be forced to do anything but, who knows, maybe you'll change your mind and jump in after all. :)

Note: If you are interested in livestreaming the event on Twitch.tv or similar, let us know via the Slack channel. Thanks to Ofer Shaal for this great idea!

Have you prepared any websites or contributed projects for Drupal 9 already? Or helped with Drupal 9 compatibility issues in the issue queues?

Nice! We could use your guidance. If you are up for mentoring at this event, contact Gábor Hojtsy and let him know what days and times (with time zone) you can cover. Even if you can only help for an hour or two, that's okay! Ideally, we'd love to get 1 to 2 people covering all times across all time zones over the 2 days. You can check the current coverage on the Drupal 9 porting weekend event page.

After you sign up, make sure to join the #d9readiness Slack channel and arrive during your planned time. If there are other mentors there already, check in with them to see if they need any help with anything. Otherwise, scroll backwards in the Slack channel to catch up on what's been happening and if anyone has asked for help and didn't get a response.

How you mentor others will depend on what they need help with. Someone might need help finding an issue or project to work on. Another might have a technical question when reviewing a patch. If you are worried you might not know how to answer all the questions, it's okay! If you don't know the answer, just let them know and, if possible, see if someone else in the channel knows the answer. This is how we learn together.

If time allows, we hope to have an up-to-date list of issues to start with at the beginning. Stay tuned in the Slack channel for more information about this.

Are you good at searching the issue queues?

Searching the issue queues for existing issues is a very valuable skill that should not be underrated. Sometimes we might forget to check if there is already an issue for our Drupal 9 compatibility problem and create a new one and we end up with duplicates. It happens to the best of us. I've done it myself!

Maybe you aren't up for doing any issue patching, reviewing, or testing but would be happy to look for existing issues or see if issues are duplicates and close out the extras. We'd love that type of help! If you would like to focus on this aspect of contribution, here are some tips:

Check the Drupal 9 plan of the project

A thousand projects set their Drupal 9 plans up for their project pages. Project maintainers can do this by editing their project manually. If a Drupal 9 plan is provided, and it does not say the project is Drupal 9 compatible already, it would be the best starting point for finding the related issues. There still may be other issues that need triage though.

Searching the issue queues

If there was no Drupal 9 plan or even if there was a Drupal 9 plan, looking for other issues may turn up things you can clean up. You'll want to use the "Advanced search" when searching the queue and make sure to look for all issues rather than just open issues. I've made the mistake before where I was only looking at open issues and missed ones that were fixed but closed.

Keep in mind that some issues are tagged with "Drupal 9 compatibility" but not all are. In some cases, issues won't be tagged at all. There is an old tag called "Drupal 9 readiness" that was mistakenly used. If you find relevant issues that aren't tagged with "Drupal 9 compatibility", you can add the tag as you come across them. Only remove the "Drupal 9 readiness" tag if the issue is tagged with "Drupal 9 compatibility".

The issue titles aren't consistent so you'll need to search for various keywords within a project's issue queue, e.g. "drupal 9", "compatibility", "deprecated", "deprecation", "port", "update", "readiness", "core_version_requirement". Searching for these types of keywords using the "Advanced search" should help you find most, if not all, relevant issues.

If you need a refresher on the issue status codes, the "Status settings of issues" documentation is helpful. For the porting weekend, it would be good to work on issues with "Active", "Needs work", and "Needs review" statuses. You can also double check that the "Reviewed & tested by the community" (RTBC) issues were actually reviewed and tested by someone before moving to the RTBC status. The person adding the patch should not set the issue status to RTBC themselves.

What do these issues look like?

It's good to be familiar with what these Drupal 9 compatibility issues typically look like. Here are some examples with their current status as of May 16, 2020:

  1. Info.yml file core_version_requirement changes
  2. Deprecations
  3. Miscellaneous

What issues can be closed?

It's important to only close issues if you know they are duplicates or are irrelevant. If you find more than one issue where they are for the same thing (e.g. updating the info.yml file), then you'll have to assess which, if any, should be closed. This is a judgment call that's handled on a case-by-case basis.

Example 1: Both issue 1 and issue 2 are for info.yml file changes. Neither have had any work on them or any comments. In this case, I'd keep the first issue and close the second as a duplicate and specify the first issue in the "related issue" field on the second issue.

Example 2: Issue 2 had work done on it and has a patch and issue 1 doesn't have any work done yet. In this case, I'd keep the second issue and close the first and specify the first one in the "related issue" field of the second issue.

Example 3: Both issue 1 and issue 2 have had work done. This one is trickier. If it's obvious who did the work first, I'd close out the later issue and add the "related issue" to the other one. If it's not obvious which should be closed, I'd add a comment to both issues and set both of them up to be related to each other.

Example 4: This is a scenario that happened to me recently. Issue 1 was for the info.yml file and issue 2 was for dealing with the jQuery library dependency. Issue 1 had a patch and was RTBC. Issue 2 eventually added the info.yml file fix into the patch for the jQuery dependency changes. This made issue 1 a duplicate so it was closed. The person who did the patch for issue 1 was given an issue credit on issue 2 even though they didn't work directly on that issue. (Issue credits can only be assigned by project maintainers, so when working on issues of projects you don't maintain, please leave a note suggesting to add the appropriate credit for the issues you closed).

When should issues be created?

If it's clear from searching the project's issue queues that there are no existing issues for Drupal 9 compatibility, the next step is to double check using the Upgrade Status module. This can be done using simplytest.me or your local machine.

If it's a module, you would enable the module you want to check and enable the Upgrade Status module. Then you would check the Upgrade Status page for the module's Drupal 9 compatibility info. Ideally, you would check the module's most recent release as well as the module's dev version. This is because it's pretty common for compatibility fixes to be in the dev version but not in an official release yet.

It is useful to have the dreditor Chrome browser plugin when creating issues so that you can follow the issue formatting guidelines. But, don't let this keep you from creating issues. You can look at this issue example for formatting.

Please tag all Drupal 9 compatibility issues with the tag "Drupal 9 compatibility" and, if you are working on it during the porting weekend also tag it with "Drupal 9 porting weekend". Please do not tag it with outdated tags like:

  • "D9 readiness",
  • "Drupal 9 readiness",
  • "Drupal 9",
  • "D9 update",

or create new tags. It is difficult to find issues when lots of different tags are used. Other tags that may be relevant to add are "Novice", "Needs tests", "Needs manual testing", "Needs reroll", and "Needs issue summary update".

Are you a developer interested in creating or updating code patches?

For some projects there are already patches ready for review and testing but, for others, new patches need to be created manually or using the drupal-rector utility or the Upgrade Rector module.

Note: It is very important to check the issue queue first to make sure you are not creating duplicate patches.

Using a local development environment

To create and update code patches locally, you have a number of options. I'm agnostic on local development tools and have used LAMP, MAMP, MAMP PRO, Lando, and DDEV at one time or another. I've known others who've successfully used Docksal and WAMP.

Pick your favorite or try something new. If you want to be more efficient during the porting weekend, I highly recommend you set up your local environment a few days beforehand. You'll want to make sure you know how to "blow away" your testing site easily and recreate it.

Generating patch files

If you are new to creating patches for Drupal projects, I highly recommend scanning the Advanced patch contributor guide. Since I don't create patches regularly, this is where I go to refresh my memory every time I make one.

For additional information for creating patches manually or using Drupal Rector, Tsegaselassie Tadesse (tsega) wrote a great post for the event: "How to prepare for Drupal 9 Porting Weekend".

Are you a developer who understands Drupal coding standards and has an eye for detail?

For every patch that gets committed, it's best practice for someone who didn't write the patch to review the code. Code patches might be simple, one-line changes or complex changes that span many files.

The patches we are focused on for the porting weekend will be mostly deprecation patches and info.yml file patches. Sometimes these are combined into one issue and sometimes they are split out. You can review some example issues above. For the info.yml file patches, these are trivial to code review. Ideally, someone should test the patch as well before marking these issues RTBC.

For reviewing deprecation patches, you'll likely need to check the change record for the deprecation to see if the code is updated properly. Some of these are pretty straight forward such as replacing drupal_set_message with the Messenger service while some will be more involved like handling the removal of jQuery UI from Drupal core.

If the changes look good and you have time to successfully test the patch as well, the issue can be marked RTBC. If you review it but don't test it, add a comment with your notes and make it clear that it still needs manual testing and add the "Needs manual testing" tag. If the patch needs changes, add your comment with feedback and move the issue back to "Needs work".

When doing code reviews, it's very useful to use the dreditor Chrome browser plugin". This will provide a UI for reviewing the code as well as some shortcuts when editing your comment.

Do you like testing things?

Manual testing is a vital part of fixing issues. For each project that's made Drupal 9 compatible, we need people to try out the updates to make sure they don't break anything. How you test depends on the project. Some will be easy to test and some won't be. Ideally, you'll need to be familiar with the contributed project features to test properly though, for simpler projects, looking through the project page and README file might be enough to get you going.

Testing using simplytest.me

In many cases, you can test using simplytest.me. If you haven't used this wonderful tool, you've been missing out! There are times when I don't want to install a site locally but want to contribute by testing a patch. This is very common for me right now because my laptop is almost out of disk space. ;) But, it could be that you are on a computer that doesn't have a development environment set up or you just don't want to set one up for whatever reason.

If you'll be using simplytest.me, I highly recommend installing the dreditor Chrome browser plugin so that when you see patches in the issue queue, you'll see a SIMPLYTEST.ME button. Click that and it will open a new tab with the relevant project and patch. You don't have to install the plugin though; you can go directly to simplytest.me and choose the project and add the link to the patch.

Note, at the time of writing, simplytest.me is working for testing Drupal 8 versions but not Drupal 9. For contributed projects that are sticking with a Drupal 8 version and making that version Drupal 9 compatible, then you can test the Drupal 8 version on simplytest.me. For projects that are making a Drupal 9 version, then you'll need to test locally. If you are able to help with updating simplytest.me for Drupal 9 support, please contact Adam Bergstein (@nerdstein) in the #simplytestme Slack channel.

Side note: When testing core patches, something to double check is that you are testing the correct version. The version selected automatically on simplytest.me is the same as the version on the issue. This isn't always the version for the patch you are testing. This is not a problem with contributed project issues as long as the version on the issue is correct.

Testing with a local development environment

If you want to test locally, you have a number of local development options. One advantage of local testing compared to simplytest.me is that it's usually faster to spin up and refresh your site in between testing different patches. With local testing, you can also test what happens when you are on an older version of the project and update the code with composer.

Reporting your results

As you manually test a project's features, it's good to take screenshots of key things as you go so that you can upload a select number in your comment. You don't have to take tons of screenshots, but you especially want to screenshot any bugs you find during testing and also copy any error text you encounter.

When you are done testing, it is very helpful to explain your steps in a bulleted list. For example, here's a Smart Trim issue comment I added with steps to reproduce and screenshots. Bonus points if you add the testing instructions to the issue summary so it's easier for others (and yourself!) to find it later.

Please add information about your testing to your issue comment instead of a "works for me" type comment. It is much more helpful to know what you tested, if it worked as expected or not, error text if available, and select screenshots showing it working or not working.

Thanks!

Big thanks to Gábor Hojtsy and Ofer Shaal for reviewing and fine-tuning this post. It takes a village to make Drupal its best! We hope you join us for Drupal 9 porting weekend, no matter how you'd like to participate.


Image credit: Aaron Deutsch

p.s. Apologies, my old website is still on Drupal 6 and looks particularly bad on mobile. I've only started posting here again after many years and I've been very busy reviewing Drupal 9 patches and surviving a pandemic. :) Please ignore the cobbler's old shoes for now, thanks!

Apr 29 2020
Apr 29

These are the steps I went through on "Drupal 9 porting day" on April 28, 2020, which was initiated by Drupal core "Initiative coordinator coordinator", Gábor Hojtsy. It was focused around timezones: Australia & New Zealand, Europe, and Americas.


Image credit: Aaron Deutsch

I'd like to dedicate this post to Hook 42 and to my family in lockdown (sons Aaron & Jacob, husband Josh, and mom Merleigh). Hope everyone reading this is healthy and safe!

Please pardon my super crude Drupal site (especially if you are on mobile)! I haven't written blog posts here since 2013, and it's running on Drupal 6! o_O Yes, the cobbler needs new shoes, and I hope to get some in the next few months. Meanwhile, this was important and timely enough information that I didn't want to wait to update the website before putting it out into the world. And, it's pretty ironic I'm writing about Drupal 9 patches on a D6 site ;)

Thank you!

Huge thanks to Gábor for the porting day idea and coordination as well as the amazing #DrupalCares Drupal 9 module challenge! The Drupal community is very lucky to have you.

Also a big thanks to the many porting day coordinators and participants listed in order of Slack participation (if I missed someone, please ping me on Twitter or Drupal.org and I'll try to add quickly): heddn, xjm, berdir, longwave, mondrake, penyaskito, ccjjmartin, drumm, damienmckenna, nterbogt, larowlan, shrop, kimb0, dww, surabhi.gokte, Peter Wong, jungle, Ankush Gautam, Ankush Gautam, Ankit Pathak, VladimirAus, mirom, dan2k3k4, klausi, Kiran Rao, geerlingguy, DuaelFr, renatog, svenbergryen, neetumorwani, shaktik, bircher, Matroskeen, alexpott, Jeevan, Atul Sharma, Manuel Garcia, piyuesh23, Nitish Singh Guleria, wizonesolutions, rahulrasgon, renatog, Paulo Calaes, JayKandari, Amit Sharma, Sonal, Matroskeen, Tejas Shah, kristen_pol, nerdstein, Nitesh, jrockowitz, mikelutz, jurgenhaas, eojthebrave, KarinG, Leeotzu, mixologic, japerry, Vishal Chaudahry, mikelutz, Aimee Rae

Step 0: Resources used

There are a lot of Drupal 9 resources out there but here's what I focused on for the porting day:

  1. Slack readiness channel
  2. Drupal 9 compatibility contribution quickstart guide
  3. Drupal 9 Deprecation Status
  4. drupal-check
  5. Upgrade Status
  6. drupal8-rector
  7. Upgrade Rector
  8. Running PHPUnit tests
  9. State of Drupal 9
  10. Various Drupal issue queues and change records


Image credit: Gábor Hojtsy

Step 1: Checking in via #d9readiness

I woke up early due to an Ash-throated Flycatcher repeatedly pecking the window. Since my family was asleep, I checked the #d9readiness Slack channel to see what was going on. I saw a message from Gábor asking if anyone needed help picking a project to work on. Someone else said they wanted help finding a project, and Gábor suggested they look at projects from "group 100" in the Drupal 9 Deprecation Status report that only need info file updates. Earlier others had already been looking at "group 50".

I chimed in saying that I couldn't sleep so would try to find one from the list as well. I went to get (decaf) coffee (yes, I know) and more importantly chocolate to keep me going. The person asking for help chatted that they couldn't find anything in "group 100" so they were going to start looking in "group 200". So that is where I started. (Side note that it did turn out there were projects in "group 100" that could have been worked on but I found that out after picking something from "group 200".)

Step 2: Looking at an existing Slack thread for example

Gábor suggested looking at a Slack thread to see the process with a real example for D8 Editor Advanced link module. He went through the analysis roughly as follows:

  1. Searched issue queue and found existing D9 deprecated report that showed no errors: https://www.drupal.org/project/editor_advanced_link/issues/3042615
  2. Checked in the dev code that the info file hadn't been updated yet
  3. Scanned the dev code and found it was "very simple"
  4. Suspected there might be JavaScript deprecations but they were using core so "ok"
  5. Double checked deprecations with Upgrade Status module to get a more complete picture (has more detail than drupal-check) and found no issues
  6. Concluded that only the info file needs updating
  7. Was going to submit an issue for the info file but found existing one: https://www.drupal.org/project/editor_advanced_link/issues/3105317
  8. Added comment with review process and tagged the issue with "Drupal 9 porting day": https://www.drupal.org/project/editor_advanced_link/issues/3105317#comme...
  9. Pinged a project maintainer via Slack to see if it could be committed
  10. Maintainer is busy but will hopefully will commit it soon
  11. End of work on this project... time to move to another one :)

Step 3: Finding a project

Needed to find a project that isn't D9 ready but isn't being actively worked on by others.

  1. I went to "Drupal 9 Deprecation Status" for <=500 for projects that appear to only need info.yml file updates

    Although I was only looking specifically at <=500 for info.yml file issues, you can find all projects that need an info.yml file update or all projects that still need any type of work for Drupal 9 compatibility.

  2. Decided to work backwards from the end of the list of "Group 200" because other people are probably going in top-to-bottom order. This is the order I will check:
    • views_accordion 1.3
    • override_node_options 2.4
    • ckeditor_font 1.0
    • workbench 1.1
    • field_formatter_class 1.1
    • contribute 1.0-beta8
    • block_content_permissions 1.8
    • auto_entitylabel 3.0-beta2
    • menu_admin_per_menu 1.0
    • search_api_autocomplete 1.3
    • media_entity_browser 2.0-alpha2
    • username_enumeration_prevention 1.0
    • colorbutton 1.1
    • panelbutton 1.2
    • real_aes 2.2
    • schema_metatag 1.4
    • antibot 1.3
    • token_filter 1.1

  3. Checking views_accordion

Step 4: Info patch review

The info patch was the easiest to review so I started there:

https://www.drupal.org/project/views_accordion/issues/3100388

  1. Read through the change record for the change

    https://www.drupal.org/node/3070687

  2. Reviewed the patch and, for Drupal 8, the patch is correct (note that for D9, the info file will need to be updated)

  3. Tests are failing so checked the note from @katherined about $defaultTheme and confirmed that it's fixed in the other issue (see below)

  4. Downloaded the module code

    git clone --branch 8.x-1.x https://git.drupalcode.org/project/views_accordion.git

  5. Downloaded the patch

    wget https://www.drupal.org/files/issues/2020-03-21/3100388-3.patch

  6. Applied the patch
    [mac:kristen:views_accordion]$ patch -p1 < 3100388-3.patch
    patching file views_accordion.info.yml
  7. Added comment with findings and unassigned issue

    https://www.drupal.org/project/views_accordion/issues/3100388#comment-13...

Step 5: Checked back into with the #d9readiness channel

It's a good thing to check in with the relevant Slack channel regularly if you are doing a sprint or contribution day. Fortunately I did because I saw @penyaskito pointed to an earlier message from the module maintainer, @Manuel Garcia, related to the issue I was about to review.

https://app.slack.com/client/T06GX3JTS/CDDD98AMN/thread/CDDD98AMN-158808...

They were worried the patch might break existing installations. The thread had a helpful discussion with @berdir and @penyaskito on how to proceed. This is a great example why the Drupal community is amazing!

Step 6: jQuery UI patch review

Besides the info file, there was a blocker for D9 compatibility due to the use of jQuery so I moved on to reviewing the related patch:

https://www.drupal.org/project/views_accordion/issues/3091388#comment-13...

  1. Reviewed the change records
    • https://www.drupal.org/node/3064015 - "Modules and/or themes depending on jQuery UI should remove it as a dependency and manage their own libraries."
    • https://www.drupal.org/node/3067969 - "The jQuery UI asset libraries not in use by Drupal core have been marked deprecated and will be removed from core in Drupal 9." Note: has an explicit example for switching to the jQuery UI Accordion module
  2. Reviewed the patch against the example in the change record
    1. Info file is updated with dependency: jquery_ui_accordion:jquery_ui_accordion
    2. Reference of core/jquery.ui.accordion changed to jquery_ui_accordion/accordion in libraries file
    3. Fixed failing tests by adding:
      protected $defaultTheme = 'stark';
    4. Also updated composer.json with dependency:
      "drupal/jquery_ui_accordion": "^1.0"
    5. Looks good
  3. Downloaded patch

    wget https://www.drupal.org/files/issues/2020-03-21/3100388-3.patch

  4. Applied the patch successfully (note that it was applied on top of the info file patch to see if they were compatible)
    [mac:kristen:views_accordion]$ patch -p1 < 3091388-6.patch
    patching file composer.json
    patching file tests/src/Functional/ViewsAccordionTest.php
    patching file tests/src/FunctionalJavascript/ViewsAccordionTest.php
    patching file views_accordion.info.yml
    Hunk #1 succeeded at 5 with fuzz 1 (offset 1 line).
    patching file views_accordion.libraries.yml
  5. Searched the code for "jquery.ui.accordion" after applying the patch and found a reference to it in the documentation
  6. Added comment, marked "Needs work", and unassigned
  7. Next steps needed are to update this patch with minor change and manually test the updated patch and the info file patch together on Drupal <8.7.7, 8.8, and 9 (optionally, an update function could be added for the new module dependency)

Step 7: Review project page

Note that this should have been done before step 4 but I forgot to check until after reviewing the issues I found by manually looking at the issue queue.

Project maintainers can add Drupal 9 information and link to relevant issues as noted by in https://twitter.com/DropIsMoving/status/1130868996771844096. Adding D9 information to the project page will potentially help the previous two issues get worked on faster and avoid duplicate issues.

  1. Reviewed the views_accordion page for D9 info but nothing was there

    https://www.drupal.org/project/views_accordion

  2. Checked the issue queue to see if a related issue was already created but didn't find anything relevant

    https://www.drupal.org/project/issues/views_accordion?text=drupal+9

  3. Created an issue to add the Drupal 9 info to the project page and tagged it for "Drupal 9 porting day" and "Drupal 9 compatibility"

    https://www.drupal.org/project/views_accordion/issues/3131959

Step 8: Install D8 site to check deprecations

For this round, I decided to use simplytest.me to check again for deprecations after adding the jQuery patch above, the jQuery UI Accordion module, and the Upgrade Status module. Note that initially I applied both patches but got an error that I created an issue for: https://www.drupal.org/project/simplytest/issues/3131964

  1. Go to https://simplytest.me/
  2. Open "Advanced options"
  3. Type "views_accordion" for "Enter a project name" text field
  4. Choose 8.x-1.x for version
  5. Click "Add an additional project" button
  6. Type "jquery_ui_accordion" into text field
  7. Click "Add an additional project" button again
  8. Type "upgrade_status" into text field
  9. Click "Add a patch" button
  10. Copy/paste the patch file URL

    https://www.drupal.org/files/issues/2020-01-30/3091388-6.patch

  11. Click "Launch sandbox" button
  12. Wait for simplytest.me to finish installing
  13. Success! You'll get a URL similar to:

    https://stm5ea90733d366a-snjvt0qoedy7maoqy3mzycrx6vzbeixv.tugboat.qa/

  14. Log into site (admin/admin)
  15. Go to Upgrade Status report at /admin/reports/upgrade-status

  16. Go to the CONTRIBUTE PROJECTS section

  17. Choose Views Accordion
  18. Click "Scan selected" button
  19. Found 5 warnings
  20. Click on warnings link to view warnings and really found 3 things
    1. Class Drupal\Tests\BrowserTestBase not found and could not be autoloaded.
    2. Class Drupal\FunctionalJavascriptTests\WebDriverTestBase not found and could not be autoloaded.
    3. Add core_version_requirement: ^8 || ^9 to views_accordion.info.yml to designate that the module is compatible with Drupal 9. See https://drupal.org/node/3070687.

  21. I assume a and b are due to running via simplytest.me (I looked at other deprecation issues and didn't see anyone "fixing that") and c is handled by the other patch so this should be covered
  22. Updated Slack channel thread with note about the autoload warnings

Step 9: Go to bed :)

I was hoping to do more poking around but it got late and I got tired. So… this will have to do. I updated this blog post and went to bed. :)

Goodnight!

p.s. I'm zonked so probably made some mistakes... please let me know if you find any.

Dec 06 2019
Dec 06

You may have read our previous articles about how to plan for Drupal 6 or Drupal 7 End-of-Life. The important thing to know is that the Drupal 8 End-of-Life is nothing like those. In fact, “End of Life” is completely the wrong idea. Instead, it’s more like one of those spa treatments where you get a full body scrub to get rid of the dead skin cells. You walk out feeling rejuvenated and refreshed. 

Drupal 9 — Same as Drupal 8, But Without The Old Stuff

Drupal release timeline

In each new minor version of Drupal 8 there are some new features, and some old code is marked as “deprecated” (that just means that it’s time to stop using this, because it’s going to go away some day). After nine minor versions over almost five years, there’s now an accumulation of deprecated code. This deprecated code is like those dead skin cells that you go to the spa to get rid of.  So Drupal 9.0 will be the same as Drupal 8.9, just without the deprecated code. The two might even be released at the same time. 

Then, in Drupal 9.1, we see the cycle starting again: some new features, and some old code is marked as deprecated.

Don’t Rely on Deprecated Code

In the graphic above, you’ll notice that 8.9 does not have any more deprecated code than 8.8. That means that once a website is upgraded to 8.8, we can then start the process of ensuring that the site isn’t using any deprecated code. 

If you are an Advomatic client, we’ll create a ticket in your queue to clean out all uses of deprecated code. In fact, if you’ve done a project with us recently, we’ve already started doing this as part of the Q/A process in our two-week sprints. 

A Window of Almost Two Years for This Cleanup

Drupal timeline by quarters

This is the timeline for the next several versions of Drupal.  We’ve got about 2 years to make this change — more than enough time. 

Alternating Minor Versions

We handle all the technical stuff for you. But the purpose of the website is not for us to have a technical toy to play with, it’s to advance the mission of your non-profit. So we want to devote most of our time and effort towards your web strategy. While we could upgrade your website to the newest version every six months, it’s not the best use of your money or time. So we alternate versions. That means that your Drupal 8 website is either always on an even minor version, or an odd minor version. 

We’ll likely continue that pattern as we cross the threshold into Drupal 9. That means that this process could be delayed by 6 months from what you see here.

Flipping the Switch

Once we’ve cleaned up all the deprecated code, then we’re ready to upgrade the site to Drupal 9.  Remember: this is nothing like past major upgrades in Drupal. Instead it’s just like the minor upgrades from Drupal 8.6 → 8.7 → 8.8 etc.

Conclusion

The key takeaway is that this whole process should be almost seamless. We’ll create a few tickets in the queue to prep for the upgrade, and then for the upgrade itself.  But the majority of our time will still be spent on advancing your mission. Over the years to come the website content and its presentation will be able to continually evolve, all without a costly major upgrade. 

Thanks to Amanda Luker for the charts!

About Drupal Sun

Drupal Sun is an Evolving Web project. It allows you to:

  • Do full-text search on all the articles in Drupal Planet (thanks to Apache Solr)
  • Facet based on tags, author, or feed
  • Flip through articles quickly (with j/k or arrow keys) to find what you're interested in
  • View the entire article text inline, or in the context of the site where it was created

See the blog post at Evolving Web

Evolving Web