 Hello, and welcome to Drashi Rocketfuel for any Drupal project. My name is Anna Hilova and I will be leading this presentation today. This presentation was originally meant to be presented live at Drupal Comportland on April 25, 28, 2022. However, unfortunately, I wasn't able to make it to Portland, so I decided to record it for you to still be able to enjoy it. So let's dive in. As I said, let's tell a little bit about myself. My name is Anna Hilova. I'm a director of technology at Kalamuna. I'm also a Drupal 7, 8, and 9 Acre triple certified expert. And if I'm not at my computer, I like to be hiking, be in nature and enjoy the outdoors and also play and spend time with my dog. So Kalamuna is currently hiring. We are hiring for multiple positions of developers and project managers and account managers, so if you're interested in changing your new adventure, career adventure, apply at our website to check out open positions. They are very friendly bunch of people and we are always happy to welcome somebody to our great community. So what will we cover today? Well, first, we will understand different groups of Dretsch commands and when to use each of them. We'll just scratch surface about them, but I encourage you to look deeper into the Dretsch documentation and official list of commands. We will learn how to create your own commands, learn how to use Dretsch generators and generate commonly used code, as well as how to write your custom generators. So we have a lot of things to cover today. Without further ado, let's get started. First and foremost, let's enter the use Dretsch and what it means. Also, what is Dretsch? Well, Dretsch is Drupal shell. Dretsch is a PHP application that rounds in your terminal and allows you to interact with one or more Drupal projects. Dretsch core ships these commands for performing various common tasks like clearing the cache, running database updates and managing configuration. It also provides activities for executing SQL queries and migrations and for generating scaffolding code that's frequently used Drupal core in APIs. So it also allows you to effectively integrate Drupal into CI CD workflows, and it's a huge lifesaver for DevOps teams developers and they do this like... There are multiple different groups of Dretsch commands, a little touch-based on some of them today, but not all of them. Just the ones that are the most commonly used, or I find the most commonly used in my day-to-day workflow as a full-stack developer. So first, the group of commands which is kind of an essential baseline commands is set management tasks. First and foremost, the one that I use a lot is Dretsch status. And Dretsch status commands gives you an overview of your site house, similar to the Drupal status administrative report. However, it doesn't return all of the requirements. So if you want full list of requirements that everything that Dretsch status or administrative page returns, you may want to run Dretsch requirements. The next ones are database management, database management commands. Update database status allows you to check if there are any updates that need to be applied to your website, and update database to follow those outstanding updates. One of the most common commands that everybody will learn to use almost on the first day with Drupal is cache-clear or cache-review. It rebuilds Drupal registry and clears Drupal render cache and clears Drupal internal cache. So when it does cache-clear on Drupal, you can also run core Chrome command to execute Chrome tasks. It's very useful if you're planning to debug Chrome or see what's running or what output Chrome creates when running on your website. So if you see that your Chrome jobs are failing, you may want to run them through Dretsch to see if you get any additional outputs that helps you debug the job. And one of the other very useful commands in Dretsch ULINE or Dretsch user login that allows you to login as any user, very useful on your local so that you don't have to maintain the password to remember the password calls. The next group of commands is project management commands. Dretsch allows you to manage projects or modules, themes, extensions on your website. Drupal website comes with many projects like modules and themes. Dretsch comes with a group of commands that aid in management projects from the common line so that you don't have to use the UI. These commands can check which modules are present on the site code base, report their security status, enable them, uninstall them and present any additional related to them metadata. One of the most common commands in the PM group is PM list. Shows the list of all available modules. PM enable allows you to enable one or more modules. PM security checks Drupal composite packages for pending security and PM security PHP checks non-Drupal packages like dependencies that are in vendor folder for pending security updates. PM uninstall and installs one or more modules and independent modules. With this group of commands you can manage your modules and themes from the common line without the need of UI. The next group is development tasks. Development tasks is one of the most popular one within the developers and there are so many different modules that provide additional commands. I group them in the ones that are I use the most often. However, your list of development tasks may grow or differ from myself and that's what they provide. I list separated them in the following groups. Q, search API commands, configuration management commands, use related commands and database management commands. Let's dive into the Q. You never use Qs in your Drupal development. You are missing out on an ability to bunch together multiple different repeatable tasks and execute the amount of majority of nodes. For example, bulk import something, publish, promote to the front page, change the status of author or do pretty much anything you want in batches. Q list allows you to see all of the Qs on the website. Q run allows you to run specific Q and it also takes options in terms of play how long the run should be or amount of items to take and Q delete allows you to delete the entire items of the Q. Why would this be useful? Well, most of the time it would be for debugging. Even if you're not building custom import and migrations, the Qs API might be useful if you're debugging your purge. Sometimes Qs are getting hooked up because of a huge amount of items on your website. For instance, maybe the server isn't able to process all of the items since the time that is provided by the Chrome run. And the things being hooked up on link check or search indexing all on the other different tasks that I'm using on the purge, for instance, for your cache. In order to unplug things, you might want to run Q delete and delete the items in the Q and after that, you can actually continue debugging. So very useful toolset there are not only for your personal development on a day-to-day but also for debugging other modules that you're using to use API. Search API tasks. Search API is one of the most popular search frameworks for Drupal 8 and 9. And it provides additional tasks in order to see the statuses and manipulate indexes through UI. There are more comments, but again, I just listed the ones that I use all the time. You might have been in situations if you use Search API in Solar where you know that different indexing tasks may take quite a while because if you're doing it through UI and your site is quite big, it may take a while to process it all and you might be sitting and watching that batch alteration going forever. So running this task through UI helps because it is faster than a browser response and it also allows you to see any additional debugging information might be actually hidden while you're watching the batch process. So first command is Search API status. It allows you to get the status of Search API indexes on the site. Search API index allows you to actually index all an indexed items. And Search API re-index allows you to mark all of the items for re-indexing without the loss of data. Search API clear allows you to index data and mark items for re-indexing and clear all the index data that was cleared before. It wasn't cleared before. Use tasks. Well, use tasks comes with multiple commands. The ones that I use, I use mostly for debugging and additional development. When would you use it? Well, if you're using a preprocess or outer hooks and you don't remember machine names of your views and displays, you can use your list to get a list of all views on the site. You can also execute a specific view with the name and display. And I'll put it in the comments line. Why would this be useful? Well, that's very useful for debugging on the production environments when views are modulated or not be available. So that's when I use it. I also use it when I'm writing the custom modules as an outer hook and I want to see the list of them without going to the UI and looking for machine names there. So why would this be useful for internal development tasks? The next set of commands is database management. I'm sure we all ran SQL dump at least once, especially with this option, SQL dump result file that allows you to dump the database into file. Very useful if you're not able to SSH into database management utility and you can actually dump the external database into file and then download it to your local machine. SQL drop allows you to drop current database. Please don't use it on production, but on your local, especially if you're writing and dividing migrations may be very, very useful if you abort the database during the past migration. And SQL CLI from the file allows you to import the database from the file. So the set of these three commands allows you to essentially manipulate the database without the need of database management utility. Which is great. The next set is configuration management. This is one of the most simple commands and also the one that we use the most often. Configuration status allows you to check the status of configuration on your site. Configuration import allows to import the configuration and export allows to export it. So the favorite CIX recommends that we use all the time during the deployment. The importance of those commands is also in the CICD workflow. If you're doing deployments and tests through the GitHub actions pipeline, Acquire Pipelines or maybe SQL CLI or other CLI utility you may heavily utilize these commands to also import expert configuration after the code deployment so that you don't have to do it manually. It's very useful and make it easier on developers when they're doing frequent deployments and urgent pull requests. Well, we just reviewed briefly all of the most commonly used dredge commands that I frequently use. You may have differences in your toolset so feel free to figure out your own list of common commands that will be useful for you. And also, as I mentioned, I encourage you to dive deeper into the dredge documentation to look at all of the possible commands. All concrete modules also provide additional commands that might be of use of interest. So if you are looking for a list of those commands, I recommend you to browse through the module and see what commands they might be providing. However, what would you do if you don't find the commands that you need and no concrete module provides the commands that you need? Well, you would write your own and the next section of our presentation would be devoted to the custom dredge commands. So first of all, let's dive into the type of those commands. There are three major types of dredge commands. The ones that live in the custom module and relate to the custom module's functionality. Those are the most common ones and the majority of custom dredge commands would be of those type. There are also type-wide dredge commands that are not project-specific, but they actually live and applicable for the entire site. State-wide commands are usually generators because they can generate code that is applicable site-wide and not for a specific project. And global commands. So global commands are not quite a tiny Drupal installation, but instead they install globally and available anywhere regardless of the presence of Drupal. It's similar to other command-line applications like Git or Faking Terminals. These commands are not supported by default and developers need to make special configuration inside the address.pml file that is in the root dredge folder in order for dredge to pick up those commands. And they are not going to be focusing on site-wide commands, the global commands today, but we will focus a little bit more on the custom module ones and write a very, very simple one, just as an example. But first, let's look into dredge anatomy. Every command will require certain parts to be present before it can be executed. But first every command will need a dredge command file. It doesn't have to be a file per command. There is a command file in your modules that comes to a multiple dredge commands. Every command will need its own annotation. That is how Drupal and dredge will learn about the dredge in order to interpret where it belongs to, how to call it, what parameters and options it takes. And command methods. This is a method that actually holds the logic of the command and what the command node needs to return. And the services.yaml file inside your module that describes that command relationship as a service. And then the composition file in your module. In order to show you how to make one, I recommend us to dive into code. I will be showing it inside the kalamuna.com website in my local but that can work in any application on your local environment. Or in a hosting if you can manipulate dredge in your hosting can deploy the files this github.spt. So in order to start dredge command, I recommend that you use a generator. A generator is, it's something that allows you to generate commonly used snippets of code. And but in drash9 we got a new generator command in drash. Prior to that we had the same generators in Drupal console that after drash9 actually became less popular and I personally prefer code generated with drash. And I use drash generator often when I need to generate something that is repeatable but is requiring a lot of moving parts. So like in this case a command file and an annotation and method and service and JSON file all of that kind of creates complexity to multiple pieces and I don't want to keep track of them. So I don't be using a generator, you can definitely create all of that manually but generator just makes it easier. So let's go down there, open the comment line and I'm currently in the kalamunna.com website and I would run drashGenerate. The drashGenerate command allows you to see all generators from the website. Here we go. If you scroll a little bit up into the drash category you see that there is drash command file copies this and then run drashGenerate drash command file. And we'll answer a couple questions like it asks you if it's a machine to provide machine module name. So machine module name you can provide an already existing module. For instance if you already have a custom module that you may then want to add drash command to it you would type that if you want to create a new module you can type that. I will type in the new module right now and I'm actually not going to be using it because I don't want you to watch me type but I will be using a different module that I generated prior to this presentation however I'll walk you through the process of creating an absolutely new one. So you'll call it drash underscore test and you see that I actually type drash custom for this presentation before. So drash test and then it asks you for the actual module name of human readable one so we'll call it drash test. Then it's asking you for watching we are not doing reporting we are not doing any reporting we are actually making an absolutely brand new Drupal 9 drash9 command so we will skip that question and it immediately opened up a drash9 file for myself which is very useful. We will close that and I will actually go and show you in the website that is kalamuno.com website I will show you what it generated so if you go into modules and into custom you can see that I have drash test modules that we just created Compositation it created drash services YAML file and down there in the command directory created drash test command file so that's a command file. Awesome what you will notice it didn't create as an info file that you can create as a manually or you can always use a generator to generate an info file because I said I don't want to show you typing so I will be using the modules that I generated right before the presentation that's called drash custom it's exactly like this one but I updated certain parameters so that I can show you a bit of example so let's close drash test and look into drash custom as I said previously we will need multiple things for the drash command first would be a custom commands file we will dive into it in a second and then we will need to compose the json file inside your module and the services so first and foremost let's look in the Composer json file in the Composer json file you can notice that all we have are just a standard Composer file for the module project and you'll notice that we also have extra key and a relationship to the services so you have drash services and then we have drash services yaml and it tells you the version of the drash that helps because it allows Drupal to find the services file later on so after that we need to look into the services file into the services file we have a standard declaration of the services so you probably noticed before if you wrote any services in Drupal you would have your module services yaml in this case since it's drash specific service we have drash services yaml but the structure of it is exactly the same as any services file in Drupal first you have your services key then you have name of your module command and then it needs to point to the class of your commands or specifically to that commands files that I mentioned and then it acts it needs to be drash command so that is all correctly generated for you by the generator and you don't need to worry about the composer file or the services yaml file it's all good the next one if you use it generated don't forget to create the info yaml file I created in here then it's just a standard module yaml file like drash custom is in module name the type of module description core version of the department and in fact I just just a standard info yaml file for Drupal you can create it manually or again run the generator to generate just an info yaml file but without that module you won't be able to install without this file you won't be able to install the module so I urge you to make sure that the file is in place and then the most important thing is drash custom commands you also noted that it already created the right hierarchy of directories for you which is very important and useful because sometimes it might be tedious to keep creating those directories and placing files in so drash custom commands down here what we need to update everything else is pretty good but all we will need to update is an annotation and a command and a command logic command method okay so in here in the command above the command method we have an annotation this is a little bit different from the original one and I will show you what it comes with so you can see that it comes with pretty good defined annotation which has the description and some parameters option definitions usage and a command key and aliases but that's about it let's go back to the ones that I updated so down here you can see that I updated this line with what the command will be doing I will be passing in our command that we are writing today we will be getting returning all of the terms of a specific vocabulary so we will be passing a vocabulary to our custom drash command and it will return all of the terms and IDs and names that are present there so we will need the parameter of vocabulary and it will be a string I also want to process our results and I will put them as a table so there are a couple special parameters over here field labels creating header of the table so we will have a field key ID and there is a key name the heading will be term name and then we also have default fields ID and name that is useful if you want to specify some possible fields that you want to skip in your command we are not going to modify it today but just an option and then we also have usage key that will show the health facts for users when they see the list of commands so it helps to understand how to use the command so in our case we say that you can use a type in drash custom that terms in passing in a vocabulary and then this is actually a command key that allows you to specify how to call the command so this one shows the health facts for the user but that is the one that actually shows how to call the command so we will call it drash custom that term and that is the command name and actually I need to rename it to be get from here awesome and then alias is specified alias for the command so you probably not just like drasy expert in the configuration you don't need to type like config expert you can actually do cf so that would be the alias and we specify alias for all commands as get term and we want to return the role of field so at that table in the command line so that's why I'm specifying this consideration role of fields class you'll have to there are so many different ways of returning data out of drash commands I just thought that would be a nicer output format and then there is this that is basically the default generated table output from if you don't need it so but that's what an example from the generator so a very nice one you really have to have it so we can actually delete it, the command is without but it doesn't really have to in some sense so we can just keep it alright you can delete it later in your real application now in the logic of the command all we need to do as I said it's a very simple command just a demonstration, we need to get all of the terms based on a special vocabulary so I'm using this if you really write it for real like for your actual project and planning to keep it I would recommend to go with the construct and create and do dependency injection but since that is just for them and I'm not planning to use it because it's a static entity type manager here that allows me to get the storage of oxon in the term and load the three basements of vocabulary and I only need term, id and name so I don't need to load actual entities I just do the slight weight load tree then I have an array of rows and they circle through my terms and I add the keys that are specified over here id and name and I add them to the term id and term name and that's it, after that I just return row of fields and I return rows alright, that's good once you've done that you need to enable your module, mine is already enabled but you can enable your module by drash, enable drash underscore custom fy, all you can do drash-pm enabled but this is an alias for the fym enabled so you will use that it will tell me that it's already enabled yes and then you need to clear drash cache so you do drash cc drash and by the way you see that I put d, it's just an alias in my terminal so I don't need to type drash all the time drash-cc drash allows to clear drash cache and when you're clearing the drash cache this is when you register the new drash command and then you do drash get that's the command that they just wrote and then we need to pass a vocabulary I know that in my website I have a vocabulary of topics those are topics for our blogs so I will just do that and you can see it returned to us a table a pretty table of topics with IDs and term name it's very easy so that's how you will be able to create your custom drash command again, what you will need in the command file is a correct annotation there is a command property alias's property is optional and then any parameters you want and the usage one allows you to put health tags and show it to the user and then you also need update logical here command and return the result as well as specify drash services, YAML and composite JSON but as I mentioned, if you're using drash generator that is very easy to do and you don't have to worry about making correctly all the classes so I highly recommend if you start with your drash command do it through the generator because it's just easier all right that was about the drash commands since we tried to base from the generator let's dive into that so there are a lot of available generators that came with drash 9 before drash 9 there were no generators in drash but as I mentioned they were in Drupal console project the Drupal console still can be used and it's often referenced in tutorials about Drupal but I prefer to generate the code by drash at this point because it seems to be the way forward to see all available generator options as we already saw you need to run drash generate command in the command line and you will be able to see all of the different generators generators can be provided in drash core and generators can be provided by modules a generated command is responsible for one slide fault that describes the right column of the output so in the core we have available generators like global, they can be used in multiple contexts in Drupal project drash specific generators we just used one for the drash command form, form-related generators modules are folding plugins like bloat plugins use migration sounds for so-called types of plugins services, scopefold for services classes tests, scopefolds for the test classes same scopefolding in yaml files like info yaml file and so on and so forth so let's run the drash generate and look at them again so this right column actually tells you what the generators are about and they all grouped into different groups as I showed you and there's literally everything you can imagine under the sun and speaking of info yaml file for the modules so this is for the team, there is also module in info yaml that you can use and generate and just answer the question area and then generate the code for you which is very useful and very straightforward, if you use the module development to send a lot of maybe very good starting point for yourself all right so let me show you how to create your own generator to create your own generator you probably need to put it into the outside generator folder it depends on what type of a file you want to generate but I would like to generate custom settings local PHP file you know the different agencies and different developers put different things in the second local file like kint specific settings, browser settings email routing you know mail services caching all of the different things sometimes different people prefer different things example files that is coming to the local core doesn't always fit the needs and it's always annoying to copy paste so having a generator in your website or in your boilerplate for your website project helps so that you can commit that and to give your teammate this file and you can just get it into your folder right out of the bed so it's very useful very easy I recommend doing it like that it's also useful for development services you know they separate from what core provides maybe special robots txt needs or anything like that that you find repeatedly changing in your Drupal projects may be useful to put into the generator so let's start with looking back into our code so I don't be showing what what it is but yeah let me look into it for you so in here we have a draft folder that you can create in the root of your website and it needs to be next to this directory that you're using for your Drupal site so like core is inside that directory you create draft and then you need a capital letter generator folder and inside there you will need a generator class so we have second local generator PHP over here and that is basically a generator class in a generator class it will be an extended basic generator and first thing that you need is a name of the generator so it's a name except almost like an annotation it tells the generate command of how to call the generator so we will be calling it as settings local custom the description will be generate cost time settings file and then a alias would be settings local PHP not just for the alias and then the knowledge where to put it so usually settings local PHP leaves in the science default folder so that's where we put it and then template class is the same as the generated directory that's what we said the generator needs an interact method is input and output interface first you need to specify amount of questions or questions that you will ask in order to determine certain options for the generator we will be asking for database name database password and database username for those are the questions you get then we gather these questions when it dates them and after that we will add a file settings local PHP in the science default and it template that we will be using for it is the settings local dot B so we mentioned that this template will leave next to the generator file so that's where I created it and I literally just copy pasted the entire settings local PHP that I typically use for my local development so only difference you notice that in the databases are in here I am placing the tweet variable DB name DB password and DB username the names of this variable match the keys that they used in my questions now is that all we need to do after that is run drash cc drash alright and then after that's done we can do drash generate in our settings file you can see settings local custom that's the one that we created for ourselves and then copy set and do drash generate and paste so let's do drash generate settings local custom I run it and it has because it has a base name so it will call it kcom and then the password 1, 2, 3, 4, those are not real passwords and the username passed then it detected that it wants me to regenerate settings local file because for it exists I don't really want to regenerate mine so I will do but if you want a new one then you press yes and it will generate the settings local file in the correct folder alright and that was all that I wanted to talk to you today if you have any questions or comments or concerns please feel free to reach me on twitter at signinginotic I am also in Drupal and on Drupal org so feel free to fill us there or visit us and send us a contact form information at kalamundo.com thanks so much for watching and I hope you enjoy the presentation let's keep in touch and I hope you had a fantastic Drupal con so sad that I wasn't able to make there in person but hopefully next year thanks so much and have a great Drupal week bye everybody