The Big Leap - Picking The Right Drupal journey towards Drupal 10

SPEAKER:
Good morning. Good afternoon, everyone, and welcome to the session on The Big Leap-Picking The Right Drupal journey towards Drupal 10. So yeah, this is about me and I have worked with PHP, Drupal for over 13 plus years now, and I play the role of a Drupal Staff Engineer at Axelerant. I'm also a Drupal certified expert in Drupal 8. I have led large teams of teams of large size from a technical front up to a maximum of 20 member team, 18 to 20 member team. And I also love to travel and explore new places. Yeah. So, I work for Axelerant. We are an integrated global delivery partner that puts for agencies and customers, that puts care into employee happiness, engineering excellence, and customer success. So getting onto the topic. Can I interrupt you here? We can actually see your notes on the back. I'm sorry. Sorry. Yeah. There we go. That's good. Yeah. So we will talk about The Big Leap first and the... First of all, Drupal 7 End of Life is again extended till end of this year. And we also have a very good chance of it being extended another more year because they will reevaluate it every year.

So that being said, the big question that is on everyone's mind is whether we should go ahead with the migration to Drupal 9 and 10 or should we wait and see till the end of the year. Or I believe in June they would say whether it's further going to be extended or not. And based on that, if it's not extended in the worst case, of course there are a lot of sites running on Drupal 7 but still there would be a lot of rush to upgrade to Drupal 9 and 10 because of security updates not provided to Drupal. So that being said, Drupal 10 is also released and pretty much stable version. And so we will look at what are the major reasons at a very high level why we need to upgrade to Drupal 9+, and then we will go deeper into what we did for one of the migrations that we migrated from Drupal 7 to Drupal 9. And here, first of all, you can't upgrade to Drupal 8 obviously because there's no security coverage. And one of the good first obvious benefits is that you get better performance due to the completely changed architecture and also usage of Symfony and big pipe caching strategies and things like that.

You also have multi-channel support, omnichannel where you can use your content and relay your content to any type of device using restful services and things like that. So other than that, you also have there are better editorial experience due to CKEditor 5. And also there are support for modules like Gutenberg, which is which is used in WordPress. So that is also pretty decent in Drupal 9+. So you can use Gutenberg also in Drupal 9 and 10. So that is, other than that, the overall change in administrative interface by Claro and Olivero themes. And also, that also provides a good amount of accessibility benefits as well with the good amount of accessibility modules also available like all-in-one accessibility and a lot of other accessibility modules are also available. And of course, you also get automatic updates from Drupal 9 to Drupal 10. And as we move towards Drupal 10 it is expected to become more easier to do major upgrades between Drupal versions. And one of the other major differences between Drupal 7 and Drupal 8+ versions is that anything is manageable as an entity.

So you would not have that flexibility out of the box in Drupal 7 whereas in Drupal 9 and 8+ you can manage any entity as a feasible entity and you can add fields or remove fields for any entity. So, that being said, these are the various reasons to upgrade to Drupal 9. Yes, being in Drupal 7 is like is good. It's good like it's being in a comfort zone but we have to at some point, we have to have some conversations and take the decision to move forward because what we are going to gain by moving towards Drupal 9+ is much more larger than what we are gaining by staying with the Drupal 7. So that being said, so I would like to ask what are the different aspects you would want to consider when moving from Drupal 7 to Drupal 9+? Like what are the general things that comes to your mind immediately? Theming. Theming changes. Sorry, I didn't... Theming changes and custom codes. Theming. Yeah. Yes. Yeah. Yeah. Theming changes. Custom code. Yeah. Those are very obvious modules. Yes. Modules as well.

Yeah. But these are, yes, it's a very good chance to completely change the theme as we move from Drupal 7 to Drupal 9 because anyway, we would have to do that particularly because we have to move from tpl to Twig templates, and that that is unavoidable and we would have to of course, rewrite the custom modules. But these are all from a developer perspective, right? So from a developer perspective, yes, theming changes, custom modules, and everything is there. But there are also other areas which we can focus more. And that's what we will discuss more here because that will drive a lot of improvement from an end user and editorial perspective as well. Theming changes and custom modules are definitely something that we have to do. We cannot avoid it. But I would be discussing on other topics as well like we are going to see now. So first thing is how are we going to handle the content types? It might be a very straightforward answer, like we are just going to migrate the content types from Drupal 7 to Drupal 9 and it's as simple as that, but it's not.

So there are a lot of things that we can do and it would be better if we do at this point rather than doing it after we do the migration as a cleanup activity. So, that is one thing. And we are going to. Taxonomy is one area where there might not be a lot of changes, but still, it's worth reviewing that and modules as well. So I will be sharing in this session what we did in each of these cases and how it has helped us to refine the information architecture of the entire site. And we will go into each of these topics. And we also looked at the roles, revisited the roles, the users, and the content workflow that is currently used in the site. And we also saw how we are going to manage the media in the new website or the new platform, and we will talk about that as well. And we will talk about how we did some field re-engineering aspects as well. And in general, we will end with what are the other aspects that we need to cover. And finally, how we documented all of these decisions and how it is important to do that as the final step.

And of course, documentation is something that it is last but it's not the least. We have to do that in order for communicating the decisions much better for the following team or the team that's going to implement the migration. So these entire slides are based on the discovery that we did as part of this project. And so first looking at the content types, it all starts with our... It's very important that we look at the content types with a clean slate without having in mind, like forgetting just for a minute like not really concerned about what is the content type that we have in Drupal 7 but asking what is it that we are going to carry forward to Drupal 9? Really not worrying about the technical feasibility of things but looking at what it is that the customer really wants or what is that the editors are really using. So, for example, it all starts with asking the meaningful questions like whether we are using this content type in Drupal 7 in the first place or it's just been there since the site has been up for a long time and we are not anymore creating active content in the content types.

And another question would be something like whether we are using all the fields in the content types and whether we need to change the data type for any of those fields and things like that. So we will look at what is the feasibility of changing the data types. We have some restrictions there, but it's still something we can do as a kind of pre-processing before we do the migration. And also about what is the content retention policy, whether we want to, or how far back we want to pull the content from the Drupal 7 site. Do we want to pull content two years back or three years back or? That also depends. So that will also reduce your database size in the new platform to a good extent, and you are kind of actually using this opportunity to clean up the content and not just using it as a migration project. So what we did here is that we categorize the content types. We categorized into majorly two sets, one being content types that fully rely on the body field as the full source of information and just as the title field, as Drupal keeps all the fields.

And another set of content types which has a rich set of diverse fields with different field types. So what we did here was there was like four to five or six content types that add just a title field and a body field. So we merged all those content types in Drupal 9, merged in the sense when we did the migration. We pulled all those content and pushed it into one content type, like for example, basic page in Drupal 9 or something like that. And we do not stop at that. We also created a mapping field that maps which content type these words nearly belong to in Drupal 7. So that is to reduce the number of content types. But at the same time, the editors will know and of course, we can use that field to actually see what content type it belongs to in Drupal 7 and do the necessary designs in the front end and do that mapping between Drupal 7 and Drupal 9 or 10. So that is one thing which we did here. Any questions so far? OK. So this is an example of the table that we used for the content types discovery.

For example, we wrote each content type name and the first question was whether we want to migrate this to Drupal 9 or not. And in this case, it can be Drupal 10 as well. So whether we are using or what are the roles that are using this content? What are the roles that access this content? I will come back to why we are doing this and the usage to which the content type is used as an end user pages or whether it's used as an internal page. So that's the fourth column. How many internal pages this content type has? Like what is the level of the page in the site plan? Is it the second level page or third level page or inner pages? Because Drupal 7 sites, mostly they have been there up for years. There are good chances that there are a lot of pages in our pages that we would not even be showing up in the SEO or will be kind of a dead page like without any links to any main navigation or anything like that. So we have to identify those kind of pages as well and whether those pages belong to a specific content type.

Also, there are good chances that is also possible. So we have to think about all these things and particularly about the roles that have access to this content because let's say that there are two or three roles that the sole purpose of those roles is to access those content types. And we decide that the need not need to have those content types in the news site and they have mostly dead pages. In those cases, we can even think about dropping the roles as well, not just the content type, but also the roles. The only thing is in those cases we have to migrate the users who are in those roles into an authenticated role or a much appropriate role as per their history. And what are the other role combinations that they had in Drupal 7? So that is about how this table allowed us to look at the content types at a very high level. And before we proceed further, we did this study and it helped us to reduce a lot of content types almost from writing. We reduced almost 40 to 50 percentage of the content types from Drupal 7 to Drupal 9.

And yeah, it at least simplifies the information architecture and we are just having what we really need in the news. And yeah, so next we will proceed towards how we, what we did with the modules and taxonomy part of this. So for modules, we used mainly the MoSCoW rules of prioritization. As you can see, we did a table in Excel, and in the sheet, we wrote down the module name. In this particular example, those are core modules. And what are the sub-modules that the module has? And so that we have that visibility of what are we removing or what are we upgrading really, so that if there are any issues we can always go back and see the submodules as well. And what is the description? Any notes or something that we want? And what does the type code contribute to the custom? And where are the configuration tools related to this module? This is important because when doing the. Sorry. When doing the migration you would want to also check whether the configurations migrated correctly or things like that.

So it would be very handy to have the list of configuration pages for each of the modules so that you can do a quick check or if you are deciding to discard a particular module, you can check what configurations are present so that you move that configurations to the new module that is going to replace this one. And whether there is a D9 version available. And we have three columns here following that, which is remove, replace, and upgrade. Remove being that we are going to completely remove this module. It's no longer needed in Drupal 9 or 10. Replace being that we are going to replace this module with a different module and upgrade being there is a version of this particular module available in D9 and we are going to upgrade this. And the finally the most important column was the usage column where we say whether it's a must-have, or it is a should-have, or it is a could-have. So must have is as you can see, must have, are mostly... Must and should have are mostly modules that are in core and contributed modules in the D7 now which are in D7, but now in D9 core.

So you can't avoid those modules. And anyway, you need it. So those are must-have modules. And should-have modules are modules which are contributed modules in Drupal 7 and these contributed modules which are actively used in Drupal 7. So you definitely know that these modules are used. And the challenge which we faced here was that the editors themselves were not, editors and the end users, none of the stakeholders were really sure whether this particular contributed module is currently used or not. And that was another challenge which we dealt with. So we had to discuss a lot. We have to ask more questions. We have to see, understand what the contributor module does and ask questions which are related to that usage specifically, instead of asking a straightforward question whether this contributed module is used. We have to ask questions that will give us clues that they are using the features provided by the contributor modules. So that will help us in gorging or taking a wise decision whether these contributed modules were still being actively used in Drupal 7 or not.

So that is one thing. And there are a lot of contributed modules that would be just enabled in Drupal 7 but not really used. So we have to be very careful when, and it's a tricky thing as well. So that being said, so optional are could-have modules which are like, we know that there are these contributed modules but these are not actively used in Drupal 7 or we are really not sure whether they are used. So those, everything will fall into the could-have category. So what we are doing here is we are actually reducing the number of modules in the site and by doing this exercise we can easily do it because anyway, all these will lead into a lot of discovery effort, but it will be worthwhile because your final site in Drupal 9 and 10 will be much lightweight with less simplified information architecture, a simple list of modules that even the deployment efforts will be really good with the composer just have to installed on your smaller set of problems. And so that is another thing. So you didn't have composer in Drupal 7.

You would also have to include that in Drupal 8, 9, and 8+. So this will also help you in doing that because the list will be much less. So we will now proceed with further roles and permissions. So, there are some concepts that we did related to roles and permissions, some common issues where there were too many roles and duplicate permissions available and the delete permission was given to non-admin roles and people were deleting content as well unknowingly. And that recycled bin, and we will talk about that in Drupal next slides. And another thing was that the content workflow was also not streamlined and things were getting published without reviews as well. And also there were a lot of roles and the name of the roles was not very clear. It was clear to someone who has been in the system for long, it was not clear for new editors or new people who are going to create pages in Drupal 9 and things like that. So these were the issues that we had. I think most of these issues might resonate with what the current users in Drupal 7 might also face.

So how we solved this or what we did here is that we made sure that roles have minimal access, particularly no delete permission given to non-admin roles. Even if delete is given, then something like recycle bin or we instead of delete we do use the workflow content moderation to do an archive workflow. And we also made sure that we have minimal roles so we don't have too many roles. So you will see how we reduced the roles in the next slide. And we also did a lot of user cleanup. First being that like removing all the inactive users and also combining users or that were chances like same person was using different user names and different emails. So that also we validated and things like that. So finally, it also matters whether we are going to do a manual role mapping or we are going to do it via the migration scripts. Manual role mapping is much better if you have a very less number of users after you do the user cleanup and migration scripts are good if you have a good amount of users and you know that these users are going to be mapped to these roles.

And the role mapping between Drupal 7 and Drupal 9 is pretty straightforward. In those cases, migration scripts are good, but still migration scripts are written only for once in these cases, most probably. Only in some cases where we do an incremental migration, we need the migration scripts, so in that case it's fine. But for one-time migrations, I think manual role mapping is better. Making sure because if the users are less particular. Yeah. So what we did with respect to the roles particularly is that this is an example of how we cleaned up the roles. So we use the roles as a combination of content restriction role and a content moderation role. What we mean by a content restriction role is that let's say that the first set of examples gives the existing structure in Drupal 7 and the alternatives gives the new structure in Drupal 9. So what we did, what was in Drupal 7 was like, for example, role A, add create and edit permission for content type A. And there was another role B which add create and edit permission for different content type plus publish.

So it gets a little difficult after this. So that was another role which was having a create and edit for both the content. So and that was another role that was having create and also publish permission for these two content types. So what we did here was in the new platform we created the roles based on the content type. So if you want to access content type A, you will be assigned a particular role, which is role A. If you want to access content type B, you will be assigned role B. And we had a role C, which had published permissions for all the content types. And what we do is for any user, we give a combination of these roles, whether they have access to only these content types but the publish permissions as for the content moderation workflow. So in the content moderation workflow we give the publisher permission only for role C. And let's say that we want to serve the example of role D in the first case, then what we do is we give a user permission or assign them role A, role B, and also role C.

So you are assigning the same user three roles and it works in a good combination with Drupal. Drupal takes care of giving the least permissions as per the combinations. So you can reduce the number of roles. And that's what we did here to a good extent. And all this helps in having your permissions page in Drupal much, much shorter. Otherwise, it was like we have to use the horizontal scroll and it can go for a much, much scroll, keep scrolling the roles. So that's majorly about the roles. And we also used a lot of modules which does a lot. One was permissions by term and which gives you the flexibility to give permissions based on which terms the content belongs to. And we also, we did not use the group module but this is one of the modules that we went with during the discovery. So it gives a much more decentralized control of the site and it's in rather than the admin user having all the access, it splits the... It's good for educational websites and organizations which are educational institutions.

So they need a more decentralized control of the site, and that can be achieved by a group. And there are also another similar module called groups test. So for sites which have a very simple workflow, you can use content moderation and if you have workflow module already used in Drupal 7, it's better to use the same module in Drupal 9. They have a migration path as well. And workbench, workbench moderation, and this sort of workbench modules are good if you want to have a dashboard and email notifications and all the good stuff that you have with workbench are these. So you get these out of the box with workbench. And trash bin was not earlier available, but now it's available in Drupal 9 as well. And there is also something called workflow buttons which also provides this feature of trash bin. When you delete it goes to the trash bin rather than the content being deleted fully. So you don't have to use the archive workflow anymore, you can use the actual trash bin. So yeah. And it also automatically cleans up those content in the projects.

Finally, we went to the media management as well. Like, we had a... There are multiple approaches here whether we want to have the same approach as in Drupal 7 or whether we want to leverage the media module to a good extent or not. And also whether we want to create any custom media types as per the need, alright? So, one thing is that again, we have to ask a lot of questions here, which is like does the Drupal 7 site contain media, which is mostly images alone, or does it contain videos, audio scripts, and different textures, different varieties of media? So if it has a different set of media, then we can move towards using from a normal file field, we can use a media field in Drupal 9 and 10. The advantage of that is that you get to store different types of media in the same field, whereas in Drupal 7 you need to create a separate field for image, separate field for videos and things like that. Whereas using the media encoder, you can have one field which can store different types of media like video, like text, and things like that.

And those are the things that we have to reevaluate when doing the media migration. And we will also touch a little bit on the modules that we use for media. We used File Entity Browser and we also add Media Directories, Bulk Upload. And Media Directories are currently virtual directories and still that's the ticket that that being worked on to make it into a physical directory. And the drag and drop support is now available out of the box for the media library, so you can drag and drop from your system into those sites. And finally, we did a good amount of re-engineering as well. Rre-engineering the sense the goal here was to look at what are the different data types for each field and validate if you are using them effectively. Like, for example, we had a plain text which was storing a date and we had CKEditor which was stored in plain text, and instead of having taxonomy, we had a List(Text) kind of fields. So if certain fields are compatible, even though they are different data types.

So, during the migration, we can see if we can create a different field type that's more appropriate and do the migration accordingly. The benefit here is that you get a much better editorial experience, your storage is optimized, but really because you are avoiding a lot of CKEditor than just using plain text where you need plain text and you have a better user experience as well, particularly for the editors. And also for the users, you get better field for matters which are more appropriate to these field types that suits the data types. Yeah. And what are the other aspects that we consider? We have to consider what are the integrations that are available in the current site, how we are going to achieve the same integrations. And again, if all those integrations are needed in the new site as well, and any field name changes to be done in the content types and or do we need to add any new fields or do we need to change the settings and things like that? And any pre-processing that is needed before, just before dumping the data into the new system.

And the final thing is documentation. So we discussed a lot of things along this path and a lot of things outside of just the developer kind of things rather than just about the custom modules and templates. We discussed a lot of things that can be done and optimized here. But all these things are everything is a decision made and the team that is going to do this migration implement this might not be the same thing. So it's very important that we document why we change the content types or why we chose this particular field type and things like that. So here I'm showing you an example where what kind of documentation we created for a particular content type. So, let's say that it has a content-type title. It has a brief description, it has field-level requirements. What are the fields that are needed for this content types and what are the new fields that are going to be in Drupal 9 rather than what are the fields that was in Drupal 7? What is the content retention policy offered that are going to migrate the content, whether there are any aggregate pages for this content and what are the filters that we want to have in the aggregate pages and things like that?

These things, when we write our own as a document, these are very good things that we can discuss upfront even before the designing phase starts, so that we have good reasoning and we have good amount of information, how we want to display our content as well. And what are the different migration considerations that they want to consider, any processing or anything that they want to do post the migration or before the migration? And what are the assumptions that we have for each content type as well, and any external references other than these? So, yeah, that's it. Thanks for staying. You can go ahead with the questions. One question I have is I would totally if I had (INAUDIBLE). But is it possible to just upgrade from seven to 10? Yes. Yes. Yes. I believe an upgrade path is available directly from Drupal 7 to 10. But I'm almost 80% sure that it's available because the fact that a lot of people are available in Drupal 7 is, and Drupal seven is also a supported version still, so that's the reason we have an upgrade directly from Drupal 7 to 10 as well.

So you do not go to Drupal 9, you can go directly to Drupal 10 as well. And irrespective of whether it's Drupal 9 or 10, these set of exercises are something that will help you in the long run. So, yeah. Did you use any external tool for(INAUDIBLE). Sorry. External tool for migration. Any additional tool. It will... Are there any tools used in the migration exernally? You mean tools, right? Yeah. Yeah. Like Rector. Did you use Rector? Yeah. Yeah. Rector is also available. But in this case, yeah, we used... We usually... It is used mainly to upgrade and do the changes automatically. But here we did the migration via writing the migration scripts that are out of the box tools as well available via Acquia like Acquia Migrate and Migrate Accelerate. But it depends on what is the use case or what is the level of complexity involved in the migration, whether some sites have a straight to like a straight to straight migration mapping like these content types will be almost the same and there will not be much need to change the content types or change the information architecture in the new platform.

In those cases, you can use tools like this to migrate. Drupal Rector does the changes manually, but there are much more advanced tools like Migrate Accelerate and Migrate. Those help you when your migration is straightforward migration and you don't have to change much, you just have to migrate the content. It looks like that's it for questions here in the room. So. Thank you. One more question. Apologies for missing the presentation. I was wondering whether this conversation is about the Backdrop CMS an alternative form of the Drupal 7. Is it about Backdrop CMS? Yes. What is the question again related to Backdrop CMS and Drupal 7? So Backdrop CMS is a form of Drupal, right? Yes. Yeah. We know that (INAUDIBLE) still in Drupal 7 and for some of them, Drupal 10 is not really an affordable alternative. So I was wondering, does your team work with Backdrop CMS offering it as an alternative for those who can't afford Drupal 10 for some reason? We can look at it, but there are a set of... We have not worked much on Backdrop CMS but we can look at migrating that.

So we have to look at, it's a separate distribution by itself, so we have to look at what we can do that in those cases. But I might not have a specific answer why it was not, why we don't have everything ready in the Drupal 10 but that is something which can be done. People want to follow up on this question. What's the best way to follow up on this? With your team. What was the best way to follow up? OK. You can reach out in our website. So, axelerant.com, and we can discuss further. OK, I'll do that. Thank you. Yeah. Well, thank you very much. Thank you. And yeah, let's not forget about the contribution day. OK. Thank you. Thank you.