This is a transcript. For the full video, see Drush 10 - Tag1 Team Talk #006.
Preston So: Good morning, good afternoon, good evening wherever you are in the world, and welcome to another episode of Tag1 Team Talks, the roughly biweekly podcast and webinar series about emerging web technologies hosted by Tag1 Consulting. My name is Preston So, I am Editor-in-Chief at Tag1 Consulting. I'm moderator of the Tag1 Team Talks, and also author of Decoupled Drupal in Practice. It's a real big pleasure today to be joined by three of my good friends this morning, and I want to welcome first of all, Moshe Weitzman, as well as Fabian Franz, and Michael Meyers. We're going to be talking today about Drush 10 and we're joined by the creator of Drush himself, Moshe Weitzman, and by the way, if you want to check out this episode and other episodes on Tag1 Team Talks, please go to tag1.com/tagteamtalks, and if you like this webinar/podcast, please remember to upvote, subscribe, and share it with your friends and family.
Preston So: Let me go ahead and introduce our guest today. I am located here in Berkeley, California. Moshe Weitzman is located in Boston. He's a senior technical architect at Tag1. User ID number 23 on drupal.org, Moshe is one of the few people in the world that have contributed to the core of every single version of Drupal. He's made countless major contributions to the platform, including creating the migrate module, organic groups, testing harness, and of course Drush, which we'll be talking about today. One of the fun facts that Fabian just indicated to us today is that Moshe has actually been at every single DrupalCon in the history of Drupal, which is quite impressive.
Preston So: We're also joined today by Fabian Franz in Switzerland, Senior Technical Architect and Performance Lead at Tag1. Fabian is one of the top five Drupal 7 core branch maintainers. He's also one of the top 50 contributors to Drupal 8, and is the maintainer for several Drupal 8 core subsystems, including big pipe, dynamic page cache, and theme API. Finally, we're also joined today by Michael Meyers, Managing Director of Tag1, and I'm going to turn the mic over to Mike just for a second here. Do you want to talk a little bit about Tag1, and why we're talking about Drush today?
Michael Meyers: Awesome. Yeah. Thanks Preston, Moshe, Fabian for joining us. Tag1 the number two all time contributor to Drupal. We work with a lot of different technologies from Laravel, to some real time collaborative systems with this awesome framework called Yjs. Obviously, Drupal's core to our business, and automation and management of Drupal sites is key to every project that we do. So we're thrilled to have Moshe on board, and looking forward to Drush 10, and 11.
Preston So: Absolutely. Well, let's go ahead and get right to the questions, but first, before we get into kind of the background around Drush, and a little bit about the history, Moshe, I mean, we've got you as the creator here on our webinar and podcast. I'm curious, what's the best definition of Drush for those of the audience who haven't really been familiarized with it yet?
Moshe Weitzman: Sure. I want to just let everyone know that Drush existed for a little while before I took it over. It was one of many brilliant ideas that Arto came up with way back in the day. And so I've maintained it for over a decade at this point, but I wasn't the actual creator of it. So Drush is a tool that you add to your Drupal website via a composer, and the main function of this tool is that it speeds up lots of administrative and development functions that you need to do in order to take care of your Drupal website.
Moshe Weitzman: Okay, so if you need to enable or uninstall modules, you need to install a Drupal website, you need to block a user, change a password of a user, and so many more things you need to update your search index, you would use Drush to do that quickly. It's a command line interface, which means that you use your terminal, and you type out a few commands, which people who are watching this are probably familiar with that. And we use Drupal's API to get done what you need to get done. It's faster because Drupal doesn't have to deal with rendering and theming, it just will go ahead and do the thing you want to do.
Fabian Franz: Yeah. And it's pretty amazing when you were talking about what Drush is, what it felt to me like was, hey, I've been using this every day. I couldn't even imagine using Drupal without Drush. It's just really, really amazing achievement in that.
Moshe Weitzman: Yeah, I definitely have heard that before. It would be really painful to have to use the web interface for everything. Not to mention the fact that we're sort of in a DevOps revolution, years into the DevOps revolution, and you need scriptable websites in order to behave well in there, and Drush really is the scriptable interface for Drupal.
Preston So: That's amazing. And I'm also a very frequent user of Drush. I use it all the time. It's a really well designed and amazing interface for doing just about whatever you need to do with Drupal. But let's dig into a little bit of the history of Drupal, and the kind of past of Drush. How exactly did Drush come about, and when did it come about, and what happened to kind of let you begin to get involved with Drush, and start to maintain it?
Moshe Weitzman: Yeah, so Drush had its 10th anniversary maybe a year ago. It's quite an old project. And as I said, it was started by Arto. It was originally a module on drupal.org Contrib that you installed into your website. And people were pretty amazed, and thankful, and impressed, and happy with Drush as a module. But as we expanded it, we were unable to really fully realize all the commands we wanted to offer. Namely, you couldn't install Drupal using Drush, and other things that sort of happen outside of Drupal, like starting a web server in order to quickstart a Drupal site, and so forth. So I think it was Drush 3 when we switched from being a module to being a project that is outside of Drupal. It was a really big change, and I want to say thanks to everyone who contributed. Greg Anderson contributed to that pull request, and he's been a constant maintainer ever since then. So seven releases of Drush, he's been an awesome co-maintainer with me.
Moshe Weitzman: So we moved ourselves out of Drupal, and we are able to offer site install and quick Drupal, and lots of other cool commands like that. I think one part of your question was like, how did I get interested in Drush? Well, it was very much a scratch your own itch situation. I was a Drupal consultant, or at least a core developer, and wanted to get things done quicker and I saw that Arto had made something interesting and so he seemed like he wasn't maintaining it that enthusiastically anymore, so I jumped in and helped, and then eventually took over the maintenance of that.
Preston So: I think that's an amazing story that really reflects just kind of how so many amazing ideas have come into Drupal. People come in with an idea, you scratch your own itch by working on it with them and then eventually, you become a maintainer yourself. And that's the story that I think we all share as contributors to the Drupal ecosystem. And I wanted to ask what were some of the major milestones along the way, some of the major kind of enhancements, or features that landed. Are there some major Drush version numbers that you consider to be more important because they introduced certain functionality, or introduce certain features that were really commonly requested?
Moshe Weitzman: Sure. So I think Drush 2, [Adrian Rousseau 00:00:09:09] put in the idea of interacting with a remote Drush, a remote Drupal website. So what we now call site aliases and the backend functionality where from your local Drupal website, you could go out and rsync the files directory, or SQL sync the database from one drupal installation to another, or run user login ULI on a remote site and get the URL to login as user ID number one. That was a huge boost in functionality. There was a whole backend API that was super robust that worked over SSH that let us do that. It was only in Drush 9 when we finally got around to rewriting that. So kudos to Adrian for making a nice framework there.
Moshe Weitzman: And so moving ahead in the chronology, yeah, becoming an independent project of Drupal might've been Drush 3, a huge step up. Drush 5, I think, we implemented output formatters. That was very much Greg Anderson's contribution. So output formatters let you take a command like PM list, which is the list of all of the modules that are on your Drupal website, and which ones are installed, and what their category is, and name, and machine name, and all of that sort of stuff. You typically get a table of information out which is very readable, and nice for humans. With output formatters, you can get that table in JSON format or YAML format, which really opens up the possibilities of using Drush for scripting. So I mentioned the dev ops revolution. I mentioned we've got continuous integration. Output formatters are really useful in those scenarios for wiring your programs together.
Moshe Weitzman: Innovations after that, when Drupal 8 came out, Alex Pock contributed the configuration commands. So config import, config export, config SAP, config get. Later on I wrote config pull, so right from the beginning of Drupal 8, we had strong CLI support for its config subsystem, which has been invaluable to realizing the potential of that subsystem. I think just about everyone uses those commands when they push their code from dev, to stage, to prod. So definitely that was a big milestone. This is a long winded answer, hopefully people are enjoying it though.
Preston So: Of course.
Moshe Weitzman: Okay, so Drush 9 was a monumental release, maybe a year ago, and we rewrote Drush. For the very first time, it was rewritten from the early days, Drush 3 when it got pulled out of being a module. We rewrote it in a very modular way. We put lots of composer packages out for the public to use. This would be the consolidation annotated command, consolidation site process, consolidations site aliases. So people who are writing command line projects can go ahead and use those packages if they want. That was one benefit. The other benefit is that Drush itself became smaller because we modularized that site-to-site communication, and we made it really easy and tight to declare a new command. Commands are no longer written in PHP like they were in Drush 8 and prior. Well, commands are written in a combination of a PHP method for the callback, but the Doxygen above a callback is how you declare the command name, and usage examples, and parameters, and options, and so forth.
Moshe Weitzman: In the same release, YMAL took over as the format for configuration and site aliases in Drush, and we started using Symfony Console as our runner for commands, and we built on top of that. So yeah, Drush 9 was definitely a monumental release for Drush. We introduced a few new commands in 9. We have support for config split, which is a module which we may not need going forward, Drupal 8 and further, because it's been brought into Drupal Core, but that's the way you get some modules to on in prod, but not on in development, and vice versa, and you can vary your configuration easily by environment. And there were some conveniences in Drush 9. Running commands from the project route instead of from the document route.
Moshe Weitzman: And finally we added Drush Generate, which perhaps some people don't know about, but I really think it's awesome. That's a scaffolding command so you can quickly create plugins, services, modules, lots of files that you need to build a modern Drupal site, and you can quickly template them out, and put them into your source code and just edit them from there. Drupal console was a first project that brought that to Drupal 8. Drush has since gained that capability a year ago in partnership with a separate project called the Drupal Code Generator, which people should check out. It's pretty great. I'll stop there.
Preston So: Absolutely. No, I've actually used Drupal Code Generator in the past, and it's great to see that now with Drush Generate being part of Drush itself, that's going to open up a whole lot of possibility for people who are really trying to speed up their Drupal development process. So I know that today we're really interested in Drush 10, and I know both Fabian and Moshe, you both are very interested in Drupal in Drush 10. I'm curious, what are some of the new features in Drush 10, and what should we be looking for? What are some of the key value propositions that distinguish Drush 10 from some of the past versions that we've just described?
Moshe Weitzman: So Drush 10 is the version that is best suited to Drupal 8.8 which is coming out soon. It is the one that embraces the new configuration features, exclude API, transform API, the config split in core stuff. So features wasn't really the focus for Drush 10. What we did in Drush 10 primarily was remove a decade's worth of code from Drush. So in Drush 9, you actually have all of the old APIs, and all of the new APIs. So the commands that are in there generally are using the new APIs in Drush 9, but if you called a Drush 9 site from Drush 8, it will go into all of the old code branches. So we decided to make Drush 9 like that in order to make it easy to give people a lot of time, a year to upgrade their commands, and be able to interoperate with older versions.
Moshe Weitzman: So Drush 10 interoperates with Drush 9 fine, but it doesn't interoperate with prior to that. So 10 is extremely lean, extremely clean compared to 9. And what does that help us do? It helps us enjoy and be able to maintain it for another decade. So I think that Greg and I are committed to Drush, and want to keep growing, and keep it a high quality project with test coverage like it has for all its commands and subsystems. So I think that Drush 10 really sets us on a path for years of profitable use of Drush. There aren't many projects that last as long as we have, and keep the quality up the way we have, in my opinion. So I think a release like 10 is really quite important. I encourage people to upgrade at your earliest convenience. Even though there aren't that many new features, you're going to get sort of the best level of support going forward, if you're on the most recent version of Drush. So go ahead and upgrade your composer files and bring it in. I think you'd like it.
Fabian Franz: This is amazing. Do you have any statistics of how many lines of code you've kind of removed, or re-written, or something like that? That would be really interesting.
Moshe Weitzman: It would be really interesting. I don't know. I guess if someone wants to take that on, it's all in Git. So yeah, please do share how many lines of code we might've removed.
Michael Meyers: Speaking of statistics, do you have a sense of how many, or what percentage, roughly, of Drupal websites use Drush? I would imagine the majority.
Moshe Weitzman: I would also imagine the majority. So Drush is not a module, so it doesn't report back to drupal.org, so we don't have those statistics. We have statistics that packages gives us around number of installs, and those numbers are incredibly high for all packages because of CI systems, and so forth. So I don't really pay much to those numbers, but the numbers are quite high if you feel like checking them out. Stars on GitHub are an interesting metric, at least we're pretty sure that humans are the ones who are starring projects on GitHub. Our GitHub page actually now shows the number of GitHub repos that include us as a dependency, and interestingly enough that number keeps going up rapidly, as if Github is slowly churning through their millions of repositories, and upping the numbers. So yeah, I don't know if someone can take a look at our page and see what the number of stars and number of dependencies are, but yeah. They're in the thousands, and certainly the feedback I get at DrupalCons is that people are using it and enjoying it.
Fabian Franz: So you should really just add a little phone home, all the new software has phone home. Like for Drush, a cache clear. [inaudible 00:21:52]
Moshe Weitzman: Right. In prior releases, we had some analytics around what commands people were using, and we would have people opt in to that and send the data to a hosted MongoDB . But it turns out that I didn't really have much interest in churning through those numbers. I knew people were using the commands, I knew they were enjoying it. They were telling me, and I didn't really want to dig through the numbers that much. So I didn't use it. And I think that service reduced their free plan to the point where we couldn't use it, and then I just removed the logging from Drush. So we don't have those analytics. It would be pretty cool. I think that the Homebrew CLI has a nice analytics platform. It's not too common in CLI tools to do analytics like this, but Homebrew does it, so if anyone wants to bring it back and model after Homebrew, I think that'd be pretty cool.
Preston So: So Moshe, I've got a kind of a serious question, a very serious question, in fact. Drush 10 is a huge milestone, as you said. I think it really reflects the long and storied history that Drush has in the Drupal ecosystem, and especially the fact that it's something that has had a lot of staying power, and so many people use it. I still use it every single day. One question I have, though, is we've got the iPhone X, why not Drush X?
Moshe Weitzman: [inaudible 00:23:32].
Preston So: Yeah.
Moshe Weitzman: I feel like the semantic version of people would get really upset if you introduced letters into a major version.
Preston So: I think I agree with you on that.
Moshe Weitzman: Yeah.
Preston So: So let's turn to another area that I think is of interest to a lot of folks because, I think there's been a lot of innovation in terms of CLI development within Drupal. We've heard, of course, from a lot of folks that they'd like to use Drupal Console as well, but I think a lot of us are confused about what are some of the distinctions between Drush and Drupal console, and when are systems situations that you'd want to use one over the other. I know that they're very different, and they have very different use cases, after having spoken to both you and Jesus as well, the maintainer of Drupal Console. What are some of the major differences that our audience should know about, and when should they use one over the other?
Moshe Weitzman: Yeah, I get that question a lot, and I'm actually not an authority on that question. So I really rarely use Console, so I can't really say what it does, and doesn't do. My impressions as a barely informed person I can share. They do largely the same stuff, and the commands vary in minor detail. So in that sense you're free to use whichever one you like because they kind of do the same thing. And even you could say they have similar architectures, because they're both built on top of Symfony Console. The commands look different if you're into command authoring. Drush has this annotated command layer on top of console where you write commands using annotations, and Symfony Console has like a straight Symfony Console approach with a few different methods per command, and that's really just a stylistic difference. Really doesn't matter for functionality.
Moshe Weitzman: I think there are other differences that may matter to people when they're trying to choose. And again, I could be wrong about this stuff. My impression is that Drush is quite a bit better in its testing coverage and approach than Drupal Console. Console does a fair amount of testing, but it's unit testing. Drush actually shies away from unit testing. It does functional testing. So we have a real copy of Drupal in our test suite, and a full copy of Drush, and we run CLI commands, and test the output of those CLI commands on a real Drupal. And I think that the Console does more mocking in their testing approach.
Moshe Weitzman: There are advantages to both approaches. There's whole other talks around the best way to do testing. I happened to come from the approach where functional is really important, and shouldn't be omitted, and so that's why Drush really pays attention to that. It's my impression that over the last year plus, Drush's development has been more robust than Console's. Console seems like they had a burst of energy a couple of years ago lasting a while and doing great work, but the sort of focus has moved to other projects for the people who are maintaining that. And so those are reasons to consider when you're picking a new CLI tool for your project. Having said that, the main template for Drupal, which up until a couple of weeks ago was the Drupal Dash project in GitHub included both console and Drush, so you really can switch between them, and be as polyamorous if you want. There's really not a problem with it.
Fabian Franz: I also hadn't had a question I'm really curious about, and the question is how did you personally feel when Drupal Console was just first released?
Moshe Weitzman: I was impressed by parts of it, and thought that Jesus and that team were innovators in the space, and my first efforts and desires were to like, "Hey, let's merge efforts, and make one great command line tool." And I think there's a lot of history in Drupal around trying to collaborate instead of fork, or instead of making duplicate projects. And so that's the goal I really wanted. And I pitched that goal in Prague, the console maintainers said they would think about it, and then they became unresponsive to follow ups on that question.
Moshe Weitzman: So I got the impression that they liked their current tool, and they liked their current development process, and wanted to stay as an independent project. So it was a little disappointing. I felt disappointed, to answer your question. I think that people felt confused about what tool they should be using, and the confusion remains today, Preston asked the same question. So that's how we ended up with two different command line tools that do similar things.
Fabian Franz: Right. It's pretty unusual for a Drupal project to be that there's two of a kind, and we really have some spirit in the Drupal community of really having just one project, for one and [inaudible 00:30:34] is really pretty unseen, which was pretty interesting. That might be because Console originally came from the Symfony world. It came kind of over from there, based on the original Symfony Console, then extending to Druapl, but they have a little bit different things, and I've recently learned that also the same people, they all want their own version of things, and they're reinventing the wheel everywhere again, again. It's really, really crazy in a way, if you look at all of those things. So I personally am very glad for stability we have in the Drupal ecosystem of having one tool that does one job great, but in this case maybe Symfony gives some nice innovation, and there was open source in its best [inaudible 00:31:26]
Moshe Weitzman: Right. Yeah, I totally agree with that. I mean, I think it would be better if it was one tool, but certainly there were large contributions made by that team to show us what a command line tool for Drupal 8 could be, what building out on top of Symfony Console it could be. So it's all turned out great.
Preston So: And I think we can all agree that the inspiration that Drush has provided for so many people, including the Drupal console team, something that we cannot discount at all. I'm curious though, I want to go in a different direction here now to talk about some of the ways in which Moshe, you've been working on Drush for an incredibly long time now, have a very large amount of background in it, and just sort of are immersed in it constantly. What are some of the things, from your insider's perspective, that Drush could improve on, and what are some of the advancements that you'd like to see in the Drush project that other people can work on, or that are initiatives that you would love to see happen?
Moshe Weitzman: Yeah, so I think that the current talking point is really around Drush in core Drupal. And what we mean in particular there, I guess every person might mean something different, but Drupal already has two commands in it, its command line commands. So there's the kernel of an idea there. The commands are quick Drupal, and site install. Or, quick start and site install. And they're really simplistic implementations of those things. I think the site install only installs on SQ Lite database, and doesn't install from config, and doesn't do this and that that dress was because it's 10 years ahead.
Moshe Weitzman: But I'm interested in that initiative. I've shared some thoughts with the maintainers about how we can get there. We have now recently Drupal Project, the starter template for new Drupal sites has been deprecated in favor of something called a core project, or core recommended project. I can't remember exactly how it is, but there's official starter templates for Drupal now, and those bring in our dependencies. I would like to see Drush added to that, first as a suggested dependency, and then ultimately as a required dependency of the starter kit, people could then take it out if they wanted to
Moshe Weitzman: And so you the core development process is quite long, quite nitpicky, and so I have some desires to go to jump into it, and some hesitations about jumping into it. But I think that getting Drush in as a dependency of Drupal would be fantastic in those templates. There's a set of key commands that have been identified in this issue on drupal.org, we'll put that issue in the show notes here, that would definitely live inside of core, so install, enable, and uninstalling of modules. That kind of stuff would probably be just Drupal core commands.
Fabian Franz: Clearing too?
Moshe Weitzman: Which one?
Fabian Franz: Cache clearing. Would cache clearing also [crosstalk 00:35:47]
Moshe Weitzman: Yeah, cache clear. I think user login would be a good candidate too, yeah.
Fabian Franz: That sounds amazing to just have like a core of commands direct to the central pull available. The start having to do anything more, but also probably decrease. No, it would increase developer experience, and decrease beginner frustration because they have everything they need directly in their fingertips. Very cool.
Moshe Weitzman: Yeah, it would be cool. If you start with the Drupal project you also have Drush and all its commands right from the beginning. So in a sense, it's an experience improvement. In a sense, it's not an experience improvement. In fact, you would now have the site install [inaudible 00:36:38] or the site install of Drush which does more, and we'd have to avoid people getting confused about what they should use again. So there's definitely a suite of possibilities, and we want to end up somewhere where people are happy and not confused, and can do the things they want to do. So let's talk about it in that issue.
Preston So: Yeah, I think that's a wonderful way for folks to get involved, and I would love to see a lot more of the Drush functionality available just right out of the box in any core Drupal installation. I'm curious, though, one of the other things that I know, beyond some of these ideas around reconciliation of a lot of the different approaches that we see. What are some of the missing features, or have you gotten a lot of feature requests in particular for let's say completely new ideas, or completely new things that people would like to see within Drush? Is that something that you've heard or, or is it primarily more about getting Drush in the core at this point that you and Greg have in terms of vision?
Moshe Weitzman: I think that the rate of feature requests has slowed down over the years. Maybe we're getting to be an old fogy project like Apache that doesn't really change, and does what it needs to do. So we will keep up with Drupal. We're already compatible with Drupal 9. We run tests against Drupal 9. Every PR is tested against Drupal 9. So we are cutting edge in that respect, to make sure we're working with the latest Drupal, and there is a fair amount of maintenance that goes with that. But new features, we don't have too many that are planned right now.
Preston So: How about you Fabian? Do you have any kind of dream features that you'd like to see? I mean, this is your chance. You got Moshe right here on the call
Fabian Franz: Actually, I think, I'm not sure. Maybe it's there already. Is there something for invalidating cache tag [inaudible 00:39:00] in Drush?
Moshe Weitzman: No. There's nothing for invalidating by tag. I actually wanted that recently, and I used PHP eval command in order to do it, so I think that would be a reasonable enhancement for the cache commands, yeah.
Michael Meyers: Yeah, when's Drush going to build my site for me?
Moshe Weitzman: Yeah, it's more designed as an accelerator, but yeah, we could throw in a little AI, and maybe some scrum process, and we could build a site for you.
Preston So: Let's not forget about the cryptocurrency miner. We need that in Drush, too.
Moshe Weitzman: Oh, right, yeah. It'll be self-funding.
Preston So: Well, we're just about coming up to the end of our time here. So I wanted to really thank you of course Moshe, for joining us today, but I wanted to also ask, how can people get involved? I think a lot of us are interested in helping out with some of the issues in the Drush project. What would your recommendations and tips for those of us who are interested in getting our hands dirty, and working on some of those bug reports, or some of the issues that you've got in the queue?
Moshe Weitzman: Yeah, well I want to encourage people to keep writing documentation. That can be... Documentation in our repo is great but can also be just write blog posts about Drush. Write tutorials about Drush. I think that people who are new to command line can sometimes struggle with how to get started. So stuff that is step-by-step tutorials is really valuable for the community. So definitely write those. If you do write something and post it on the web, you can open up an issue for Drush to add a link to it.
Moshe Weitzman: I'd be happy to add links to that stuff from our docs. And in addition to the tutorials, and documentations, and videos, and conference talks about Drush, you can go into the issue queue, and go and find bugs and feature requests and make PRs for them. Lots of people do that, and it's a really great way to contribute. We're a welcoming project, and the people who contribute a lot get rewarded. They become co-maintainers in some cases. So yeah, if you love Drush, consider giving in that way.
Preston So: Wonderful. Well, I know that a lot of folks watching this will probably go and check it out and see if there's anything they can contribute to. Any last words, by the way, Moshe or Fabian about Drush? Any parting thoughts?
Fabian Franz: Yeah, so most, thank you so much on behalf of the whole Drupal community for maintaining this tool for so long. It's been really great, and I think it's great that it goes into a stability phase, et cetera, and is there for everyone to just use and it works. And what more could you dream of a tool?
Preston So: I agree 100%. I don't think any of us can imagine a Drupal without Drush.
Moshe Weitzman: Well, yeah, I appreciate it guys, and thanks to you and thanks to the community for contributing to it, and making it great.
Preston So: Thank you, Moshe, and once again, I want to thank our guests today, Michael Meyers, Fabian Franz, and Moshe Weitzman. By the way, we post all of these tag team talks at tag1.com/tagteamtalks. All the links we mentioned today, including that issue that Moshe pointed out just a couple minutes ago, are going to be posted online with this talk. So please feel free to check out tag1.com for all of your information related to this. And there'll be more content coming out about Drush 10 very soon, so please watch your tag1.com tab that you keep pinned on your Chrome and Firefox tabs, I know you do.
Preston So: If you enjoyed this talk, please remember to upvote, subscribe, share it with others, share it with your friends on the street, share it with anyone that you would like to talk to about Drush. As always, we love to hear your feedback, and if you have any topics you'd love to talk about, you'd love us to talk about with regards to the Tag1 Team Talks, please send us an email tagteamtalks@tag1consulting.com, and once again, I want to express my fond gratitude to my dear friends, Moshe, Fabian and Mike today. Thank you so much for joining us, and wherever you are in the world. Until next time, thank you.