 Hey everybody, we're probably going to start right now or it's probably a good time to start because it's five minutes behind and we all want to get to the after party. So let's wait for those people to do their thing. Hey everybody. So this presentation is about local Drupal 8 development as maybe you could tell by my slideshow theme. I'm super inspired by it and jazzed by it. I hope you guys find the slides funny and not annoying. I did this very late last night so let's hope it all goes great. Okay so my name is Nick Gajewski. I'm a senior developer at the Ontario Digital Service. So some introductions. My name is Nick, senior developer at the Ontario Digital Service. I've been in Drupaling for about 10 years now, started at about 5.4. And then I've jumped between a whole bunch of technologies from Flash to Python, Django, JavaScript frameworks. I was a front-end developer. I always keep returning to Drupal because it's the best. I work for the Ontario Digital Service. If you're here this morning you heard our CDO speak clearly hardly. We're all about doing things simpler, better and faster. Someone talk to me afterwards if you want to know more about it. Let's talk about why local Drupal development is tight. It's wonderful and I thought of this presentation for two reasons. One, kind of as a junior developer from a long time ago, I remember like setting up a local environment was really difficult. You'd have weird inconsistencies between you and your fellow developers. So this talk is about a little bit about how Drupalate and some technologies helped make that really nice and pleasant. It's also about, I thought of it because I now sort of manage a small team. I have about five, well, between three and five junior developers working with me. So some of the techniques here help us all just stay on the same page and avoid headaches. I want to give a shout out to my brother from another mother, Rollo Henry. He's going to be doing a talk tomorrow, which is a companion piece to this. Basically everything we do locally, we give to him and he takes it and through CINCD throws it into our staging environment and to our production environment. We do kind of like a road show every now and then at the ODS where we go to other parts of government and tell them we've done like 40 production deploys in the last six months. Our production pushes take like between three and seven minutes and we blow mines. So he's going to talk a bit more about how we do that stuff. Okay. So topics. We're going to cover setting up a local Drupal environment. We're going to talk about configuring your local environment for development and we're going to talk about site configuration management. I think with those three topics you should be pretty good to go for local Drupal development. So setting up a local Drupal environment. The big concept here is that local Drupal development doesn't have to be a pain in the butt. I'm talking to you, Zamp, talking to you, Mamp and Wamp. If you guys have been around for a while, you may know these technologies. They were good but I spent so much time editing V host files and setting up all this junk just to get a Drupal install working wasted days of my life and tell you those days are gone. You can actually be productive. Also I spent time with building my own virtual machines and they actually had DevStack and things like that. I want to talk about one thing that I'm really jazzed about right now which is Drupal VM. How many people are using Drupal VM? Three, four people? Cool. Hey, guys. It's on my junior devs here. Yeah, Drupal VM is amazing. So Drupal VM stands for Drupal Virtual Machine. It is the easiest and fastest way to get a Drupal development running locally. Here are the four steps to set up a Drupal virtual machine locally. One, download Drupal VM. Two, run Vagrant up from the command line. Three, go make yourself a coffee or a sandwich, just late at night, grab a beer, whatever. It takes about 10, 15 minutes. Boom, four, start Drupal. It's that easy. Basically all of my team has had a pretty seamless experience with Drupal VM. Jen, would you say that's true? Noting yes. On a Windows machine there are a couple of things you might want to consider. I'll mention that briefly at the end, but if you're running OSX, it's literally that and you're up and running with a vanilla Drupal install. So number two is assuming you have VirtualBox and Vagrant installed, those are also really simple installs. They're stock installs. There's nothing crazy going on there. Question? So no VirtualBox or parallels? Sorry, so VirtualBox. Okay. Yeah, so I just meant it. So VirtualBox is the only piece of technology you'll need, oh, and Vagrant, because you want to use the command line and you want to use some of the benefits that Vagrant gives to VirtualBox. Oh, and feel free to ask questions at any time. I won't get mad. I'll happily answer them. So if you run Vagrant up, you will get this, I actually forgot to include this, but from the command line, it'll tell you where to go. It'll say like, oh, go to Drupal VM.test or Drupal VM.local. Those things have changed, but you'll get a little dashboard like this. It's a lovely little dashboard. It tells you information about your local host. There's some other things that we'll mention here as well, but you can see here it talks about MySQL, talks about MailHog, PimpMyLog, Admin or things like this. These are tools that are packaged with Drupal VM, which are super powerful. You also get easy access to your virtual machine via Vagrant SSH. So like, you know, beginning of the day, if I'm building something, I just type Vagrant up. It does its thing. It doesn't take 10 or 15 minutes every time, just as the first time it takes literally like a minute. Then you type Vagrant SSH and you're free to do command line things on your box. Cool. The beauty of using Vagrant is that you can configure your virtual box with a YAML file. So I love these birds flying, by the way, it's very freeing. So I have a few snapshots here from the config.yaml file. So for example, if you want to choose a specific Ubuntu to install or any kind of operating system, it's just a matter of filling in the line here. If you want to, which you probably will want to, sync your folders to, let's say, a local Git repo. It's just a matter of filling in a few values in a YAML file. If you want to switch between Apache and Nginx, again, just simple as changing one string. MySQL are Postgres, not a problem. One string. In fact, the project that we're working on right now runs on Nginx and Postgres. Locally, and no problems. I can't imagine trying to do that with a XAMP install. I think it would just be a big pain in the butt. Lastly, I just want to draw your attention to these installed extras. So out of the box, admin is installed. So that's like a, what was it, a PHP admin. So a database tool, a GUI database tool. Drush comes along. MailHog, which allows you to intercept emails from your virtual box. PitMyLog is logging software and then a whole bunch of other things here. If you want to install any of these, it's simply a matter of uncommenting these lines. Well, okay, there's one more thing you might have to do, which is called vagrant provision. Not a big deal, but it's really, you don't have to worry about anything more than that. You don't have to get under the hood anymore than running commands at the terminal. In fact, one thing I had to do, which I think I wouldn't have been able to do a long time ago, which is I had to build a queue worker or one of our products. They wanted an email digest to be sent out for our user base. So the email digest would check elastic search. It would then build a queue worker. That queue worker would then send emails to anyone who's interested in specific topics. Sounds like a really big deal, right? With a setup like this on Jipple VM, I was able to do that all locally very easily. Just one note, I didn't actually use this elastic search because we were had a different version, but I was able to look at my database, find out if the queue worker is being initiated correctly. I was able to with MailHog intercept all the emails that were being sent and do all that stuff, all that debugging. It was awesome. Something that would have taken months took a couple weeks to do. It was great. Summary of that, I'll just say that use Jipple VM. It's wonderful. The way you can keep all your developers in line or together is share your config file. This could be kept in a wiki or your git repo somewhere like that. Everyone's going to be happy all the time. Except maybe Windows developers. I did one of my juniors had some issues with Windows. We got around those by using the git bash shell. With the git bash shell, if you run it as administrator, you end up getting through some permissioning issues on Windows. Questions about that? Cool. A note about Lando. I think in the write-up for this, I was going to talk about Lando. I'm not going to talk about Lando. I got really busy. It's my girlfriend's birthday tomorrow, so I've been running around Toronto by all kinds of gifts. Before that, I was at a cottage and camping. Sorry. Although I do, people that I respect, talk a lot about Lando. The interesting thing about Lando is it's Docker-based instead of virtual machines. If you're running something really intensive, Lando might be the way to go. Our DevOps team really likes the sound of Lando. I think that's something I'm going to explore later on. Configuring your local environment for development. When you're developing locally, you obviously want certain things turned on. Let's go over what some of those things might be or how to configure those things. One is you want to set up settings.local.php. So settings.local.php configures your local Drupal install with developer-friendly settings, like to say links are in caches and aggregations. It also allows you to share other settings with your local development team. To use this feature, you can follow the instructions at the top of example.settings.local.php. Sorry, I was missing a local there. So let's take a look at this file, the file that you would create from example. settings.local.php. At the bottom of it, you can paste a piece of code like this. And so this has connections to your database. You can see sync configurations there. You can see the sync development is set to true, while sync production is set to false. We'll talk a bit about more of what that means later on. You could set up like elastic cloud keys there. This last piece, the Drupal root and the kint stuff. Does anyone use kint in Drupal 8? Yeah, so you might come across this issue, which is like errors out and says you can't kint a blacklist function. This gets around that most of the time, not all the time. You'll still have them occasionally. It's a weird Drupal 8 thing, one of my little pet pages of Drupal 8, which I love otherwise. But yeah, so the idea is that with this file, you can either commit it to your code base or again share in a wiki, share with all your developers, and then you all have the same settings and no one's like, why is this not working for me, or why is this working differently for me? As part of this whole setup, when you do the settings.local.php, when you set that up, it enables this other feature, which is development services.yaml. It currently requires one edit because the Drupal community is arguing about a comment again. Another little bit, about Drupal 8 is there's lots of little bugs that remain in it, and I go and find the patch on Drupal, and the reason it's not committed to cores, because people are arguing about a comment. Kind of annoying, but it's fine. So if you go to this file, you'll have to add these three lines of code, and this helps with local debugging. So you could set local debug, twig debug to true. These last two, I haven't quite got to work, but I'm not sure why, but it's supposed to enable autoreload of twig files instead of caching them. And when you set up the first one, twig debugging, you can open up your console and Chrome, and you'll get stuff like this, so messages like this. So if your front-end developers are asking, how do I theme this? Where is it coming from? Where is this file? Basically, every template comes with this bit of code above it. So I'll just move away from the mic here and just point at this for a second. But so you can see that here, it's telling you which template file is actually being used. So very handy for front-end developers, if they're like, you know, because Drupal can be like, if you use it, it's a lot of lines of code. It also gives you template suggestions. So if you want to override this with something else, it'll tell you what to name that file. And then if you clear caches, Drupal will grab that new file and use it. So I'm ready from this section. So share or force commit your settings.local.php file. Normally settings files are ignored by Git, or you could share it in your wiki and then make three lines, change three lines in developer settings.yaml. Okay. Lastly, we'll talk about site configuration management. Does anyone use the site configuration management tools in Drupal 8? Yeah, stuff like that. Or do you use like splitting and things like that? Okay, we'll talk a bit about that here. So Drupal 8 configuration. Drupal 8 comes with a really cool tool where you no longer have to use features. Basically, it's like a configuration management tool. And it allows your sites to, sorry, it allows your sites to store database configurations in YAML files. So the neat thing about this is that you could see if your configuration is out of date by comparing it with a YAML file. And you typically set this on install. You set wherever your site's directory is and you can export your database configuration into YAML files. So for example, here's something that I sort of got from one of my sites. So this configuration tool is telling me that the configuration that I have in my YAML files does not necessarily agree with what's in my database. And you could see here it's pointing to three specific things. So three different node types, their displays are different in my local setup versus what they should be in the YAML files. If you click on these view differences buttons, you actually get like a diff of the two. So it tells you exactly what's different. And of course, the advantage of this is you can commit your YAML files to git. So I could share my YAML files with everyone on my team and we could immediately find out why your site might be acting differently than mine. Okay, so that's great. But on its own, it has pretty limited functionality. Luckily, the community has stepped in and created three excellent modules to extend this. Here they are. One is the configuration installer module. So this module adds another step to the Drupal installation process, which allows you to and install a Drupal site from a config. This is something that I think might be brought into core by like Drupal 8.7. Again, there's some debate about some of the nitty-bits, but it's going to be there soon. So this is, if you're not at the point of like, let's say sharing databases, if you're a pretty nascent site, you can share, you can have all of your development team quickly boot up a site and start working. The configuration split module allows you to partially or completely split configurations as you wish. Usually you want to do that wrong, or I do that anyway, along environment lines. The config filter module is a dependency of the config split module. I've never really interacted with it, but think of it like as an API. You can't have one without the other. You need both. Both have been like incredibly stable for a very long time. Like I think the last time a bug was reported in any of them was a year ago. So they're rock hard rock study. So here is the configuration split from a project I'm working on right now. So you could see that I have a sync development folder and a sync production folder. In this particular case, I'm working locally. So you could see that my sync development folder is active. Well, my sync production folder is inactive. And if you remember that, well, maybe I'll just go back to it. You can manage this via this. So you can see that my sync development status is set to true and my sync production status set to false. So if you show this to all your developers, they'll have the exact same settings that you do. Normally in the past, you'd have to like ask for a database from someone. And then when was the database snapshot taken? And it's kind of confusing. This eliminates all that. Okay, so here's where we were. We're looking at sync development. And the way that I've set these up, and I think this is pretty standard is again, you have a different sync for each environment. Currently my setup for the sync folder has the majority of everything. It's the meat and potatoes of my website. Yeah, and this is typically what I would use for like a development environment or staging environment. You know, those are just standards. Typically this has 900 files. It's kind of huge. The system is a little bit bloaty. But again, the ability to control your configuration in code is important. Sync production sits on top of my sync. And basically what that has is just slight changes to those files. So maybe like Google Analytics keys are different. Or maybe an S3 bucket has a different address. Basically it just has slight modifications on my sync folder. Lastly, we have sync developer, sync development. Similar to sync production that sits on top of sync and has overrides for local developers. This is slightly bigger on my project right now. It's about 20 files. And this like sync production that changes things slightly but also exposes a lot more stuff to local developers. So, you know, you have different develop settings there. You may, if you have an SMTP server, you might set it to, you have to set it to PHP mail. So your mail hog will be able to catch things. You obviously set, you know, display system errors. And you can set permissions to say, for example, anonymous users can see all error messages, which you would never do on a production site. But with this override and the fact that it's, you know, set in your settings file, it's just there. And all your local developers have it. So summary of this section. I would say leverage the configuration installer, configuration split and configuration filter modules to help you manage all your environment configurations. All right. Well, that's it for me. It seemed to have gone really quickly. Happy dribbling. Any questions? Yes. Quick question. I'm not saying this to start a flamethrower because I can go either way. Sure. But have you guys tried Docker for Drupal? All it is is a set of Docker files that download different machines, Apache machines, cruise ship machines and what have you. We need to try. I think in terms of developer friendliness, it's easier for a group, like a singular Drupal VM than having developers learn all the Docker stuff. We even tried creating like a sandbox that was all container based. And it was just too much overhead for the developers and additional overhead for DevOps to be like a wrapper to make that simpler for them. Where it's interesting that Lando could be a possibility, but also in terms of work in terms of DevOps, Vagrant is closer to how we deploy. So we don't have Drupal in Docker. So there's no point in running it in Docker right now until we fully get to a completely containerized. Yeah, we played around with Docker and we found that it wasn't ready for production for Drupal. That I did later with, except I've tried Docker for Drupal in Docker-based systems and operating systems like Ubuntu and what have you. It runs far better because it's native Linux. Rather than if you were to run this kind of Docker stuff on MacOS, I think only recently Mac or Docker for Mac has improved yet. Yeah, I think like, yeah. And the other thing is having like front end developers and junior developers also learn some Docker wrapper commands is rather complicated. Like on the whiteboard at work, I often have like the Vagrant up, Drush CM. I'm like, I have to like Drush CR. Like those are, I think we're at that stage for younger developers rather than like learning extra commands which sit on top of your commands that you would run anyway. Like at my organization for several projects, I did set up Docker for Drupal and we do use it, except the wiki for getting started is like a 14 step kind of thing. And these are devs and even still it's kind of sometimes difficult to wrap your head around why I'm running this command and what happens if it screws up. Yeah, and I think that's why I'm so like enamored with Drupal VM because I like, again, like those four steps, nine times out of 10 is all anyone needs to get things up and running. Which I think leads me to the next question. I played with Vagrant for Drupal in a Windows environment but there were many performance issues. Have you guys run across that kind of thing? So yeah, actually we have. My team uses Max and we're the Ontario government and we got like some really nice Max. It was the last thing we'll get for a long time. Don't worry, don't worry. It took us three years. Yeah, well, the funny thing is the development team was all using their own computers before that. So for OSX, especially like the last two generations, no problem, we had someone join our team who was using a Samsung like Windows based machine. And yeah, he had significant issues with some of the configuration management and importing and exporting. Whereas the person sitting beside him had an OSX and they were both tasked with like, I'm like, all right guys, like, you know, I made a change, like make sure you upgrade, update and everything, you know, one guy was done in a minute and an hour later, the Samsung was still chugging along, trying to get this thing done. So there might be some performance issues on Windows machines. Well, yeah, well with the config installer, like I would recommend that like at the start of projects when things are still pretty bare bones and you don't have any like, say production content there, the config installer works great because you could just create like Laura Mipsum content. For our project, I think we did that, well, we did that for about three months until we started getting significant content in from production. At that point, we set up like SQL dumps and we would import those. Maybe try using like modules like content sync. I have not, I have no experience with content sync. So you just, you guys just do a database dump from production to... Yeah, we're... There was one with Drupal 7, or I can't remember it was Drupal 8, but it, it might be something similar where you remember dump like nodes as PHP and then we tried doing that, but we deal with so much content it's just easier to do an SQL dump. Yeah. Like I think our dump last time was like a half a gig and it was still like a cinch to import is very straightforward. And the neat thing about that is so after you do your import, you do your Drush CIM and it'll override anything you got from production with local settings, local settings that you need. And of course we sanitize all our information before we share it with our local developers. Any other questions? All right. Cool. Well, thanks for coming out. And hopefully see you guys at the Rec Room.