 All right, I want to, so I am acting as just a proxy. Unfortunately, Kalei could not make it here in person, so he's gonna give the presentation via Zoom. So I'm gonna give it over to him and let him do his presentation of the big lead picking the right Drupal journey. And you are on. Thank you, Sean. Good morning, everybody, and welcome to my session on the big lead, picking the right Drupal journey towards Drupal 10. I am Kalei Chalun. I am Drupal 10. So I work at Axlaren. We are an integrated global delivery partner for agencies and customers that puts talent to employ happiness, engineering excellence, and customer success. So going back into the big lead, so we all know that doing a migration or the transition from Drupal 7 to Drupal 9 plus version is the survey lead. And we also know that as for the latest update, the Drupal 7 end-of-life has also been extended. And it most probably would be extended next year also because they thought that they would be evaluated again in the next year. So considering that the most predominant question that would be in our minds is that should I still migrate to Drupal 7, 8 plus or Drupal 9 plus versions? So the answer is yes, because of a lot of other reasons or benefits that we would get due to the suffering and being in Drupal 7 is more like being in the comfort zone and we'll come out of it. We would not know what Drupal 9 plus versions are to offer for us. And considering that Drupal 10 is also planned by the end of the year, it is good strategy to upgrade to Drupal 9. One of the main reasons being Drupal 8 and Drupal 9 has also extended. So we can upgrade to Drupal 8 and we have to go to Drupal 9 plus and we can also be looking forward for a lot of improvements in Drupal 10 to date of the year. Some of the major things that we would get in Drupal 9 are would be areas like we get better performance due to big pipe catching strategy, remove a lot of Drupal 8 code from Drupal 8 and also a blade of symphony, Drupal 9. And we also get off each other support by the R&B that support their respective services module and we can just stay here to communicate with any management to other apps or any other systems that is not in Drupal. We also get better editorial experience by using CK letters, latest version 5 and also we have ways to integrate the most popular, good and bad editor along with Drupal in Drupal 9 and plus. So we also have better flexibility in managing the MPTs like every MPT or anything that you see in Drupal 8 plus and Drupal 9 and 10 is going to be treated whereas in Drupal 7, not everything was paid so it feels for media user taxonomy and that is really useful for us in a lot of ways and we are also looking for automatic updates strategy strategy initiative by which the update to Drupal 10 is expected to be more seamless and finally we have good accessibility support by mainly due to the Olibro and the Claro teams being made as the default and we have all the alerts in core now in Drupal and also more semantic HTML by elements and contributed modules like CK editor accessibility auditor all in one accessibility long modules like that or also extending the already available accessibility support in Drupal core to the next level that we can really provide a equal platform for it. So I would like to start with the question like what are the aspects you would want to consider when moving from Drupal 7 to Drupal 9? So usually the things that we consider in this case are like the content types the taxonomy and the modules then we also want to think about the goals and the content flow how we want to make these to work together and how are we going to manage the media in the new site and also this is also a good time to do some field re-engineering work we will talk more about what I mean by the re-engineering and that's in that when we arrive there and there are also other aspects which we can consider during this taking this big leap because it is a major change and there are a lot of other aspects also you might want to consider later. So finally we also want to focus on documentation and making the clear on so how we document whatever we decide to do and why what are the reasons behind the decisions that we take. So I would like to start with content types but if there are any questions you can interview me and we also can discuss some of the questions at the end of this class. So first the question for most of the thing that we are more worried about after content types and of course it constitutes the major part of Google and it is also important at this point of time to have it plain slate and to not worry too much about the constraints that we have added in Google 7 because there are a lot of restrictions from a technical level we have in Google 7 so we need to just keep that aside for a moment and believe that anything is possible and by going with the right approach I think anything is definitely possible in Google. So apart from that what we did here in this case was we categorized the content types based on one particular thing which is like whether the content type relies mainly on the body field as its information source or whether it also drives its information from other which other fields it's as well. So for content types that rely heavily on body as the information source what we did was we merged those then we put the basic page content type in Google 9 and also we created a mapping field that also shows all the content types that are in Google 7 so that when the migration happens we have a content we have the mapping about what content type this content belongs to in Google 7 and we also have the body field which has most of the data or all of the data for that particular content. So and for other content types which require a good number of which fields sets we add them as the separate content types and it's also important to consider what content types we can drop if we are not using. So in this case it's important that we ask meaningful questions like like for example are we using all the content types in the first place and are we using all the fields that are present in the content types are these content types mostly shown as aggregate form aggregate pages or whether they are shown in a full view on a single page or what is the form mostly view format for this content type and are there any changes that we need to make in the VAD want to store data like field level changes particularly also if we want to migrate all the data from the server and all that we want to impact some data so we have to decide on the content with retention policy also and also can we change some data during the migration like do some pre-processing before we migrate the data to Google time. So these are some of the questions that we can ask around the content type structure, fields and this usage in the current site. So I just want to show this table which we used for when we used to analyze how we can understand the content type in a much more detailed manner. So we created a table for each content type that we noted the content type name that we want to migrate this to be then. That's the most important question that we need to ask we should not assume that everything that is in Google 7 needs to go to Google 9. There's no R and fast rule like that. So we want to understand the importance of the business importance of the site whether the usage of the content type and a lot of factors and we also want to know what rules use this content type so let's say that we are deciding to drop this content type then the rule using that content type might also become unselling in that case. So and we want to understand where this content type is used whether it's used as end user pages or we are just adding that content type or supporting data that can be shown in other content types and things like that and also even if you are showing it to the end user whether it is internal page or whether it's a fast level page alone or fast level in the sense in the site map let's say that this content type is mostly coming in the fast level then it means that it's the most important content type or whether it's coming fourth level or fourth level or SEO purposes it's recommended that we do not make the user navigate more than three levels so at least we need to make sure that we are not migrating content types that are at a very deeper level and not even visited by the user frequently in the existing site so these are some of the things which we can check to validate whether we want to migrate this particular content type and to what extent we want to migrate so these are the different aspects which we want to consider for the content types any questions or no questions so we can now proceed towards the next topic which is about the modules and the facts on so in this in this topic what we did specifically to modules was that we categorized the modules based on master rules of prioritization where we categorized them into required and like the kind of optional modules in the required modules we further divided them into must have modules and should have modules the must have modules are of course the core and the contributed modules in Drupal 7 which are now in Drupal 9 core and the other set of modules which are should have modules are modules which are actively used in the contributed modules as contributed modules in Drupal 7 but we also want to use those modules in Drupal 9 because they are very really dependent on in the Drupal 7 set so for each of these modules it is important that we did a similar analysis like shown in this diagram like we wrote about each module one of the sub modules that are present what are the configurations that are present and better we want to remove the base of upgrade the module and the main another point I want to highlight is the new stage column which kind of shows whether em, s, w or c which stands for must have, should have, should have or won't have so we categorize the modules in this way so that we know that these are the modules that we need to first install to the side like the must have on the should have modules and could have modules are something that we need not install immediately but it might be needed later on so there are a lot of scenarios when we develop the Drupal 7 side we might have found a lot of utility modules that might be needed at that point of time but later on it is not actually needed so we can actually uninstall those modules but we would not have done it in Drupal 7 so it is important we do this validation during this move so that we are not just adding the modules blindly just because it was to add in Drupal 7 but we really evaluate its need in the new side and we reduce the size or the number of modules because this will help us in the maintainability of the site in the long run and it is also less prone to vulnerabilities due to this so this is one major aspect that we want to consider when considering the modules and also we want to reduce the taxonomy so we found that we need some new taxonomies that are needed to better categorize some of the areas on the side and also we have to change we have to change some of the way we categorize the existing content by changing the taxonomy name or adding more things to the taxonomy and things like that because we could not add things to taxonomy obviously in Drupal 7 and it was not important and these are things we can leverage these teachers in Drupal 98 plus versions so moving on to roles and permissions so regarding roles and permissions there are a lot of aspects that we want to consider starting with we have given very minimal access to roles because during the course of time as and when we add more users we tend to give a standard set of permissions to the roles which kind of creates a lot of roles also we will see an example in the next slide on how we can optimize the number of roles and also that's why it's important that we have minimal roles in the side and it's also a good chance to do a user cleanup because we may not migrate all the users that are in Drupal 7 for example a lot of users we found were locked or they are not anymore active in the side so we can just migrate the users who are active in the Drupal 7 side and we can just focus on those users so if you consider that the number would be pretty significantly less than the total number of users and that also reduces the migration time and one last aspect we would want to consider is that whether we want to do manual role mapping for these users or whether we want to do migration scripts migration scripts in the sense whether we want to write the migration scripts to do the mapping of roles for these users considering this is a one time activity most of the cases when we migrate data from Drupal 7 to Drupal 9 we just want to do manual mapping because we don't want to spend a lot of development therefore then writing the migration script for just a one time activity so this is also one thing which we can consider and these are the common issues I have also shown the common issues we have faced in this migration and it might resonate with the issues that we are also facing which are like too many roles and duplicate permissions available and the delete permission has been given to not as many roles and the content also might not be that clear or the reviewers are not or sometimes if the content bypasses the reviewers and gets published because published access is given to roles that are not supposed to have access and also there are very minor changes that might need to be done through roles like creating the roles for the administrators so these are the various things that we want to consider about the roles and permissions so let me proceed to an example so this is an example of how we can use roles and content workflow in conjunction with each other so that they give us the optimal or minimal number of roles so because it's very important how we use the roles to achieve the content workflow we want so we can say like clean roles is content restriction it is a combination of content restriction role on a content moderation role so let's see with an example and an alternative solution so in this example let's say that we have four roles and with role A having access to create and edit content IPA and role B has access to create and edit content IP and also publish content IP role C has access to create edit content type both A and B but they don't have access to publish content any of the content types role B has create A and B content types and also publish it so role B has access to do all the operations so what we can see here is that as we add more users we need to create roles that exactly match what the users want to which is like adding more permissions to these roles and what that creates is the number of roles so the number of roles gets increased and the people page becomes really wide with a lot of roles and it's very difficult to even see what function is there and which roles are in those functions so the alternative to this is that we can create roles that are restricted to certain content types so as soon as we create content types which will be relatively limited to the number of users or less than the number of users we can create roles which have access to create and edit those specific content types and we can also create roles that are very content or content workflow or content moderation specific like these certain roles can only do publish permissions or to be exact only one role should be able to do publishing so what we can do now is that as and when the users get added we can create combination of these roles so that it fits the users requirements so that we can give the user role A and role C if they want to create, edit and publish content IPA and similarly if they want to do everything we can give them all the roles role A, B, C to the user and Drupal works that way in a really good manner and this is how we can reduce the number of roles that are restricted to Drupal 7 and this is one good exercise which we can do though it still takes a lot of time when doing this exercise it actually reduces the number of roles that we have in the Drupal 9 site and it is a big release for the administrator also so that we also need to drain the administrator out to assign the roles to any user based on these combinations that he has so this is one good approach which we have done and it has been working good so this is something which I want to highlight so proceeding further we want to be also mindful of how we choose the modules or what are the modules that we choose we have came across these different modules when we did this and this is like so let's say for example you are categorizing your content based on taxonomy terms and a lot of things are proved based on taxonomy terms then you can use permissions by term module to give access to specific content that are tagged in these terms so this module does that very good and this is something that we have used and if you want to decentralize the admin or not give that to one role like administrator or user one role alone and you want to decentralize the power of publishing and editing content based on the various sections of the site or various content types in the site then you can use to do the module and it's very stable in group of nine and I am believing that we will obtain version so if you are using sites with a very simple workflow not that much complicated workflow then we can use content moderation which is available in core in group of nine and we can use workflow module if we have already used the workflow module in group of seven that is a migration path available we can use that this is of course different from the workflows model that is that are in group of four itself so and if there is a need for to have a dashboard and to send email notifications whenever content is waiting for your review show what are the content that is that needs to be reviewed by a particular person in those cases if there are requirements like that then we can use the work bench suit which consists of work bench work bench moderation and work achieve and finally so one one thing which we have noted that is that there is no trash bin or recycle bin in group of nine it was available in group of seven so an alternative to that would be using the archive content transition in content moderation or there is a module called node revision which kind of runs a cron job to iteratively delete very old revisions which you can set like from this time frame I want to delete these revisions which are which I consider to be old so you can these are alternative to trash bin in group of nine but there is not a same exact trash bin that we have in group of seven in group that is an opportunity for contribution there is so and yeah so that's all about rules and permissions and if there are no questions I can proceed with media management. Questions? Okay thank you so going with media management so media is one of the most important aspects that we want to handle in any in any group of website because it drives the traffic and also there are certain certain business needs to have a rich in media or some websites might not focus much on media they want to they might have actual content more they want to show actual content or some sites might be very specific in what kind of media they want to show like whether they want to show videos specifically or some sites might contain a lot of audio files and that is the least important maybe site to site so it's first important that we check these things analyze what are the requirements or business needs to how we want to store the media and what is the future scope of media in the site also like I said so some sites want to be rich in media and some sites would want to be mostly textual so there is no need we need to identify what is the future scope of media in the site and whether we want to be media rich or not and finally we also want to check whether we can use the same field to store different types of media like whether we want to have a single field to store images audio files videos and things like that or whether we want to have separate fields so based on this there are three options that we have which is having fields for each media type separately like it was in Drupal 7 and we can have single field by other media model and the user can be allowed to upload different types of media at the same field so this will reduce the number of fields that is there in Drupal 7 and also finally we can also create our own custom media by adding our own metadata and fields to that particular media type so this way we can leverage the fieldable properties of media also so these are the various aspects that we want to consider when doing the media migration and how we want to manage the media in the Drupal 9 set so again I also wanted to highlight some models which which were very useful or we came across when we migrated the media so let's say that you are using simple image or video file field path in this case this is a single field that just stores a simple image of Drupal and on these cases file entity browser is a good module that can be used to browse the media but is an equivalent alternative to media browser in media module so if let's say that you go to the route of using the media module in board itself then in that case we have the media characters module and also bulk upload module to upload a lot of media and also browse the media in a very editorial and the media one thing to note about the media directories module is that it provides only virtual directories and they are working on doing it as actual physical mapping to actual directories in the file system so the community is working on the same to map it to actual physical directories and finally there is also drag and drop support available in the directories module which you can drag and drop your files there into drop space in the media for the particular media field type going forward we will now discuss on what kind of field re-engineering can be done during this while we are taking this big leap from Drupal 7 to Drupal 9 so the goal here is to re-look the data types of each field and validate whether we justify those data types and the data currently present for those data types for examples of this is there are a lot of cases where we use plain text instead of dead field, CK editor instead of plain text we have a CK editor in Drupal 7 where we just give one or two words we don't have CK editor kind of for this week and we also use this text instead of text on the tabs so these are some examples of how we can change it since the field types so that it is very easy for the editor and we also review the database for the editor they wrote us to scroll through very big node editor node ad screen and they are so under edit page that page becomes very very clear for the editors as well and also that is better user experience also because on the fact we use exactly the fields that we need to use for these specific field types and as we get the proper parameters for those field types so we can render those fields in a really good way so this is why it is important that we do the field engineering work and maybe all the field types when we do this migration from group 7 to group 7 so we will now look at what are the other aspects that you can consider apart from all these things that we have seen now is that so we can look what are the integrations that are available for us in the group 7 like for example search, solar search integrations or the social media integrations and any third party integrations that we have done for 7 we also need to migrate them or migrate that data and integrations to group 9 as well and we can ask some questions like are there do we need all the things whether can we represent these fields in a much better way like changing these field types and also whether we want to change any properties of these fields like default values whether we want to change the required properties of these field types and things like that and finally we need to also consider whether we need to do some pre-processing as part of the migration because we are migrating a huge amount of data now it would be much sensible to do some pre-processing in a very automated way by using the migration scripts rather than doing them manually for all the content difficult and almost impossible when the content size is very large for your site so these are the various aspects that we want to consider apart from the topics that we discussed so far when doing this migration so finally we come to what are the next steps that we want to do after we have done this the one main thing is documentation we must document the above aspects very clearly as it says the decisions made and what are the routes that we have taken and why we made these decisions so because it will bring clarity to the development teams that is going to actually implement all these and do the migration from Google 7 to Google and also what to document so it's important we document every decision that we make and why is behind the decision so that it makes sense for the team when they actually work on it and they can take if they want to change some decision then they can take a sensible call so I want to end with an example here on how we did a documentation for every content type that we live so in this case for every content type we add a brief description that says what the content type is what is the purpose of the content type and what the content type aims to solve and also what are the field level requirements of the content type that we documented each and every field that is available in Google 7 and what are the equivalent fields in Google 9 whether it will be the same field or whether we are dropping a particular field or whether we are going to reliant the field and things like that and also it's important to note down the discussions that happened as comments in the same we created Excel or British for this and it's also important to note down those comments or discussions that happened around these fields so that we add the history of what are the decisions made for MVP and we also need to consider the content retention for this field like we discussed whether we want to migrate every week all the content for this content type or only some content for this world or two years back and also we also documented what are the aggregation pages how the aggregate pages will look what are the sorting types that will be in the aggregate pages and things like that and what would be the default sort to that level of detail we documented everything during the discovery phase of the project and we also documented what are the variations that will be available and how they can drill down in these aggregate pages to see multiple results so the full view design or the full view page of this particular content type will go the designs of this particular content type for full view and what fields we want to show maybe we want to add some things which are there in the content type and not shown in the full view things like that we note down all those influences here and finally what are the migration considerations that we want to do for example whether we want to discuss our inconditions that we want to add while doing the migration and things like that and mainly we want to also document what are the assumptions we made while doing all this so that it justifies the decisions that we take and whether the team can also validate whether the assumption has gone wrong or the assumption has changed now so that they can take a better decision in future and finally we also need to build the references or what are the different references that we use to arrive at these decisions and what references the team would be helpful for the team with respect to this content type it can be external or internal these are the various aspects that we consider when documenting something about the content type so similarly we documented the media approach and the topics that we discussed every topic we documented in our documentation space and we use what are the documentation space that we are using but it is important that we document all of these so that we have a clear background of what we do and we don't go pushing the analysis this is great background on planning for this stuff I'm kind of wondering what the next step is are there tools available that help migrate content types great so the question was this is great for planning but are there tools that can actually handle the migration piece for the content content types sorry so there are tools in the sense there are tools like migrate plus or modules like migrate plus and modules that support the migration but one point to note here is that it doesn't provide for people or non-developers it doesn't provide a perfect UI for you to map the content types and migrate but it provides such a migrate interface where you can migrate you can just map the fields in Drupal 700 map the fields in Drupal 9 and just on the tip of a button we will do the migration but another thing that is not available in Drupal by default but one thing to note is that migration requires writing some migration scripts but it is very straightforward if the migration is one-to-one mapping for the fields from Drupal from source to destination site but mostly in real-time use cases it is very rare that we get that straightforward migration where you just need to map the fields from source to destination mostly it will be like we have to do some mapping we have to do some processing and post-processing so that's where Drupal comes here into picture and that's why it's important that we write these migration scripts so that we can actually see whether we want to change something but to answer your question a kind of a ready-made Drupal button module is not available in Drupal itself but there are supporting modules like Migrate Plus which is also available in Drupal 4 which we can use to migrate simple sites which have a straight forward use cases for migration to help answer your question now, migrate and migrate plus are used for migrating content unlike if you have a Drupal 7 site with 10 content types and each of those has 20 fields do you recreate all that in Drupal 9 like manually or is there any way to help that process along? yeah so the were you able to hear that? yes yeah I got it so you're asking about how we migrate the configuration first before we migrate the so for that there are some modules like node export or I mean node export, config export we don't have that's a major disadvantage in Drupal 7 because we don't have configuration export but what we did here in this case I can tell you what we did here is because we evaluated each and every content type so and also the fields so it was okay for us to create these content types and fields manually because we wanted to validate the field types and everything so we did not use a tool here we rather did it manually because we validated a lot of things like we discussed now so in this case we did it manually only so as far as I am aware there are for configurations I have to check but as far as I am aware I don't think there is an automated way of moving those content types to the line thank you but just one thing to highlight sorry one thing to highlight there is that we can do that automated way if we don't have any changes to make in the content type but if we want to re-evaluate the content type and fields I would suggest we do it manually though it's a one time effort it's a huge amount of one time effort but still in the long run it will be beneficial for us so that because we have minimal content types minimal fields in a more optimized way than inside any other questions there are no other questions we are all set did you have anything else you wanted to contribute before we end I just want to say thank you for giving me this opportunity and thank you for accepting me with virtually thank you thank you