 So we're a couple minutes early, but it's the last session. So I'm just going to start. Start early, get out early, right? So this is the debugging during development session, or debugging in Drupal 8, creating, breaking, and fixing a module. So I'm Ali. Hi. Thanks for coming. I work at ZivTech. We have a booth on the floor if you guys want to come hang out and talk to us. And you can find me on the social medias at AliRays. So why are we here? So we really want to, when we're developing, to plan ahead to reduce technical debt. And if we set ourselves up for success in the beginning, we can reduce the amount of time it takes us to code and develop and get those tickets. So the reason that I made this session was really it was something I wanted to go to, or something I would like to know more about. Because I really just wanted to stop googling every time I found an error. I don't want to just take someone's blog post and then try their blog post, and then try something else, and then try a different blog post. So we are going to think about, try to logically think through why we're creating this module. And then, of course, we'll break it for some fun. So again, just trying to reiterate that we should be thinking about debugging before we start coding and really setting ourselves up for success. So some of the tools that we're going to be going over in this session is using the Drupal console to build out our scaffolding. We're going to use an intelligent IDE, PHP Storm, in this case. We're going to look at XDbug. And we're also going to look at a continuous integration tool, ProboCI. So more things. So I'm not going to talk about how I set up some of these tools, but I do have a getbook of documentation on the internet where you can look at how I personally set up things like XDbug. So at ZivTech, we use a vagrant environment for our development. And we also do a file sharing. So setting up XDbug to work with an IDE and do file sharing is a little difficult. So please feel free to go check out this documentation. I can't say that it will work for everyone, but if you have any questions or comments on it, this book is more like a work in progress thing where I constantly am adding debugging things that I like troubleshooting errors and things of that nature. So you should definitely check it out. So more of the resources. I'm using a Drupal 8 instance. We're also using an install profile called bear, which you can find on Drupal.org. And we're also going to be creating a module about socks. So for this demo, I created a site called ZivTech Rocks My Socks. And we're going to create a module that highlights some of these socks, the ankle biters, the old fashions, and the knee highs. So in order to break and debug, we need some code, right? But first, we should talk about some configuration and set up for success. So some easy low hanging fruit would be setting up your PHP INI file to make sure that you have error reporting and HTML turned on, and also increasing the character limit for your error logs so you can read your full messages and turn it on to verbose so you can see more. You can't debug it if you don't know what's wrong. So also Drupal 8 ships with a settings.local, a local.settings PHP file, which has a lot of really great stuff. So one of the initiatives of Drupal 8 was make it better, make it faster, which is really great for our production site, not so great for our development site because when we turn on things like aggressive caching, we'll have to turn those things off for development so we're not just constantly refreshing. So you should take a look that ships in your site's default file or directory, and then you'll just need an include in your settings.php. So we use the settings.local file to turn off a lot of the modules we'd also want on production because you don't put this in the get. It's all in your local. So other really great places that you can get resources is documentation and the community, the stack exchange and the IRC. And one that I really want to talk about a little bit more is the change records. So the change records is a really great place to look for resources when you're starting development in Drupal 8. So you can look up things like your favorite hooks, your favorite D7 hooks and search for it in the change records and it will show you how it's changed in D8. So if you're trying to do something and try to build a form and it's just not working, this is a really great place to start and you can be like, okay, this is how it's different in Drupal 8. So can't have a talk about debugging without caching, right? So there's a couple of ways to clear caching in Drupal 8 and you can do it from the terminal and use Drush or the Drupal console and it's just DrushCR now instead of DrushCCL. And one that I really like to tell, like especially project managers is to open up their Chrome dev tools and you can turn off caching in there as well which is just really great when clients are trying to like see new images and things like that. Okay, so I promise I won't talk about caching anymore because I wish we could get paid for every time we had to clear our caches for the site. Okay, now I promise I won't talk about caching anymore. So where else can we find our errors? So we should check our logs. You can find them in the admin interface or with Watchdog you can actually use Drush to just DrushWS and it will print out your errors to your console. So we really wanna be able to find those errors so we can log and debug. So DPM, everyone's favorite helper in D7. So what is DPM? If we actually take a look at the new function in Drupal 8, we can actually see that it's just seeing if our user has permission making sure we're an admin and have access rights and that we are just using Crumo to print out all of our variables. So before we used to be using Crumo and now we're using Kent and it's just basically doing like a var dump of our files. So let's take a little bit more, look a little more in depth than in DPM. So in D7, we have the familiar DPM which we could push down and look for variables. And in D8, this is what happens when you DPM. And I don't know if it's exactly readable but that's kind of the point of this slide is that it's pretty hard to read. We have a bunch of variables and classes that we need to look more into. So how do we make this readable for us? How do we do something with this knowledge? Just to show that it's really hard to read kind of blurry, so it also helps. Really trying to stress the point. So Devel has made sub modules that you can enable once you download and install it on your site. And one is the sub module Kent which has a lot of the color and organizing the code that we can see in this slide. So it's really great and you can find those trace leading to your call and use it for back tracing but we still can't use it to find protected in private methods. So what other tools can we use? Another really great tool to use is called the web profiler. It's another sub module and it creates this, if you turn on the toolbar, it creates the toolbar at the bottom of the site which you can see on the left. Oh wait, home. Yeah, the web profiler. So you can see the toolbar on the bottom and you can actually configure what tools you see in the admin config by just checking them on. So if we look at it on our site, something that is common that we should check all the time is our routes. Every page needs a route, it's like a path that we'll talk about a little more later. But if your route is broken, your site is broken. So we really need to make sure that we can find this information and you can go to the admin interface and look through it or you can click on the toolbar and find a lot of great information that we can use for debugging. So another great tool is the Drupal console. How many people have used Drupal console? Okay, great. Okay, then I won't talk too much but it's really great for generating scaffolding and clearing your cache and you can also use it for debugging as well. So if you go to your code and you can find the route name, you can actually just do Drupal route and then put in that internal route and you'll get a lot of the same information that you will see from the web profiler. So you have options of using the interface or you have options of using your console. So let's talk more about the code. So again, this is the demo site and in order, so this is the demo site and we're going to think through what we need to do to make our site look like this. So first, let's just think about what we need. We need a module. We need a basic page to show our SOC entities. We need to create some SOC entities and we need a form because we wanna ask our user what their favorite SOC is. So let's make it. So we're gonna use the Drupal console to generate some of this code and we're going to generate a module and a controller, then we're going to break it and then fix it and then we'll keep moving forward through this list. So for the module, we would do Drupal generate module and we have options of having it create a composer file for us, our info.yaml file and now you have the optional .module file. You don't need a .module file for your modules in Drupal 8 anymore but I always include them because you can create a help function or method that when the site admin is in the user interface they can click the help function and you can have documentation or links to find more stuff about your module so I always still add it. So to create a basic page in Drupal 8, we use controllers to store a lot of our business logic. One of them is to create a basic page. So we're going to use the console to generate a page for us and on the left hand side you can see the scaffolding of the directories and files that the Drupal console generates for us and you can see that we're trying to generate a page which is on the right. So what is our goal of creating this controller? We're trying to create a basic page. So things that we need is the namespace. We also need any use statements for our classes and we need to print some markup. So we're using this method to not just take over the page but to print out inside of the Drupal content area. And then as I mentioned earlier with routing we have the module routing file which defines the path and in which controller we're using. So a common problem you will find is class not found. So in order to solve this problem we are going to use PHP Storm to try to identify this problem. So there are a lot of different text editors that you can use. One that I personally use is PHP Storm because it has a lot of really great already integrated just goodies that you can use to develop. Some of the goods are code hinting and auto completion which we'll look at in a second. You can also, and boom, that's it you guys have a nice day. It's still bright out so there's still day left. Still light out, that's a fact. Still time to nap before everyone goes back out tonight. Yeah. Hey, if that's the only thing that goes wrong I'm pretty psyched about that. Okay, need sunglasses for that one, right? Okay, so another really great thing that you can use with PHP Storm is you can actually command control and click on classes. So you can step through and look through some of the core classes that we extend when we create modules. So the controller. Here now is our broken controller and when we refresh the page we'll actually get this nice HTML printed error message because we turned on HTML error reporting in our PHP INI file. And we can see from our error that we have an error on line six and that it is a problem with our controller class. So we're going to use PHP Storm's auto completion to find, to look at our class. So we knew it was a problem with our class and then we can actually see that we were missing our use statement which will break your class. You need to tell Drupal what classes you're going to extend. So a really great, you don't have to use the auto completion but you can use it to create the use statement for you. And things like that just reduce, reduce the human error. Reduce the human error of typos and spelling and things like that. So I try to use it all the time. Another really great thing that you can use is to create, you can auto create your getter and your get and set methods. PHP Storm will generate all of that for you. It also generates your annotations and a lot of the documentation that we're supposed to start doing more and more of as we're developing in Drupal 8. So the next thing we want to do is create our socks. So we now have a basic page and now we need to put some stuff on it. So we're going to use Drupal console to create a config entity for us because we need to have our three socks for our user form. And we're going to use a Drupal console to do that and you can see on the left hand side the files and directories that Drupal console will make for you. And on the right hand side, you can see the final config entities. Config entities are a new thing for Drupal 8. It lets you create configurable entities. It lets you create an admin side where you can create things that you can have more fieldable that's not a content type. So what's our goal of our entity? We need to create our socks. We need to create an entity type of socks. So when we do that, you can see on the left hand side, we're creating a class. We're going to extend the base class and we're going to give it some properties. Fabric and some other things that we really want to know about socks. Mostly how far I can push this sock joke. And then you can see on the right hand side, we're still using the build row function to get our properties and display them in the row for our admin side, which is what you would see on the right hand side here. That's what this code on the, also on the right hand side is doing. So what's a common problem we can encounter when we're doing config entities? Accessing the private and protected methods. So this is something that we can't use DPM for. So we need to look through and figure out how to do that. So when you implement an interface, you're agreeing to abide by certain rules. It's kind of like you're setting up a contract. So we're actually using an interface here and we need to make sure that we are following those set of rules. So at the bottom here, creating a protected method for rating. And I'm basically saying I don't want anyone to mess with this outside of this class, but I still need to get the rating. I still want to know what people think of my socks. So we're going to use the get method instead. So we can see here that we have that protected method. So we're actually gonna use PHP Storms auto completion where it'll create the get and set for us, which also generates the documentation, like I mentioned earlier. And we can now use this to get our property instead of just calling it the way you can see above. So we also need a form. It's Drupal, right? Can't have a Drupal site without some forms. And this is the form that we're gonna create on the right hand side. So we can have people vote on which one they like the best. And we're gonna use Drupal console to do that. And it's going to create our sock form for us. So you can see here that our goal is to create the form. And this is pretty, this is still similar to D7. Hopefully some of this is still recognizable. We're creating the form. We're creating a save and or save function. And then we're going to call that. So it's a common problem that we can have when we're creating forms. One is syntax errors. So how do we solve that problem? And we're going to use PHP, we're gonna use the integrated XD bug with our PHP storm instance to logically create breakpoints and step through our code. So XD bug is a PHP extension. It was created in 2002 as an alternative to just doing var dumps. And we're going to set it up. So we'll go back to the broken code. So our error is saying that we're having a problem with our save function. So we're going to use XD bug to solve that. I'm gonna do a bigger video than that one. Great, I'll start this over. So now we're looking at our submit function. And we know that our submit function was broken and we're going to just create some breakpoints in this simple if else condition to figure out where our problem is. So the first thing I did is create some breakpoints. Just gonna create a whole bunch of them just so we can figure out, yep. And we're gonna turn it on. And we created a URL for the ZivTechRocksMySocks.local favorite socks. And now we're going to call the submit function. So when you have XD bug turned on, it'll actually go back to your IDE when you hit your breakpoint. It will stop your site. So now that we have XD bug set up, we can step through and look through all of the variables that our submit form is calling. So we knew that the error was in our form state. So we are going to drop down our form state and look through to find the, look through some of the variables to figure out what we didn't do correctly. So we know that it's calling our variable correctly. It is pulling the favorite sock from our form, from the build form that we created. And now we're going to take a look at the form state interface to see why when we called it our array, it's still not working. And we're gonna scroll through to find our function. And we knew that from the XD bug. Still gonna scroll a bit more. And we realized that it's actually an object where we need to call a method. We can't just call an array to get the values. So we know we're not supposed to call an array anymore. We're supposed to be calling objects. And we can use the method getValue to call our sockResults. So again, we're just changing the value to use the getValue method instead of calling it an array, calling it from an array like we would have in d7. So debugging also doesn't stop at QA. Sometimes we also need to debug our clients. So what do we do when we think, oh, we're amazing module developers and we wanna make all of this stuff live? And how do we logically and not act frustrated when we do things like that? So for example, a common problem would be having a shared staging environment and doing the client approval process when you're working with multiple developers. So a tool that we use at CivTech is ProboCI for continuous integration and it allows us to create staging environments for each feature or pull request. So instead of using one staging environment, we now have multiple staging environments for each isolated feature. And it helps speed up the approval process. On some of our sites, we actually let our client merge it into master and they can do that because we have Probo in place. So setting up Probo, it ingrates with GitHub and you just need to put a probo.yaml file in the root directory of your project, not your module, but in your doc root. And we have the Drupal plugin lets you define your database so you can make a staging site and we're just doing things like turning on, clearing our caches. So when you create a new pull request for your feature, you can run through a system of checks and wait for Probo to finish doing its testing and creating the environment for you and you can actually click on the site and it will pull up your site with your fancy features on them. And then you can show your client who can then go back onto GitHub and say, that was amazing, you're the best module developer ever and push it to production because that's how all client approval processes go. So another problem is cherry pick deployments. So how many people love cherry pick deployments? So cherry picking deployments is when your client wants you to just push some of the code and not all of it and we used to just have full deployment days at ZivTech where Jody would spend all day trying to make sure that everything is correct and we're only pushing certain things when they want the image gallery is done but the user staff profile isn't ready yet but they still wanna push things to production. So how do we get out of the cherry pick deployment? Well, it's when we're really focusing on that get flow workflow and every feature, every ticket is its own branch, has its own pull request and it lets us isolate our client requests to each pull request to each staging environment. So when the client is ready for say the image gallery I mentioned earlier they can just do that on a pull request and push it into master. And the links up here is the probo staging link and this is your staging environment that you would send to a client where they can comment and look and view what your changes. So just to review some of the configuration that we talked about is the get book that I mentioned where I set up all of these tools in a more step by step especially the XD bug one. You can find the SOC module that we created on GitHub and the slide deck. So we really just wanna stop before we are developing. I know it's easy to just start coding before you actually sit down and logically think about what do I really need? What is the goal of what I'm trying to do and then what can I do to make sure how can I fix and test that and what tools can I use to solve that problem? And then success. And that's it, thanks guys.