 Alright, let's get started. Welcome everyone. We're going to talk a bit about the Drush ecosystem and you guys will then ask a bunch of questions. I'm looking forward to that. My name is Moshe Weitzman. I'm the director of research and development at Acquia, a longtime Drupal core developer and one of the Drush maintainers. I want to introduce two other Drush maintainers here, Jonathan Headstrom from OpenSorcery, maintainer of Drushmake. If you guys haven't been following closely, Make is now part of Drush5. Mark Sonnebaum, also a performance engineer at Acquia, just want to give you an overview of what we're going to talk about today. These are all of the projects or institutions that are part of the Drush ecosystem that we're going to talk about today. So hopefully you'll find something you're interested in in this list, something you haven't heard about yet and maybe we can increase your Drush happiness here. I figure I can take 30 seconds to introduce Drush for people who haven't heard about it. After that I'm going to assume that you have heard about it and used it. Drush is a command line program. So it's not about web pages, it's not about modules that you install into your Drupal site. This is a command line program that actually works outside of Drupal and drives Drupal. The version that we're working on still is Drush5 that works with either Drush6 or Drush7 and sometimes Drush8. Drupal, sorry, that was confusing. Let's try that again. Drupal6, not 5, Drupal6, 7 and 8. The other thing I want to say is if you're just learning about Drush, there's a command that ships with it called DrushTopic. You definitely want to use topic to read all of the documentation that we've written. The first member of the Drush ecosystem that I want to talk about are two terrific ISPs or web hosts that you use to host your sites. Aquia and Pantheon are specialists at hosting Drupal sites. As Drupal experts, they recognize that Drush integration is really important and they support it as well as anyone on the planet. We can look a little bit about how Aquia supports Drush. There's a URL down here that we can go to. This is the Drush cloud reference for Aquia. When you are an Aquia customer, you can run all of the usual Drush commands. In addition, Aquia cloud provides maybe 20 or so commands here that are custom to its environment that you can run. What these commands do are let you log in to the system and get authentication tokens. You can do all the things that Aquia cloud lets you do. You can push code to any of your environments. You get a dev stage or production environment with Aquia cloud. You can push code to any new environment, change what tag it's at and get. You can create database backups. You can restore database backups. You can sling your Drupal database around from one environment to the other. You can learn environment commands about what you're running in your environment, what tag it's at and so forth. Push SSH keys and find out about your pending tasks. There's a tremendous amount of Drush integration that Aquia cloud offers you. The other big piece that it offers you is it gives you a site alias file with all the aliases to your environments. On your local machine, you can SSH to the production environment and run commands there just from your local machine. That's actually a feature of Pantheon also. They will provide you an alias file that lets you get to your environments also. Definitely encourage you if you're Drush fans to host with one of those two. If either of those don't suit you on www.drush.org, we have a resources page. We list some other web hosts that are friendly to Drush, which usually means they have Drush pre-installed for you. Just to show you a little bit about what that looks like here. Let me make this a little bit bigger. The SA command stands for site alias, and it tells me all the site aliases I have on my system. The ones at the top here were provided by Aquia cloud. Aquiacom.prod is the production www.aquia.com site. I can go run commands against that. No idea if it's going to work because I'm not on, let's not even try that. You can find out more information about your aliases. You can see that that has a remote host and a remote user, and I can run commands against it. So those are how the web hosts participate in the Drush ecosystem. Next big project I want to mention is the agar project. Agar uses Drush very deeply in its system and all over in its system. Agar is a way to install, upgrade, deploy, and backup a network of Drupal sites. So if you are in the situation where you have a dozen or a hundred or several hundred sites that you have to manage, and you want to self-host them, you don't want to use Pantheon and Aquia cloud to do it, Agar is a great solution. One of the great things it does is it enforces best practices around code deployments. So if you are going to do a push of your code, you basically prepare a package in Agar and it runs through a script of deploying to a new directory, changing your sim link so that the web server now serves a new set of code, running the database upgrade, and giving you tools to roll back if you're not happy with that release, okay? So definitely check out agarproject.org if you're interested in learning more about Agar. It's a pretty big system, I can't demo it right now. It would take a little bit too long, but just want to call that one out. Okay, Devel, Devel is a project on Drupal.org. This is a module, it runs inside your Drupal site, okay? It stands for development, it's made for Drupal developers. It has pretty nice brush integration that I can show you. The kinds of things it does, you can generate content, okay? Generate users, terms, images, all of this kind of stuff. If you're building out a Drupal site and your client hasn't given you the content yet, it's a new site. You can just quickly populate it with lots of content and get a feel for exactly how it's working, show the client how it's working. It's really a nice tool. Devel has integration with the XH Prof PHP extension. That's really useful for profiling. If you set up Devel's integration with XH Prof, you will get a link to your XH Prof run at the end of every Dresch request. So you can go see why your Dresch request was slow or not slow, and go in and optimize the functions that took the most time. Super handy, and there are a couple commands for viewing source code. So let's take a look at Devel's Dresch integration. I'm in a Drupal 7 site right now. So GenC stands for generate content, all right? So the next two parameters, we can learn what they mean here. If you just append dash H on any Dresch command, you see the help for that command, okay? So we're passing an argument for number of nodes, which is 50 nodes. We're gonna pass a maximum comments of four, all right? So take off the dash H, run it. Dresch is now creating 50 nodes and up to four comments on each of those nodes, okay? That's all it took, took maybe a second or two. I can go to my site, that's the admin page of my site. Here's the home page. You can see that there's lots of Latin nodes here, okay? This is what Devel does, fills your nodes in with Latin. It's field API aware, okay? So there's an image field on article nodes. It went ahead and generated an image and put it in there. It generates these sort of quadrant images with a circle in them, which is cool. We can thank Nate Haug for that, and there's comments on these nodes, okay? So that's generate content, generate users. It's about to generate 50 users, all done. There's some notice here that's happening that appears not to matter, that I can look into at some point, but I verified earlier that it is in fact generating users. All these users were created 14 seconds ago, okay? If you were to put field API fields on your user entities, it would populate those also. Other commands that Devel offers, this is the help command. It has a dash dash filter option. I passed filter equals Devel, which says just show me the Devel commands. That can be handy sometimes. You can also use grep for that kind of thing. But some people don't like to pipe, so we have a filter. Here are two more commands that I was starting to talk about fn-hook and fn-view. If you wanna look at your Drupal site and find out who implements what hook, that's what fn-hook is all about. Just pass the hook name, and you can see that there's 19 implementations of hook permission in my Drupal 7 site. And I can go ahead and look at the source for any of these. I'll take number two, which is comment permission. And now I can see that function, okay? And fn-view is the same sort of thing for any function. It doesn't have to be a hook. There's the user access function. And you can pipe that to VI. I haven't done this in a while. No, it's the other way around, right? It's not a pipe. You have to pipe to VI-VSV. Really? Yeah. Tell it to read from the internet. Let's see how good you are, Mark. One dash? Yep. There it is. Good job. My favorite command in VI. I'm spazzing out here. Okay. All right. Where were we? We were getting past the VEL. Migrate. Okay, Migrate is a module that I maintain along with Mike Ryan. And its goal is to take data from other systems and move it into Drupal, okay? This is a pretty extensive module and features fantastic Drush integration. So I can show you a little bit about how Migrate uses Drush. Let's take a look at that. So Migrate offers about a dozen commands, all right? The first one we'll use is Migrate status, which has an alias to MS. Migrate status will show us that we have a group of migrations that are beer migrations. Okay, this terminology will be familiar to people who have used the Migrate example module, which is like the docs for Migrate. There's three nodes that haven't been migrated yet or three terms, I should say, beer terms. We can go ahead and migrate those. The Migrate import command is how you do that. Okay, so it just processed three terms and three were created. If you weren't happy with those terms, you looked at your website and something was wrong with them. You just roll them back and fix your code and roll them forward until you have a successful term migration, okay? So the point here is that, sure, the question was, what are we migrating from here? Yeah, briefly, Migrate module is about migrating either from an old Drupal site to a new Drupal site or migrating from some other database or file system and putting content into nodes and users and terms and so forth. So it's a generic data migration tool. Yeah, that's true. Why don't we talk afterwards? Because I have a lot to say about data migration but not here and so I really wanna answer that question. All right, but we'll do it right after this talk. I did, yes. Okay. Okay, next member of the ecosystem, Site Upgrade. Site Upgrade is a command that used to be part of Core Drush. It got so full-featured that we actually moved it out into its own project, okay? So the project is called Drush underscore SUP. Its goal is to give a really robust way for you to run a upgrade from Drupal 6 to Drupal 7. So in a sense, it's an alternative to Migrate module which also provides that service. But this really follows the traditional way to upgrade Drupal sites which is to run update.php. So what SUP does is you install it into your Drupal 7 site and you point it at your Drupal 6 site and you say, go upgrade me, all right? So it will look at all the modules that you are running in your Drupal 6 site and pull down the latest stable or dev releases of everything that is available in Drupal 7 and then it will copy your Drupal 6 database to your Drupal 7 site and it will run the upgrade path on it, okay, or it will install the Drupal 7 site and then it will run the upgrade. So it's a real full service tool for major version upgrades. It's the sort of tool that doesn't work the first time you try it, okay? That's the nature of major version upgrades is that not everything that was on your Drupal 6 site is available for Drupal 7, okay? So it's a best effort and then you have to open up your Drupal 7 site and see what's broken and tell SUP about what you want to do. If you used to use content profile in Drupal 6 and you want to use user entities in Drupal 7, you can say, all right, don't upgrade my profile stuff or write a special update function to handle that kind of migration and then your upgrade will start working. So it's very much a way to just like run an upgrade, trash what you did, run another upgrade, fix some things and keep doing that until you have a nice upgrade path for your site, okay? Here's a module which is pretty handy again for developers called module builder. It has a nice UI for doing its thing but it has pretty great Drush integration also. What module builder is about is the end goal is to give you a .module file and a .info file and a .install file that are skeletons that you can adjust but it's very much an accelerator, okay? So let me just show you and you'll get an even better feel of what it does. It's alias to the command mb, okay? So I'm running Drush mb here. I get a warning here that is of no consequence but it appears, enter the module name. So let's say we're building the temp5 module. Enter the required hook presets. I skip, I don't know what it means. Enter the required hooks. So you can say that the module I wanna write temp5. I know that it's gonna implement permission. I know that it's gonna implement block info. I know that it's gonna implement block view. What's its human name? Temporary five. What's its description? Loram ipsum, Loram ipsum. What's its dependencies? This is stuff that goes in the .info file. It depends on the og module and it's part of the develop package, okay? So what mb has done here, let me see where I can show you. All right, here's the proposed temp5.module file. It put in nice doctogen at the top of the file like we're supposed to do and told me where I'm supposed to customize it. It implemented hook help for me and put all the help text in that I had pasted. It implemented hook block view for me and put the name temp5 at the beginning of the function, and it gave me a nice stub inside with a case of my block and the subject and content here for the block view. I don't see block info here, so maybe I did something wrong when I inputted them all in or it's maybe not called block info, I'm not sure. In any case, this is a really fast way to get started. It has lots of options about where you wanna write the files to when you're done and if you wanna write them and you don't actually have to go through that interactive wizard that I did, you can pass everything you want to mb, dresh mb, my module, menu cron, dash dash write, dash dash quiet, the name is this, the description is this and so forth and so on, so pretty neat function for getting started with modules. Ctools export. Ctools in its latest versions has pretty nice dresh integration and specifically with its exportables feature. If you add a really new module called export bonus, you get even more dresh integration and it's really pretty amazing all the stuff that export and export bonus give you. So if you just run dresh ctex without any parameters, you get the interactive wizard again and it's asking me if I want to export everything or export some things, let's just export everything and it's telling me that the following blotty blotty blotty is gonna happen, all right? Do I wanna overwrite the last module? Yes, yes, sorry, I should have said yes to all this stuff before I started. Okay, so what Ctools export has done in this directory is it has written out exported PHP for all the things that it supports, okay? So this is something that a lot of people have used features for. I'm kind of excited by this because it sort of cuts features out of the loop and just uses Ctools directly to do exports. So if you look at these files here, that one doesn't have a lot of contents, but if you have some imagination, you can get excited. Here, we've taken all our path aliases and exported them. We've taken all our blocks and exported them. Aha, this is the one I want. Okay, so here's the system main Bartik block and it's been exported to code, okay? Same for all my other blocks. Content types exported to code, date formats, fields and instances exported to code, okay? Filters, menus, roles and permissions, variables, vocabs. All of this stuff is exportable by Ctools and Ctools export bonus, okay? Presumably what you do here, you check these files into your Git repository, you do a Git pull-on production and you have new configuration there, all right? Hopefully this can get us through Drupal 7 until we have better stuff for Drupal 8 with the CMI system. So that was Ctex, Omega and Zen themes. I wanted to point out that Drush isn't only for sysadmins and developers. There's some things to offer for themers also. Both of these great base themes offer Drush integration and they offer the same feature which is that you can quickly create a sub theme using Drush. So let me just demo that for you. So if I look at my list of commands, I have a command called Zen. If I look at the help for Zen, I can see that the main argument is the name of the theme I wanna create or the sub theme and optionally the machine name. So if I wanna create the pretty theme, I just called drzen pretty and it said the starter kit for pretty was created in my sites all themes directory. And here you would get all the things, that didn't work too well, that you would expect in a Zen starter theme, okay? So instead of having to copy directories around, change a bunch of function names, it's gone ahead and done all that work for me. If I look at template.php, you can see here that it's already replaced the function names to be prefixed with pretty. Okay, so if I was just copying the starter theme, I'd have to do all this work myself, but the drush command went ahead and did this work for me, okay? So there's things to like. Theemers have things to like from drush as well. Git release notes, better to just show you what it does. This one is for project maintainers on Drupal.org. Okay, wow. Okay, so I ran drush rn, which is the release notes command. I passed two arguments, which is the git tag that I want to start from and the git tag that I want to end at. So the drush 5.4 release to the drush 5.5 release. Here in an HTML list are all of the changes that happened during that timeframe as the commit logs tell us what happened. You can just copy and paste this, perhaps clean it up a little bit and put it into your release node, okay? So this is a huge time savings if you're a module maintainer. And the project is git release notes on Drupal.org. Okay, so the next project is drush deploy. Mark is actually the maintainer of drush deploy and I'll let him introduce this one. Oh yeah, okay. So drush deploy is a tool to deploy your code, not your content or anything else like that. If you've ever heard of a project called Capistrano, which I think there was a Capistrano session here. It's a great best practices way to get your code out there and possibly run tasks when you're done. I found that not a lot of people were using that, possibly because it's just a Ruby project and it's not really just in our vocabulary. So I wrote drush deploy, which is just a complete rip off of it, but it uses parts of drush to enable that functionality. Because the actual part of drush deploy that I had to write was really the only deployment code because drush happens to have, I mean it has site aliases, it has systems to re-erque you to specify specific parameters for a command line or for a command by default in those aliases and all of those things made it really simple to write this tool that ends up being simple in the end. Yeah, and really all it does is you give it, you give it, you have a special deploy that drush rc file and you give it the basic parameters and it will, actually I can show that part. Are you ready to switch? Yeah. Yeah. I can talk a little bit about deploy while you're getting set up. Sorry. Okay, so one of the fundamental ideas around drush deploy is a site list, okay? And site lists are a feature of drush. We talked a little bit about site aliases before, how you can have an alias that points to a remote server and drush will SSH over to that server and execute whatever commands you want. A list is basically a collection of remote servers, okay? And so when you run drush deploy, you run it over a list of servers typically. So you say, I need to deploy a new code tag to my staging servers. And you've set up a site list of staging servers. And so Mark will go over that a little bit. So I'm gonna show you the basics here. So I just have this one site alias setup. Like most said, you usually use this with site alias groups where if you have multiple in the same file, it'll just go across them all. I only have one set up here, but that's sort of the minimal setup for a typical site alias. And here's the deploy.dreshrc file. So you can get an application name because it supports multiple applications on the same server. Let me make this a little bigger, perhaps. Yeah, you tell it what Git repository you're deploying from. And here I just have my fork or press flow. What branch to deploy from. So in this case, this would be a dev setup, so it's just master. Keep releases, so every time drush deploys, it deploys to a new directory and then it swaps a sim link. And so if you want to, say, keep some of those around, you can, by default, it just keeps around three. And then new deploys will delete the other one so that your disk doesn't fill up from big deploys. Deploy via sets the strategy you want to use. There's like a pluggable strategy class for how deploy actually puts code on the server. The remote cache basically just, it doesn't do a full Git clone every time. It has one Git clone in a shared directory and then fetches on that so that it has all the reps that it needs, R syncs into a new directory and then just checks out the tag that you want. Which is much, much faster than actually doing the clone and then you aren't like pulling in place. It's much safer to just fetch and then check out your tag. And usually they tell it where the docker is. And I put one example of a task here. Drush Deploys supports this concept of tasks because as it is, it doesn't seem probably that useful to just have a command that puts your code on a server because you're probably thinking, yes, I can do that. There's a little bit more to that, but it has a really powerful notion of tasks where if you just define a function in this file and then give it the annotation task, Drush Deploy will know that it is a task and it'll register it. And then there's actually another annotation that's not that I don't have in here where you can say this task runs before or after a certain event, like the sim link is the big event. And if any of you have dealt with Copper Strato, this is the exact same concept where the sim link means everything went fine with the Deploy and my current sim link is now gonna go to this new directory. So beforehand, if there was some checks you wanted to run, you can just write them as tasks. And then every task and every Drush operation has to exit zero for the entire thing to complete. If anything exits one, then the entire thing is rolled back. It's basically a big transaction. So yeah, and you can see it just made sure that it had the directories it needs and then it's basically ready to go. So now we'll do a Drush Deploy. Yeah, and so you can see it's SSH and Informing, doing the git clone, then the git checkout, and then updating the revision. Yeah, so then that worked just fine. And if I go to, actually I probably addressed SSH to that. Alias first. Yeah, so Deploy is a little different. Usually you put your alias first and then you run the command. Because when you put the alias first, that's telling Drush everything after this, run this Drush command on the remote server. And Deploy runs entirely on your machine. All it does is SSH, SSH is into the command or into the other server to check out the code. You actually don't have to have Drush on the other server for Deploy to work. So in Deploy, it's taking your alias as a parameter. So it's just an argument to that command and then I can get that alias and then look up all the information about how to SSH into the machine separately. So if you have a Drush command that you don't necessarily want Drush to exist on the other server, you don't want that to be a requirement, you can always just take the alias as an argument. And there's also Drush SSH. We added that recently. I don't know if a lot of people don't use that yet. So then when I look into here, I have the Deploy directory. That's the application name I had. Yeah, and you can see that current assembly is pointing to the release I just did that's all timestamped. And then if you look in releases, there's only one. But yeah, that's what that does. It might seem simple, but it sort of packages all of the best practices about deployment up for you. And I've noticed that, I mean, it's rare that custom deployment setups are taking care of all the same things because especially if you don't have really expensive tasks like update.php every time you deploy, this will let you very easily do a zero downtime deploy where you just switch over. And you can even actually do expensive tasks and you can do all those expensive tasks before the sim link. And then as long as that happens, you just switch over right at the end and you're good to go. So, yeah, that's Drush Deploy. Yes, no, it could, that part of Drush Deploy is pluggable, but someone else is gonna have to write that. I have it in my contract that I don't use SVM. Let's just hold the questions because we're nearly at the end and then people can go to the microphone and ask questions. The last project we wanna talk about in the Drush ecosystem is Cache Audit. Yes, you're on. So, Cache Audit is super, super simple. It's a good example of how simple it is to write Drush commands and how if you have a small need like this, I would highly encourage everyone to just write these small little Drush extensions, even if it's a custom thing for your site because they can be, it's just time saving to just put things on the command line sometime. So, in, so if you normally need to look at a new site and figure out what's being Cache what isn't, especially with views, if you're trying to figure out why this page is taking a long time, I have a bunch of views on that page and you have to go through every single view to go check the Cache settings on each one. That's really tedious. So, I wrote Cache Audit that you can just do Drush Cache Audit. There's only one command, no arguments and it gives you a really nice brief overview of all of the core Cache settings so you can check release easily. I mean, it's something you can also check for consistency on a deployment to make sure that these settings are set to the things that you need to have set. And then for each view, for every display of that view, why did that look so bad? Oh, well, the columns are odd, but oh, because of this resolution. But you can see the Cache settings, whether block cache is enabled and what the times are for each view. So you can quickly audit your site to see which views are not being Cache so you can go Cache them easily and there's a patch in the queue to add panels support. So if you're using panels and you're using pain cache, you might take a look at that. It still needs to be reviewed. And I think the CDN module, there's a hook in it where any contrib module can implement that hook and then add their own cache settings to it. So the CDN module has done this, for example. All right, well, that's the Drush ecosystem that we wanted to talk about today. I hope you guys have some questions. Why don't you just come up to the mic here and kick it off. Hi, this task that you just showed to us, are these to be run every time a new deploy is done or are related to a particular deploy? Yeah, so that would actually happen on every single deploy. For example, you did a change in the source code in the module and that needs, for example, to run a Drush update DB for that particular thing when it's deployed. Yeah, so good question. And let me pull up the readme so I have a reference. Yeah, so here's the example right here. That type of thing is something you want to control per deploy. It's probably not a great idea to say, I mean, so my deploys used to be, I mean, by default, I would always do Drush CC all. Drush features revert, because that's an idempotent process that always is gonna happen. But update DB doesn't always need to happen, right? Or there might be other expensive processes, like maybe on some deploys, you need to rebuild node access, god forbid. But that's not something that you want to necessarily hard code in this, because your Drush deploy file is likely going to be committed into source control, and you don't wanna hard code that because you're gonna wanna change it from deploy to deploy. What I do, I mean, what I used to do in Capistrano and in this, I would say, so this is the line, this options after deploy Simlink, that means I'm gonna run that custom task after the Simlink. I would set up those, like have all your tasks in that file, and then set all those up with all of the expensive ones, or the ones that you don't do every time, comment it out, and open this up and uncomment it right when you're doing your deploy. Because that's something, like this is made to do the deploy, I mean, like Jenkins isn't doing this deploy, like you're gonna be doing it most of the time. And so that bit of a manual process, I don't really see is that big of an inconvenience because you're gonna have to make those decisions anyways. And so, yeah, you just really uncomment them. I have been struggling with site aliases. For example, two developers working on the same project, I'd like to, both of them, use the same site alias definition. But one has his development environment set up differently and has different pathos of web routes defined. Is there a way to override for project-based site aliases, or is there another solution for this? Are you working on the same server as the other person, or how do you send? Local developments on the computer. And they, I'd like to share the same site alias file, because it's centrally set up and maintained and stored. Yeah, and the site aliases that are inside the file are pointing to remote servers that you both use, or? And both remote servers and local servers for their own dev. All right. Yeah, what's the use case for site aliases locally? They can, we have one script to pull the database from acceptance or life to development environment. And there's one script that uses the same alias. So pull from acceptance to dev. And so they have the same script. Yeah, I mean, I would say that the sites that are local should be in a different file than the sites that are remote. And the local one, you basically maintain your home directory and do what you want with it. So yeah, that's the solution. And the only other, I mean, if you really want to do this, one of the nice things about our configuration files being PHP is that you can sort of do whatever you want. You could do something like, like look, like check, or like do a, like a get end local end. And then like have, like get somebody's name and then do a switch based on that and then have all that in code. And then just make sure that everyone exports that variable in their bash RC. Or include a local file, well, that you can have to. Yeah, yeah, or it includes a local file there. That's actually, that's the way you usually do that with like settings of PHP. Yeah, okay. I have a question about installation of Drush because for a while there has been this DBIN package which I always found like really useful because I was running DBIN anyway. And then I recently read that, it's not the preferred way to install Drush anymore so could you just comment on that or? Yeah, so we had that and we were working on maintaining that a little better so that we could, because yeah, I mean, having Drush in apps is really inconvenient. Like lots of packages in Ubuntu, they just get updated really, really quickly, right? So it's, and they also can't change a major version with a, within that. So you can't have, so if Drush four is on whatever version of Ubuntu, we can't then just upgrade that to Drush five because it's a major version. So it just doesn't work well. And if we're gonna really make that better, we'd also need to do it for Yum and everything else. I just tried, I figured, well, we have Pear and I noticed I was installing PHP unit with Pear and it's like, well, how hard would it be to do that? And so I set that up and it actually works really well. And so for probably over a year now, we have set up Pear.drush.org and it's a custom Pear channel which I mean most things you install from Pear have custom channels nowadays. And all you do is use Pear channel, discover Pear.drush.org, Pear install, drush slash drush. And that's it. If you go to the Drush, the Drush project page, I'm pretty sure it has those instructions on there. And I mean, it's, it might be, I mean, you need to make sure you have a recent version of Pear. PHP unit has the same limitation and you can just upgrade your Pear. But if you have any trouble doing that, I would really highly suggest just, just getting through that and making it work because we as a community, we tend not to use packages that much. Like we don't use Pear very often. Composer is fixing a lot of that. We're starting to use that more, but we're generally kind of bad at sharing code because of that. And Pear does suck. If there's a lot of things about it that are wrong, but it's what we have. So as PHP developers, we should probably be more comfortable with using it. Is my opinion? Yeah, thanks. And certainly folks who want to just get cloned, drush and follow along and run, head or run a stable release, that's a perfectly fine way to, you know, keep up with drush also. So use Pear, use get, whatever you prefer. And I'd say usually it's like the, and Pear will be updated, like the day we make a release, except that it's not right now because my laptop broke when I was here. And so I don't have my SSH keys. So I'm going to do it soon. Sorry about that. I wondered if you could say two things about the distinction or maybe how complimenting AGR and drush deploy would be. As in like which use case or just practice when to use which? So drush deploy is more for a single site. I mean, you could do it in a big multi-site setup, but like what drush deploy does is sort of a small part of what AGR does. And AGR actually uses a very similar process. They just, they actually just sim link into the Docker instead of sim linking the entire Docker. But they used a very similar process and a good technique. But really I would say that's an issue of whether, like you have a good use case for AGR or not. If you don't, I mean drush deploy is going to work for pretty much any site as long as you have, or the point from get, and you have your point via SSH. But I mean, AGR is much more geared towards just a massively like massive multi-site where you're constantly creating new sites if that answers the question. Yeah, that's, I mean, we're using AGR, so basically kind of adding drush deploy to this core concept wouldn't really give much more like beneficial functionality or something, so that's how I understood you. Okay, thanks. Hi, is there also maybe a site configurator or a site generator? We're just write a little file and I say, okay, this website has this and this menu, this template, this blog, blah, blah, blah. I write a text file and now click on a button and then the complete website is generated, maybe in Italian, maybe in English, maybe. So that I don't have to click in administration, site building, blah, blah, blah, menu, blocks, et cetera. Or do you know? Are you proposing a new project for drush that is like a text file spec for your website? Yeah, maybe just a generator, a site generator. Yeah. It seems like there's a lot of overlap that idea in say like features and install profiles. Yeah, and drush make to a certain extent is a little bit like a text file that defines your website. So there are pieces of that out there. I think what you described is a really big project, so that's probably why people haven't taken it on, but it certainly would be handy to be able to write a text file one afternoon and have a website come out. Okay, so there's a comment here that there's a Drupal 6 project called Bone that attempted to do this sort of thing. So perhaps someone will revive Bone and save us from all our consulting hours. Any other questions about drush or drush ecosystem? All right, oh, there is one, great. One last question. Regarding Ctools export, I didn't get exactly the difference or how is it different between features? Is it made to take over features or can you elaborate, please? So I'm definitely not the expert on Ctools export or as a collection and share features with other people and so forth. And the functionality, I mean that's not new, because Ctools has always had the import, export UI, and then the old way of doing this before features was you took that export and you put it in a file and then Ctools would load it. The only thing the drush command did is it automated taking that and then putting it in a module and doing all that stuff for you, which then makes it sort of overlap with features because it's easy to export that way. But the functionality is something that's been there actually before features existed. And features actually uses the exact same code that Ctools is generating, so features is like an extra set of. Yeah, and so as long as all of your exportables are Ctools exportables, you could potentially use that, I think, instead of features. Yeah, one other question, not strictly related to the ecosystem, but can you tell us anything about like your plans for drush, what's next for drush, or any big features or? We're, you know, we worked really hard to get drush five out and we're kind of in a blissful rest period now with drush as far as drush six, so I'm open to everyone's ideas about what drush six should do and future versions of drush, but I guess we don't really have concrete plans for the next version and what we might add there. Okay, I think it's likely we'll do some internal refactoring to make it more OO, probably not like as intense as Drupalate, but some simple clean up and refactoring. I honestly, I don't want to add any features. I mean, I think the drush core as a framework is getting really close to being feature complete and so I just want to make a stabler core drush that makes it simpler and easier for people to write commands for it. Cool, thanks. I was curious, somebody mentioned the idea of using drush to download a copy of the production website to a development environment or your local laptop. Do you have any suggestions about additional commands you might want to use and other modules that would extend those, for example, to sanitize the database? Uh-huh, okay. Well, just around slinging whole sites around, that's the archive dump command if people haven't used it. So, or is it the site archive? No, archive dump, right, archive dump. So, this command will take the code for your site and the database for your site and the files for your site and zip them all up into one tarball, okay, so you can move that somewhere else and restore it somewhere. It's actually a standard Drupal format, the site archive format, and there's a corresponding archive restore drush command that is for untarring those files and restoring your Drupal site. Greg also mentioned sanitizing your database. This is a feature of the SQL sync command. SQL sync in core drush allows you to move your database from one server to another server, typically using site aliases to move it to a remote server, and you can sanitize along the way, which is to say you can remove the passwords and email addresses if you want to. Sanitize is pluggable, so if your site has more confidential information than just email addresses and passwords, you can implement a hook and scrub that data out of the database dump. It can be useful if you're providing a database dump to all your developers, you might want to sanitize it first, you have less PII going out to your dev team and possibly getting leaked that way. The sanitize release, the sanitize functionality can be used on its own. There's a SQL sanitize command, so if you're not doing a SQL sync and you just want to sanitize my SQL dump that you have, you can just do it that way too. Lots of sites implement their own commands to like pull their code and their database and sync to local environments, and sometimes that's necessary, but it's really worth checking out drush r sync and drush SQL sync because I think it's pretty likely that those commands would actually do it all for you. Just another project that does similar is drush fetcher, that's a sandbox that Howard just released like last week, and that kind of builds your entire development environment and gets your database and sets up your Apache and pulls from Git and gets any submodules and does all that stuff, so it's worth checking that out too. Cool, yeah, drush fetcher. Sandbox by Howard Tyson. Okay, yeah, check that one out. I know the vagrant module has some drush integration, which is pretty neat. There was a Drew Puntu project, which I think is a little bit passe now. Perhaps Quick Start is the one that sets up your drush for you and sets up your whole environment for you to do development, so check that one out also. All right, well, please give us feedback by searching for drush ecosystem and filling out what you thought of our session. Last thing I want to add is that we have some aquia t-shirts here, so feel free to come up and grab a t-shirt around the edge of the table here. Thanks for coming. See you later.