 You are in the Drush session, traditional Drush session. We've done this at all the Drupal cons for some time now. There is always new stuff happening in Drush and that's what we're gonna talk about again here today. The version of Drush that we've all been working on is Drush 7. So here we are, Drush 7, what's new? Little bit about me. I am a long time Drupal core contributor since the very first year of the project. Some of the stuff that I have made in the past, the Deval module, Organic Groups, and now the Drush project. Organicgroups.drupal.org was a site that I founded and I was a founding member of the Drupal Association. And just a shout out to all the self-taught programmers out there, I'm one of you. Shout out to all the non-self-taught too. You guys are awesome. I'm the research and development director at Acquia as well. Forgot that I took a little extra time with animations here. And now my thing won't advance because I got too clever. Okay, so the agenda I think is gonna come up in a second after the bat's done doing his thing. Let's get this bat to do his thing. That's the extent of my graphic design talent. We're gonna go over some of the commands that are part of Drush 7 that you might not be familiar with. I think there's lots of super handy stuff in here. And not quite, oh, I blew my, I guess if you like that, you can give feedback now. Okay, can people see the terminal? Actually, it's handy, right? If the window goes higher. Like I've learned that over the years. Okay, so here I am at the terminal in OSX. I'm in a Drupal 8 site, okay? That will matter later. And I just wanna put a shout out for the topic command, okay? This one's not actually new in Drush 7, but I think not enough people know about it. So I just wanna make sure that you read all the awesome docs that the Drush maintainers and contributors have made, okay? Drush topic is a little hard to see at this resolution, but it gives you a chooser of 25 articles that we have written, or pieces of documentation we've written. All of the global options that are available in Drush is the first one. That's the one I use the most. If you wanna customize your Bash RC, there's a topic about that. If you're connecting to your server through Bastion, there's one there. So there's just a plethora of docs that Drush has provided you to learn more about this product. A lot of these are available as text files in the examples directory and in the docs directory inside of Drush. So if you prefer reading them that way, that's fine too. But we give you a command to read them, all right? Let's start off with Boris, okay? Boris is a separate open source project. Technically it's called a PHP REPL, which is a shell where you can play around with a fully bootstrap Drupal and run commands. So let's just take a look instead of talking about it. So I typed in DR space PHP right there. I've aliased DR to Drush on my system, okay? To save a few characters. And PHP is an alias, a command alias for the command core-cli. So either core-cli or PHP, they both do the same thing. And now you see that my prompt changed to something called self, okay? So I'm now operating in a fully bootstrap to Drupal 8, okay, and I can do things there. So let's look at what I can do. I can run any function that comes with Drupal, all right? So there I ran this function, views get enabled views, okay? And I got, I believe this is an array, it would tell me at the top. Yeah, it's an array of all of my enabled views, okay? The items in the array are entity view objects, okay? Views, config entities. So it handles like complex types as well as just arrays. If you actually care to look at the guts of a given view, you can do that too. That didn't work out for me. Undefined constant, I think these are, that was my text editor, not helping me. Okay, so this is a view object, a single one called the front page, all right? So this is a shell, we have our history inside the shell that we can go backwards with. So it's a really quite a functional shell. I wanna point out that it works on Drupal 7 sites also, okay? So that looks like this, and I had a couple commands I wanted to show you. User load, I'm not in the shell, you guys knew that. Okay, so there's the user object, all right? You can save variables and use the variables later, you know? Okay, so you can load user number one, change a property and then save user one. That kind of stuff is a little easier in Drupal 8 because we have really nice methods on our entities now. So that's using the Boris shell locally. This works with site aliases also, so you can open up a shell on a remote site too. So provided that you have a recent version of Drush on the remote side also, a lot like the SSH command which drops you into the remote side or the SQL CLI command which drops you into MySQL somewhere remotely, this does too. Okay, so you can drop into a shell on a remote site. Okay, so let's hang out in Drupal 8 for a little while and talk about the views commands. I have a command views dash list. This will list all of the views that you have on your Drupal 8 site, all right? It wraps a lot because of my font size, but here they all are. You can see their names and descriptions. You can see their status and any tags that are associated with that, okay? You can look at the help and this command runs a lot like PM dash status which is to say that you can filter the list for just ones that are enabled. You can filter for certain tags. You can use all of the usual output format stuff to get it as a CSV or a JSON if you're trying to script stuff and move all your views from one place to another. You can do that with views list, okay? So let's look at views execute. Okay, so I don't have any promoted nodes so I didn't get anything there. So you might be wondering what executing a view could possibly mean at the command line. So the kinds of things that you can do are dash dash count which is how many results are coming back for this view which can be pretty handy. You can get the view in any alternative format you want. Okay, so the results can come back in JSON and CSV using the dash dash format option. Dash dash rendered is kind of cool. That will give you the HTML so it's a themed view and you can go ahead and put that wherever you need to. And the show admin links flag just takes some of the cruft off of the view, all right? Okay, I want to talk about the configuration commands because they're pretty sweet. The configuration commands are command line way of interacting with the configuration management system in Drupal 8, also called the CMI system. If you guys aren't yet familiar with that. That is a new version of the variables table from prior versions of Drupal. What we did there was we took everything that used to be a variable and either made it configuration or made it state. Things like the last time Cron ran went into the state system and a lot of other things like module configuration kind of stuff are in CMI. So there's lots of commands for working with that CMI system. Let's take a look. Okay, so there's lots and lots of config objects in Drupal 8. Here's one that we commonly use, system.site. That's where you change the site name, among other things. So okay, I ran the command config-edit-system-site, okay? So what config-edit does is it goes and queries into Drupal and asks Drupal. I need the current active configuration for the namespace system.site, okay? And that's currently stored in the database but that's really swappable and Dresch honors those swaps because we go through the CMI API. And so we got that data out of Drupal and we saved it to a temporary YAML file, okay? And we opened up the editor that's currently declared in your environment for editing. So config-edit is really quite useful for getting stuff that's otherwise hidden in your database, serialized, not particularly easy to edit. Pulls it out into your editor for editing. And there's more. So let's just change the name of the name property in system.site to Drupalcon, okay? When I save, when I save and close this file, the Dresch command starts up again and it will do a config write using the Drupal API and actually write your new object to the Drupal, okay, to the active configuration. So that's a pain in the neck to do all that stuff by hand and config-edit really makes it simple for you to do that. Okay, so if we do config-edit again on system.site, hopefully this will work and we'll see our new name. That proves that the round trip worked, okay? Hopefully you guys can see this. The name property is Drupalcon now, okay? So that's config-edit. It used to be only slightly necessary because Drupal stored active configuration in YAML files. So you could at least see them and figure out how to edit them and bring them back in. Now Drupal moved that to the database so really this is the best way to change configuration or the best way without going through the Drupal web UI which is fine but it's slow. Okay, so that's config-edit. Okay, so here's a slightly longer command, Dresch config-set, all right? So there are times when you're working in scripts where you don't want the interactive editor to make changes. You want to just slam in a new value. In prior versions of Drupal, you had the variable set command or vset in order to do this kind of thing. Config-set is equivalent for Drupal 8, okay? The variable commands are unavailable on Drupal 8. That system's gone. Okay, so Dresch config-set and then the namespace you wanna operate in, system.site and then the key that you wanna change and then the value. So we wanna change the name from DrupalCon to Austin. I haven't actually done this in a while. I believe it gives me a confirmation if all goes well. Do you wanna update the name key in system.site? I do and might as well show you this other command. Config-get is a way, it does what config-edit does but it doesn't bring it into the editor. It just shows you in the shell what the YAML representation is for a certain config object. So here you can see the results of config-get-system-site. The second property's name, it's values now Austin. So we just saw how you use config-set and config-get to set values in your site. So the next set of config commands are config-export and config-import. I think you have to be a little bit more familiar with Drupal 8 in order to appreciate all that those guys do but let me just start showing and I'll talk about it. Okay, so the first command is Dresch config-export. Here I'm getting a confirm saying that the current contents of my export directory are gonna be deleted. And then it's got a super long path that tells me exactly what directory's gonna get emptied out. Of note in this long path, and this is a Drupal thing, not a Dresch thing, by default Drupal stores, or Drupal places the staging directory in site's default files and then it's got this long secret path for the two configuration directories. And then it's slash staging, which is to say we're exporting to a staging directory. Yes, it's okay to empty that directory. Configuration successfully exported, okay. So what I want to do is actually show you this directory. Okay, I don't know how you increase the font size and finder. Okay, so basically when you do an export out of Drupal's CMI system, you get a pile of YAML files. You get every configuration object that Drupal knows about exported and represented in YAML, okay. So we could take a look at these. And they wouldn't be all that interesting, but it's the same kind of thing we saw before. This is core.extension.yaml and I think it might hold module weights or something like that, I'm not sure. So now I have all of my configuration objects. Why would I want to do that? So the reason why you use export and import is to propagate configuration changes to your staging environment. So you typically would check them into Git, okay. Then you move the tag in your staging directory or the branch to the new code, verify that everything looks good and then cut a new tag and change your production to run that new tag. So the CMI system exists and the export import system exists so that you can put your configuration into code and move it through the different environments, okay. It's kind of a complicated topic. I encourage you guys to watch a video that is on the Acquia website. If you look for Drupal 8 configuration in Acquia, I think you'll find this blog post by Peter Wollinan and then like add on piece by me after that that talks about how to stage your configuration Drupal 8 and these commands are featured, okay. But I do wanna show you what config import is all about. So we have that pile of YAML files in my staging directory. We can make changes in those YAML files. Let's go ahead and do that. Okay, the flood limit parameter, I change it from five to 10. I think flood has to do with like dossing your site with too many contact submissions. Now if I do drush config-import, drush is going to submit to Drupal all of those files and before it does so, it looks and asks you for confirm. Do you really wanna change contact.settings? And I believe this is the general output of that confirmation. It tells you which objects has changed or been added and removed, all right. And you confirm and you can keep going. You can even do the same thing with, there's an option for seeing a diff, oh dash dash preview. Let's see how that works. So if I'll go as well, I'll see a diff of my proposed change, not just a summary table of what's been added, updated and removed. Yeah, okay. Here's the unified diff. I'm going from limit five to limit 10, okay. And that looks good to me. I wanna import everything that's in my stage directory, namely that limit change. Okay, I got a success message at the end. All right, so that's the set of config commands, okay. We saw list, we saw set and get and import and export, all right. There's a lot of great primitives there for working with configuration. And there's even, if you look at config export, it has a way to automatically start a get check-in at right after that. So encourage you guys to use these config commands when you start working with Drupal 8. Okay, another Drupal 8 command. Migrate-manifest, all right. Drupal 8 you might have heard for the first time has a migrate module in core, okay. So the traditional update.php major version thing is gone, replaced with migrate module. So very basic CLI support for migrate modules in Drush core, okay. I think the other migrate commands that you've been used to will be in a new project called migrate plus, which doesn't have much in it quite yet. So this is the migrate-manifest command. Here you see me passing a database URL, okay. This database URL is pointing at my SQL and specifically at my Drupal 6 database. It's passing the verbose option and it's passing a path to the manifest.yaml file, okay. Let's just go ahead and run it, see how it goes. I'll tell you exactly what it's doing. That database URL that I passed in is pretty important. That tells Drupal 8 where my Drupal 6 database is located, okay. Remember this is actually how I would go about upgrading my site from Drupal 6 to Drupal 8, all right. And similarly, if I had a Drupal 7 site it would work, Drupal 7 to Drupal 8, all right. So you clearly have to pass the database URL in order for the migrate module to be able to get at your old data, okay. And you do that just with that DB URL option. The only argument I passed in was manifest.yaml. That is the path to my manifest file, all right. Since I just put in the file name manifest.yaml the assumption for Drush was that that is in my root Drupal directory, okay. The contents of manifest.yaml are here, all right. It is an extremely simple file with one comment at the top and then a bunch of items. These items here, D6 underscore filter format, D6 underscore user, that stuff is a listing of what Drupal 8 calls migrations. So we're basically just saying I want to run the filter migration, the user migration, a bunch of user picture migrations and the user role migration, okay. That's what this manifest is about. And it's actually a migrate module will sort these according to the dependencies that have been declared for each of these. So you don't really have to worry in a manifest file about getting the order right. It's really about what you want to have run. Manifest files and manifests are a Drupal 8 concept. It's not really a Drush thing. But the first command that got implemented was migrate manifest, okay. If you look up the docs for the migrate module in Drupal 8, you will find a nice page about manifests and you can play around with this stuff. So just to be clear, what happened after our run migrate manifest? It connected to my Drupal 6 database and particularly the filter table and the user and the user picture table. And it copied and translated all of that data into whatever Drupal 8 expects, okay. The storage for these things all changed. But the migrations that Drupal 8 has declared knows how to convert Drupal 6 data to Drupal 8, okay. The user pictures, of course, are a little more complicated. They consist of data, which is in the database. They also consist of files in your files directory. And the migration was smart enough to pull along the files in addition to the data. So if I were to look at my files directory in Drupal 8, I would also have all those user pictures. My file managed table would be properly populated. So these are like nice, happy, clean users with user pictures in Drupal 8. Okay, I wanna cover one more topic and then we'll just go to Q and A. So under the hood, Drush has made a bunch of changes in 7, namely we depend on Composer now. Composer is a great open source PHP project that's become really popular. The way Drush uses it, we use Composer in a couple different ways. The first thing is that Drush depends on a few other projects and the way those get fetched has changed. For a long time, we've depended on a pair of project called console table. Console table is the thing that gives you pretty tables at the command line. So when you list out your projects or your watchdog messages or pending updates and stuff, database updates, those are all tables that are done by console table. And prior versions of Drush would go fetch this stuff right the first time you ran Drush and we had our own routines for how to go fetch that. That's moved into Composer now. The second way we use Composer is we use its class auto-loader. All right, so after fetching these projects, Composer writes an auto-loader that now Drush can include during its bootstrap and now all of these classes can be auto-loaded. This is just a more clean way of loading code than the traditional require and include statements. Okay, so the way that affects like general users of Drush is that you install it differently now. You can install it the old way if you're that kind of guy, but here's the Composer way. What I'm showing here is the homepage of Drush on GitHub. So on our homepage at the bottom, it shows the contents of ReadMe. So in the ReadMe, you get to a section called install or update using Composer, all right? The first step is to install Composer globally. If you've never done that before, you're gonna wanna do that. So I click that link and now I have the global install instructions for Composer. It's super, super easy, okay? It's two commands that you can copy and paste, a curl command to go fetch it, okay? And run the install script using PHP, okay? If you care to separate these two and actually look and see what the installer does, you can. That would be the absolute safest paranoid thing to do, but everyone else just does it like this. And then you're gonna MV move the FAR file into someplace that's always accessible, okay? So in this case, they recommended user local bin. You can put it into any place on your path, okay? So after you've run those two commands, what you have, you can run the Composer command using any user and from anywhere in your shell, all right? Okay, so after you've installed Composer, that really is not hard. If you didn't do it already, here's some instructions for adding Composer's global bin directory onto your system path, okay? The point of doing that is that then Composer projects can, Composer projects like Drush can be called with just the word Drush and not the full path, okay? Next off, there's some instructions for how to install different versions of Drush. The second one is Drush 7, which is the one we're talking about today. And so here's a copy and paste for you. Composer global require and then Drush, Drush slash Drush and then Dev-master is the convention they have for just install the very latest version, unreleased version. Okay, so after you do that, you have a Drush that's ready to go in Composer's global bin directory and if you've added that to your path, then you can run Drush, okay, without any path in front of it. All right, so this is a hurdle that like some people never get over, some people grumble and then get over it. I encourage you to be part of the people who grumble but still get over it. Or if you wanna smile through it, that's good too. But Composer's definitely the way that the PHP world is going, so I encourage you guys to go check it out. We now are using the class auto loader to automatically discover all of our tests. Our tests in Drush, we have like a pretty strong unit test suite that runs on PHP unit. Every commit gets tested by travis.ci and we're also using that Composer auto loader for the SQL commands and soon for the user commands. So we're definitely using more OO in auto loading in Drush 7 than ever before. The Boris shell that we talked about at the beginning, that's fetched as a dependency by Composer when you install, all right? So that's kind of another way that we're using Composer. All right, so I guess I'll open up now for questions or comments or experiences you've had with Drush you wanna share. I encourage you guys to go to the mics, which should be in the aisles there, or in the middle, I see, okay. So are you adopting semantic versioning and especially with the changes for 7, is there a plan to release point increments that potentially add new Drush commands? Yeah, definitely. We have already adopted semantic versioning. So the last Drush 5 release that I made, which was just a few days ago, if any of you are still using 5, was 5.11.0, the most recent 6 is 6.3.0, and 7 doesn't have a stable release yet. But yeah, we've changed our numbering. At the same time we went to GitHub, we also adopted semantic versioning. And we do sneak in new features during a minor version also and just bump that second digit, yeah. So I'm not sure if I missed it, but I'm not clear on how the manifest YAML file gets generated if that's done using the migrate module on the old Drupal install, how does that work? Okay, yeah, that's a good question. The manifest file gets generated by you, as far as I know. So you open up your text area and you just make a list of migrations that you wanna run. So nothing particularly generates it for you. Maybe there's gonna be some contrib Drupal 8 stuff that generates the manifests based on all of the stuff you're running. I really don't know. If anyone in the room knows, they can come up to the mic and educate us. But as far as I know, that's just something that you do. Okay, well, thank you again. I love Drush, so I appreciate it. Yeah, you're welcome. Yeah, echo that. Thanks for your talk today and your work on Drush. Drush is really cool. My question is pretty simple. Is there any changes to the system for declaring Drush aliases in version seven? So far there's no changes to the site aliases. I have been thinking for a while that we should go away from the PHP-style declaration of aliases and make them YAML files. And there would be a Drush hook to adjust your aliases after they've been declared in YAML. So you would essentially be able to do everything that you could do today, like dynamically generate aliases or put in placeholders using PHP. You can do that in the hook. But there would also be like straight YAML files that could be more easily programmatically read and shared. So there's sort of wished for changes in aliases, but so far we haven't had any, which has its own niceness. They're backward compatible and you don't really have to worry about it. Thank you, sure. So two questions. Since you've been rendering and through Composer, is there any kind of scope or plan to refactor Drush on top of Symphony console component? And second question is, do you ever plan to release Drush as like afar? I think that I'm really warmed up already to using console, the Symphony console component. So people who are excited about that, let's start talking in the Drush issue queue and designing that. There is an open issue with a fair amount of discussion in it already called Leverage Symphony Console. So you guys can read up on that and jump in and participate. We, within the last week, adopted the process component, Symphony process, which is about exacting things from PHP. The Drush commands that have done that in the past are Drush, Shell, Exec, and some similar ones, Drush and Vogue process. So far, the use of process has been in the test suite, but I think that we're gonna look into how the backend can start using process. And so that's kind of the baby steps into the Symphony component land. But yeah, I think that console makes sense. There's lots of ways to adopt console and you can adopt it fully and halfway and we'll have to figure out all the different where we stop with console. The way you declare commands has totally changed. So we may or may not adopt that fluent API that console uses. But yeah, I'm inclined to start using it. You had another half question there. Yeah, do you ever plan to release Drush as afar? It might maybe make the barrier to running like Composer Update or Composer Install a little lower. Yeah, I haven't given that much thought. I guess I haven't used many far projects yet. So, or if I do, I alias them to regular files like the Composer does. And so I'm interested in it. Like if anyone wants to work with me on that, I'd be happy to look at it and get excited about it, but I probably wouldn't work on that myself. I'll file an issue. Oh, great. All right, thanks, Dave. Okay. Thanks for your session. My question is related to the configuration commands. So, if I understand correctly, the configurations are saved for each of the languages, right? Based on the language. You can save the configuration. So when you're editing a specific property, can you, are you able to do it based on the language or is it a global update that you're doing? So I don't know is my answer to that. It might just work depending on how languages get specified. If they are like different configuration objects, like if it's en.system.site, then it will all just work. If there's some other way to specify that the exact configuration object with language that you need to update, then I guess the config commands would want to become language aware. I mean, that's definitely something they need to do before a Drupal 8 is released, is be able to be language aware. I just don't know if there's zero work to do or more than that. One more question. So that configuration management tool also provides the export and import capability, right? So this is an alternate of that or do you say that, would you say that is there any, should we use Drush export import config or should we use a configuration management interface capability? I think that you can use whichever one you're more comfortable with, but if you're comfortable using Drush, the end product is the same. You get a pile of YAML files in your staging directory when you export and when you import, it takes whatever's there and puts it into the active configuration store. So it really doesn't matter. It's whatever you're trying to do and whatever is faster for you and more comfortable. So would Drush be faster than do you think? I think most people in here would say it's faster, yeah. Okay, okay, I think that's it. Thank you. Sure. Yes, it's another question. It's more related to the console component. So there's no developer called the developers myself. We just cannot create a project. So as you can see, the R R slash project slash console, we just can have this coming component when you're working on. So let's talk about it. So there's, I think I find an issue also in R. Right, yeah, I think I saw that too. So yeah, you have some success working with Symphony console and yeah, your expertise would be appreciated in getting Drush to use that. I mean, I know that Pantheon's command line tool uses Symphony console, commerce guys, their new platform product uses console. So I think that people who are building modern PHP command line tools are using this thing. So Drush should use it too. Any other questions or tips you wanna share with others about Drush? All right, thanks for coming everyone. There's one more in the back. So you can use the mic. Some people will wanna hear it, I'm sure. Oh, awesome, thanks.