DuPont presents the Cavalcade of America. This evening's program in the Cavalcade of America presented by DuPont relates some interesting stories about American artists, especially appropriate at this time because this is art week in the state of Delaware and in many other communities. Art week activities include exhibits of paintings, lectures on various art subjects, concerts, operettas and dramatic presentations. Everyone has the urge to create, to express artistic talent. This whole movement for a keener appreciation of things that are beautiful and for the development of good taste in all the art is very much in keeping with the spirit of the creative work of DuPont people throughout the country, as expressed in their pledge, better things for a better living through chemistry. In this evening's episode of the Cavalcade of America, we hear of the mothers of two famous American artists. And as Mother's Day will be celebrated next Sunday, May 10th, the DuPont Cavalcade Orchestra plays as an overture, a special arrangement of Dvorak, songs my mother taught me and Brahms lullaby. In 1738, in this gray field stone farmhouse, the Quaker Benjamin West, America's first great artist, was born. At the age of six, we find him watching a friendly Indian who was busily engaged decorating himself and his wigwam with colors. What are you doing, Lakeoma? Now if I don't ask questions. What? I didn't know an Indian could draw pictures too. You're putting the same war paint on your wigwam you put on yourself. How do you get them? They come from ground. Sometimes make pictures. You stick. Sometimes use hair tied together like this. That's a brush. Show me how to make one. You take this. Me make another. Oh, thanks, Lakeoma. Will you show me how to make colors too? Me busy. You take some you like. Me make more later. Be much busy now. I won't bother you anymore, Lakeoma. I'm going to make pictures myself. Good. The boy of six is usually very much in evidence around the house. Mrs. West does not hear her son's happy voice and running feet. She becomes alarmed and seeing Lakeoma passing calls to him from the steps of the house. Lakeoma! Lakeoma! Have you seen my son, Benjamin? No. See him long time. Oh, he must be up to some mischief. I haven't heard a sound from him in the past hour. Maybe he go in first. Wait, Lakeoma.  Yes, me look. Why, Benjamin, what does he hear with the baby? Nothing, mother. Would he tell me a false thing? What has he there behind my back? Will he punish me, mother? Hand it to me and he will see. Here it is, mother. They say it's nothing but... Benjamin, what has he done? You find boy? Yes, and look, Lakeoma. Look what he has done. Oh, he makes picture of baby. Good picture. Look, the shape of the head, the mouth. Why, Ben, where did he learn to paint and draw? I watched Lakeoma. Then I want to do it. I don't know what our friend's meeting would say to this. But what does he say, mother? They say I like it well, Benjamin, and I'll keep it always. So Benjamin West was allowed to develop his talent for drawing and painting. At the age of 22, he was given a scholarship and sent to Italy to study art. Three years later, he arrived in London, and his work was admired by the King and by the great English portrait painter Joshua Reynolds. Gilbert Stewart, later called the painter of presidents, and our historic artist John Trumbull were two of his pupils. One evening in studio in London, Gilbert Stewart brings another young American artist to call on West. Good evening, Mr. West. Good evening, Mr. Stewart. I'd like to present a print of mine from the colonies, Mr. Charles Wilson Peale of Maryland. He's an artist, too, and that's... Then he's very welcome. Come in, Mr. Peale. My home is yours. Thank you, sir. You're very kind. Do you intend to stay long in London, Mr. Peale? Long enough, sir, to show you my work and benefit by your criticism, if you'll be good enough to give it. Well, I'll be delighted to help a fellow American all I can. I had see your work this very evening if there weren't another matter on my mind. You mean the academy you've started, sir? Yes, sir. The Royal Academy, we call it. Isn't that wonderful, Peale? The first British art academy founded by an American. Yes, indeed. But I never could understand why you were not elected as first president, Mr. West. They spoke of it, but I believe we should have the greatest of us for our first president. And that meant only one artist in England, Joshua Reynolds. The inspiration and purpose of this art school fired the imagination of Charles Wilson Peale. He tried, in 1791, to found an art school in Philadelphia, but the project failed. He had a remarkable gallery of historical portraits, which were assembled and exhibited to the public in the Philosophical Society's building on Independence Square. In 1802, the museum outgrew its old quarters and moved to a new home, Independence Hall itself. We find Charles Peale arranging his enlarged collection with the help of his talented son, Rembrandt Hill. But where are you going to hang your portraits, Father? The whole long wall is covered with the cases of your rare birds and animals. Well, I'll bring the ladder over here, then. We'll hang them above the cases at the far end of the room. Well, how about this end of the room, Father? That's where I'm going to have my new art school. Oh, Father, I should think you had enough of that. And anyway, where are you going to find models to pose for life class? This is the Quaker City, you know. If I have to, I'll pose myself. I'm determined, son, that America should have an art school like Benjamin West in London. You know, I'm with you, Father, all the time, but just the two of us aren't enough. William Rush is with us. Oh, and even though he is the first American sculptor, isn't he too busy with city affairs? I hope not. Charles! Charles! Well, Will. Hello, Mr. Rush. We're just speaking of you, sir. I've got great news. A commission for a new statue? No. A whole gallery of them for you. For me? Yes. I've just been to see Judge Hopkinson and Mr. Clymer. George Clymer? Yes. And he's with us. He's going to get a group of his lawyer friends and merchants to contribute to a fund for buying a lot of casts from the antique. Wonderful. Oh, but we'll have to have a school and a gallery. Well, they'll help us to organize one. With a man of climate's prestige, a sign of the Declaration of Independence, why, we ought to be able to organize anything. We'll make him first president of our academy. Oh, Father, go easy. We haven't even a name for it yet. Oh, yes, I have. What is it? The Pennsylvania Academy of the Fine Arts. Good. Charles Wilson Field with the aid of George Clymer was instrumental in founding the first art academy in the United States. And at its first meeting, an honorary membership was voted to the American who was responsible for the founding of the British Royal Academy, Benjamin West. Applicate of America presented by DuPont moves on. For a long time, most American artists were obliged to find their inspiration and make their livings in London and Paris. But always in their exile, the American traits in their personalities and work were distinctive and set them apart from all others. This was especially so in the case of James Abbott McNeil Whistler. In 1871, Whistler lives in his home called the White House in Chelsea, London. He is beginning a new painting. His colors are spread on a table beside the easel, for he never used a palette. And he is placing the sitter in position. There now. Are you quite comfortable, Mother? The chair is a little high, Jimmy. Oh? Could I have a foot stool? Why, certainly. Now, is that better? Yes. Thank you. But, Jimmy, you've got your canvas wrong with your belt. You're going to paint on the back of it. Why not? It's a good surface. Besides, there's a girl painted on the front of it. I don't know why you want to paint no lady like me at all. Well, I'll tell you, Mother, your black dress and nice new lace makes such a lovely arrangement against the gray of the wall I couldn't resist it. Oh, I see. I'm just another arrangement. It doesn't make any difference what I look like. Not a bit.  Well, if you paint me like one of your arrangements of the River Thames by moonlight, no one will know who I am. Ah, but they'll know who did it. Why do you make them so vague and hazy, Jimmy? Because there's usually a haze over the water. Anyone can see it except those blind academic painters. That's why I don't give the canvases any definite titles, but call them my moonlights. Your friend Leyland was in today and saw one. Oh? He called it a knock turn. Well, Mother, that's perfect. So shall I. And I'll compose a whole series of them. Now, just relax, Mother. Be quite as comfortable as you can. Oh, yes, Jimmy. No one will buy your knock turns. They don't tell any story. Of course not. But they'll be beautiful harmonies of form and color. The critics will not think of them as pictures at all. The critics, huh? Those pen wipers. Of course they won't think about them at all. They can't possibly understand. Because my pictures are works of art. We know that, dear. What are you thinking of, Mummy? Is my expression disturbing you, Jimmy? I want to understand it. So millions of people can learn to love it just as it is. Just as I do now. Oh, Jimmy. I wish you'd show this lovable side of yourself to the world. Oh. They'd lose interest in me if I did. They'd want to think of me as the butterfly with a scorpion sting. Oh, but is that what you were thinking about? No. I was thinking about the past, about you, Jimmy. Long ago. When you used to draw pictures of people on the maps you were making. And got fired for it. No, Jimmy. You were discharged because you never went to work on time. In fact, often you never went to work at all.  I'm thankful, Jimmy. Thanks? What on earth for? To be the mother of such a great artist. And such a dear son. When Whistler sent a painting to the annual exhibition at the Royal Academy, they either rejected it or hung it obscurely. In 1872, he sent them the portrait of his mother. As usual, a storm of protest broke out in the consulate of the academy. Whistler's old friend and a great portrait painter, Sir William Boxle, dares to speak in its favor. I consider the work of genius, gentlemen. But, Sir William, you cannot hang anything as revolutionary as that. The academy must stand only for the best in art and good taste. Would you call it bad art if it had the name of a Dutch master on it? It is in the same spirit. It's a great painting. I, for one, positively refuse to approve it in this impudent American upstart. He hasn't even the common decency to honor his own mother. How can you possibly look at the old lady's face and think such a thing? But look at the title he sends with it, gibberish, cause it an arrangement in grey and black. And so it is. And it's high time we thought again in terms of color instead of turning out pictures for picture books. It's no use, Sir William. We're all opposed. Let's throw it out and waste no more time. There are other more important canvases. Well, I think not. And I'll never have it said I voted against this great painting. If it is not accepted and hung, it will be resigned from the council. Sir William, I'm sure, Sir William, you're not serious. I am not only serious. I'm right. It's not worth the price of Sir William's resignation, gentlemen. I vote we hang it. We'll hang it, Sir William. Gentlemen, someday you'll find you have done yourselves great honor. Sir William Bottsall was right. For today, the portrait of Whistler's mother, loved and admired all over the world, is the first painting in the National Gallery of France. The first work of an American artist to hang in the loo. In 1877, Whistler was invited to send eight paintings to a special exhibition at the Grosvenor Galleries in London. The exhibition created great excitement for it contained the first of the great nocturnes. To most people who thought of paintings only as pictures that must tell a story, these little paintings seem lacking in sense. They especially infuriated one self-appointed custodian of the public taste, a professor at Oxford, a writer of great power and venom, John Ruskin.  While the exhibition is on, Whistler drops in one evening at his club. I say there, Whistler. Oh, hello, Barton. Have you seen the latest number of Paul's clavichera? Isn't that the sheet Ruskin put out? Yes, his dirty linen robber. He has a few smudges in it about you. Oh, splendid. It shows I'm still informed. Otherwise, I'm not interested. I think you might be. Let me read a bit of it to you. Yes, do. Ruskin says, Sir Coot's linty ought not to admit it works into the gallery in which the ill-educated conceit of the artist so nearly approaches the aspect of willful imposter. I have seen and heard much of cockney impudence before now, but never expected to hear a cockscomb art 200 guineas for flinging a pot of paint in the public space. Well, what do you say to that, eh? I think it's the most debased style of criticism I've had thrown at me. Sounds rather like libel, don't you think? Well, that is what I mean to find out. Whistler was in deadly earnest. He meant to make a test case of how far a critic can go in robbing an artist of his daily bread. He sued Ruskin for libel and claimed damages. The English artists were in a panic and excused themselves from bearing witness on either side, except a staunch, embarrassed view. The famous case comes to trial in the Exchequer Chamber, Westminster, London, and the Court of Queens bench before Baron Huddleston. Order, please! Order! Continue for the plaintiff, Mr. Perry. Only one more word, my lord. An end point is that Mr. Ruskin not only criticizes the art qualities of my client's paintings, but it's priced as well, which is none of a critic's business. That is all. Sir John Holker, you may proceed with the cross examination. Mr. Whistler, sir, what do you call these night paintings? Nocturnes. What's your definition of that word? It's an arrangement of line, form and color, first. And I make use of any incident of it, which will bring about a symmetrical result. Is this the one you call Nocturn in black and gold, the falling rocket? Yes. And the one Mr. Ruskin calls a pot of paint slung at the public. Order, please! Order! Where was it painted? At Cremon. Oh, but holding it upside down. Oh, of course. It's not a view of Cremon. If I called it a view of Cremon, it would only disappoint all beholders. No, it is an artistic arrangement. Why do you call Mr. Irving an arrangement in black? Oh, but I don't. That's what I call the picture. Order! Did you take much time to paint The Nocturn in black and gold? About two days? End for that. The work of two days? You dare ask two hundred guineas? No. I ask that for the knowledge of a lifetime. Do you offer this picture to the public as one of particular beauty, fairly worth two hundred guineas? I have sold others for that amount? I offer this as a work conscientiously executed. I think it's worth the money. And I'd hold my reputation on it as I would upon any of my other works. As, for example, this Nocturn in blue and silver? Yes. What does it represent? Battersea Bridge by Moonlight. Order, please. Mr. Whistler. Sir. I can't tell whether those are people on top of the bridge and how in the name of heaven they could get office. My lord, the picture is simply a representation of moonlight. My whole scheme was only to bring about a certain harmony of color. How long did it take you to paint that picture? I completed it in one day after having arranged the idea in my mind. Oh, bad deal. My lord, my lord, I protest. As a painter and artist, Mr. Whistler has earned a reputation in the United States. He is not merely a painter. He has likewise distinguished himself as a nature. And why he should be subjected to this ignominious... Art history of first importance. So many people did not take it seriously at the time. The jury brought in a verdict for Whistler. The damages were nominal, only one fathering. But it was a complete moral victory for Whistler. Some years later, Whistler met Hoker, Ruskin's lawyer at the club, and asked him about the case. You know, I never could understand, Hoker, why Ruskin didn't appear in person against me. I wouldn't let him, Jimmy. It was hard enough as it was to save him from paying you heavy damages. Yes. Yes, why didn't the jury award me more? You know, Ruskin singled out for attack the only picture in the lot I had for sale. It hurt my prices for years. Yes. But your lawyer didn't emphasize that for the jury, which is too bad, because Ruskin was wrong and should have been punished. Oh. Then why did you appear for it? Because he asked me to, and you didn't. I see. The only reason was because I couldn't afford you.  I, gladly, have been on your side for nothing. A little late to find that out. I don't know. Here's Barksville. Oh, he seems excited about something. Jimmy. Jimmy, I've just got the greatest news. Hello, Hoker. Well, well, what's the burning noise, sir, William? It's about your picture. I've done a sea bridge by moonlight. What again? Yes, we were just discussing it. What's the matter with it now? Nothing's the matter with it. Haven't you heard the news? No. Well, I'm glad I'm the one to tell you. It's been sold. What? The National Fund bought it. Where? The National Fund. Why? To hang in the National Gallery. Yeah. I hope, Jimmy, you've got your 200 guineas for it. 200? They paid 2,000. What's that? I've got a bargain. Brilliant. Well, how do you like that, Jimmy? Well, there's something I'd like better. What's that? I'd like to see Ruskin's face when he hears of it. Fleur's victory was complete. And in our own capital, Washington, D.C., there is an entire building dedicated to Whistler's memory. In it is the famous peacock room he designed for layland and contains many of his beautiful arrangements and nocturnes. Notable among those who brought American art to international fame and glory, we accord him his place in the cavalcade of America. Better things for better living used by DuPont Chemists has true applications for the art of making books. The chemist, through his efforts to create more beautiful and lasting paper, inks, and binding material, has helped to make books, fitting and long-enduring vehicles for the genius of authors. Not far from Washington's revolutionary headquarters in historical Newburgh on Hudson, New York, are made DuPont Fabricoid and PX cloth, two of the best known materials for binding books. To this plant and laboratory have come on annual pilgrimages, the leading bookbinders of America, each one a master craftsman in his own right, to see what is new in the way of DuPont contributions to better books. Both Fabricoid and PX cloth bookbinding materials are composed of a woven textile base coated with durable cellulose compound. An almost limitless range of color and surface effects afford the book designer ample scope for his talent. Important, too, is the fact that books bound in these DuPont materials are washable and resist the attacks of heat, moisture, and hungry insect. More and more public schools of America are coming to see the wisdom of furnishing students with books bound in these washable, beautiful, and enduring materials. The unsanitary pen and finger mark schoolbook bindings of the past are rapidly disappearing thanks to the chemist. A man-made material possessing all of these assets naturally finds broad uses than in bookbinding. Fabricoid also serves long and well as furniture upholstery, luggage covering in women's handbags, and his cleanable tablecloth. In a slightly different form, this coated textile is known as DuPont Tom team, the finest of all washable window shade materials. Fabricoid represents one more achievement of modern chemical research and illustrates the phrase used by DuPont chemists, better things for better living through chemistry. Fillers of the soil, a story of American farming, will be heard next week at the same time when DuPont again presents the Cavalcade of America. This is the Columbia Broadcasting System. UADC, New York.


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.  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.  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?  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.  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?  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.  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.  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.  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.  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.  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.