Episode 174 of The SitePoint Podcast is now available! This week Kevin Dees (@kevindees) interviews Ronnie Taylor (@rontec76) about the world of Drupal and how to make the most of what it has to offer.
Download this Episode
You can download this episode as a standalone MP3 file. Here’s the link:
SitePoint Podcast #174: Drupal with Ronnie Taylor(MP3, 46:22, 44.6MB)
Episode Summary
Kevin and Ronnie go through how Drupal is structured, and how that can suit different types of project, and how a user new to Drupal can into using it for the first time. They then cover some more advanced tools you can use with Drupal and how this can improve workflow.
Browse the full list of links referenced in the show at http://delicious.com/sitepointpodcast/174.
Interview Transcript
Kevin: All right. So I am here with Ronnie Taylor at CoWork Greenville and today we’re going to talk about this mysterious system called Drupal. But before we jump into Drupal, I’d like to introduce you to Ronnie. Ronnie is one of my friends here at CoWork Greenville, and we get to talk about code all the time. I was like, “Why don’t we just talk about this code stuff on the SitePoint podcast?” So here we are. Ronnie, tell me a little bit about yourself, how you got started in this web world.
Ronnie: It’s sort of a common story. I started out doing other things and sort of evolved into doing web work full-time. I have an IT and engineering background and then worked in the newspaper world for a while. Starting learning web stuff on the side on my own and just it sort of evolved from there, started taking on customers and so eventually jumped out into the freelance world. I’ve been doing this for a while. I started full-time back in 2004 and I’ve gone through a couple iterations of business. So, that’s how I got started.
Kevin: You did freelancing for a while, right? Now, you’re kind of migrating into different things?
Ronnie: Yeah, I actually have just taken a full-time job with one of my clients. I’m doing a lot of Drupal stuff for them, but also expand into some Rails and some other stuff. But, yes, I’ve been doing freelance for quite a long time.
Kevin: Very cool. So what made you pick Drupal as a platform? Tell us why we should consider that as a viable solution outside of something like, say WordPress, which is extremely popular, has a lot of plug-ins out there. Out there, there are many, many, many reasons to use WordPress and I think Drupal gets overlooked, but you’ve chosen Drupal and, I think, for some really good reasons. I like to use Drupal on specific projects. So what are the reasons that you use Drupal? What drew you to it?
Ronnie: I would say that it’s – and then we’ll talk about some of these things later as well – but the modularity of it, which allows for a high level of customization even down into the core parts of Drupal. So, it allows it to be very flexible and almost function as a framework, whereas some other systems I’ve used, they’re inherently geared towards just being specific things and specific types of sites. So, it’s the flexibility is the short answer
Kevin: Right.
Ronnie: Then the community on top of that. There’s a huge number of modules and there’s a huge community that’s very friendly and willing to help out.
Kevin: So, you’re mentioning this community that was online, a part of the reason why you picked Drupal. You picked Drupal starting out near its very beginning, Drupal 4?
Ronnie: Yeah, I started working with Drupal it was 4.5. It was back when I first worked on a community site and built my first modules.
Kevin: That’s very cool. So you have just a little bit of experience in using Drupal?
Ronnie: I’ve used it a few times.
Kevin: So how can somebody go about getting involved in that community that you’re talking about and just learning Drupal? Because, at some point, you’ve got to dig in and learn – I don’t want to keep bringing up WordPress a lot – but it’s true, WordPress is fairly easy to learn for, say, somebody starting out, whereas Drupal is kind of this massive system.
So, what does somebody have to do to kind of break that barrier of just the overall learning curve of Drupal to really step into a platform that’s powerful enough to run something as advanced as maybe a web app?
Ronnie: I think that in every new endeavor I’m learning that starting very basic is a really good way. So, starting at drupal.org, they have a great handbook and it’s evolved and become even more of robust over the years. So, if you’re just getting involved and starting in the newer Drupal 7 and that kind of thing. There’s just a ton of great, basic information on how to get started, how to install, what’s the theme look like, that kind of thing.
The forums on Drupal.org are a great place. So, if you just dived in and, say, downloaded it and started installing, running into questions and things like that, those forums are a fantastic place. Then, you can get a little bit nerdier. There are always IRC channels. There’s a ton of participation in IRC channels and I find people very friendly and willing to answer questions, things like that.
Kevin: Are there any video podcasts or podcasts that you know of that would stand out in your mind? I know one, for me, is the Mustardseed podcast. Are there any others out there that might be helpful and helping somebody not only learn Drupal, but kind of get involved in some of those modules? Because part of Drupal is discovering the modules that are going to help you, so module discovery that kind of thing as well.
Ronnie: Yeah, I’m not sure which ones are still around. I’m kind of a little bit of a weirdo. I don’t actually like video podcasts.
Kevin: It’s a good thing this is audio.
Ronnie: Yeah.
Kevin: You might not want to be on the show.
Ronnie: No. It’s funny. I don’t really listen to many. There was a “Got Drupal?”, I think, was one. There’s sort of like a “Drupal Therapy” one.
Kevin: Yeah, that’s a really good one.
Ronnie: That had some great posts. I haven’t looked at any of those in a while but Google’s always a good tool. It’s pretty easy to find this stuff.
Kevin: So you’re saying Google it, right?
Ronnie: That’s right.
Kevin: But, yeah, you mentioned a really good one, “Got Drupal?”. That’s a really good videocast series. Again, the Mustardseed podcasts are really good. Those can really help kick them off. I know they helped me when I started. The thing is that you got started so early, right?
Ronnie: Yeah, I actually predate video podcasts.
Kevin: Right. So it’s not exactly like you’re going to look these things up to learn something. But it’s good that those things are out there if you need to learn them. So I really want to talk about some of the advanced parts of Drupal and the underlying things that make it stand out above other systems.
Part of that is the focus that Drupal has on its modularity that you were talking about earlier. How deep is that idea embedded into Drupal? Maybe tell us a little bit about what even a modular system means to Drupal?
Ronnie: The concept of modularity in Drupal permeates all the way to its very core. It’s really the foundation of how it’s built and its power is, again, one of the main reasons I chose it. So, “hooks” is a term. As you get more involved with Drupal you’ll hear the term “hooks” and that’s the under-the-hood piece.
Kevin: Right.
Ronnie: That’s really what makes a module a module in a sense. A hook is a piece down to core functionality, say, actions that pertain to users and things like that or creating content.
Kevin: Yep.
Ronnie: So it allows you to get on a very low level in the inner workings of the system and change how it works. That’s the gist of it.
Kevin: Right.
Ronnie: Is that I can hook into a user registration process, I can hook into a content creation process, and I can do very custom things that suit my specific use case and needs. Whereas in many other systems, the functionality sort of just is what it is. There are people who do all kinds of work-arounds to force change that functionality. But it’s a very unnatural feeling and it often ends up for difficult to maintain code bases and things like that.
Kevin: Right. So tell me a little bit more about this hooking mechanism in Drupal and how that relates to an everyday kind of process. Like, where would I want to use a hook? Or maybe if I’m making a module – because, like you’re saying, those hooks are kind of a core piece of modules – maybe, how does that interoperate in a workflow?
Ronnie: I’ll give you probably one of the most common examples. Pretty much every Drupal site that I do now, I’ll end up writing a custom module for it, something so basic as customizing forms, for example. So, a common thing that I’ll do in Drupal site, say, some kind of community-related site, I’ll have a user profile and then I’ll have custom fields associated with that profile.
Kevin: Right.
Ronnie: Then we might want to display them in a certain order on the registration form and things like that. So there are portions of that kind of process where the wording of the fields is not drag and drop, for instance.
Kevin: Right.
Ronnie: Or, say I might want to change the label of certain fields and things like that, then I can use hook form alter is a very, very common one. So that’s a hook that lets me alter the process of generating a form in Drupal.
Kevin: Right. So you can go in and basically with a function and just a set of parameters and an array, you can say, “I want this label. I want this ID. I want this class,” all this type of input field or whatever within the actual output that Drupal gives you, right?
Ronnie: That’s correct.
Kevin: So, I think that’s something really powerful that’s available for almost everything in Drupal.
Ronnie: It is, right.
Kevin: So I think that’s part of what sets Drupal apart from WordPress is that WordPress has a lot of hooks. It has, basically I call them, actions and filters in WordPress and that’s in there for a lot of things. But there are certain things that there aren’t exactly hooks and stuff for. Whereas, Drupal is based solely around that idea, right?
Ronnie: Right.
Kevin: So there’s a lot more control and feature richness in that, I would say, if you agree with me?
Ronnie: Yeah.
Kevin: Tell me a little bit more about modules on a basic level. What is the process like for not only finding those, but installing them? Maybe what are some modules that you use on a daily basis that you just can’t live without, that you have to have in a project that somebody listening to this can say, “Okay, you mentioned this. I’m going to go Google it and learn from there”?
Ronnie: There are a couple of word course modules. So back before Drupal 7, I had a standard list of modules and that’s kind of changed a bit in Drupal 7 because some things were so popular that Lewis decided to bring some of that functionality into core Drupal. So CCK has always been one…
Kevin: Right. What does that provide?
Ronnie: It stands for Content Construction Kit. So it allows you to easily create custom content types. So you might be building a site, for instance, where you want to post many different types of content, so maybe blog posts or video posts that have video files and things attached to them. Those are some examples.
So, CCK lets you construct those content types so it lets you choose what fields you want to have on them and put constraints on those sort of things and it also generates the forms that you would use to create them. So that functionality, most of that, has been rolled into core Drupal.
Kevin: From 6 to 7?
Ronnie: So, from 6 to 7, that’s correct. But even in 7.1, another powerful workhorse module would be Views, for instance. That is a module you’d use – once you, say, you have a bunch of content types and you’ve got a bunch of content in your site, you want to create various displays that information. So, Views is a sort of graphical way to pull together a display for your data.
Kevin: Right.
Ronnie: So if I want to have a front section of blog posts within my site, I can say, “Just show me all the blog posts. Sort them in this order, this kind of way.”
Kevin: Right.
Ronnie: So it becomes a very friendly way to build on what would otherwise be a complex process to build a complex process.
Kevin: Right. So instead of doing MySQL searches within the database to get a row array…
Ronnie: That’s right, manually writing PHP code in the page to display the posts and that kind of thing, this sort of takes away all of that.
Kevin: Right.
Ronnie: …madness and simplifies it.
Kevin: So I imagine one of the things that come with that is a lack of control over markup, which is true. So what are some tools that people can use to get around that? I know Views has its own templating system. But unless you want to create 20 template files for an advanced site, that’s not exactly ideal. Are there modules out there that kind of help you control markup?
Ronnie: Yeah. Semantic Views is the name of one of those. That’s probably one of the can’t-do-without modules now in any Drupal site, really. Semantic Views module, they’ve done a lot of the work to sort of standardize the process of really cleaning that up. So by default, in Views when you, say, “Generate a listing of content,” there are by default a lot of extra divs and wrappers and markup in there that a lot of people don’t like.
So Semantic Views just is sort of like a filter and just strips all of that out. But it still allows you to do custom templates for just about every piece of the display that you can think of in there. So it’s very powerful and granular.
Kevin: Very cool. So that’s a little bit about modules. I can’t believe I forgot to put this in the questions, but you have these modules that help you add functionality. But then there’s this whole other side to your websites, which is the actual display of the website, which, again, Views helps with, but more along the lines of themeing.
So, are there specific tools out there that help with themeing that you can think of? I know there are some for WordPress. There are parent themes like Genesis, Framework. There are some other ones. I can’t exactly think of a bunch off-hand for WordPress, but are there similar things for Drupal that can help speed up the development of the site?
Ronnie: Yeah, absolutely. There are a ton of them. I’d say a couple of the more popular ones, is there’s Zen, which has been around a long time. It’s essentially like a bare-bones starting framework so you can really quickly download it and install it. Then, there’s even a wizard module for it where you can just create a sub-theme. What that does is it just goes ahead and creates the entire structure of the theme for you, all the CSS file. The most commonly used basic and required template files, things like that.
So Zen is one. A newer and very popular one is Omega theme, which is responsive technologies built into it now, HTML5, a lot of newer stuff, and that’s built on Drupal 7. So, those are a couple of really popular ones that give you a ton of stuff out of the box. You were talking about ways that people that are just learning Drupal can quickly get up to speed. That’s definitely a very, very good way because those themes give you a lot of extra stuff out of the box that you’d have to do manually otherwise if you building a theme from scratch kind of thing.
Kevin: Yeah, absolutely. I think one of the main ways I learned WordPress – I didn’t quite learn Drupal in the same way, I learned WordPress first – and I totally agree with what you’re saying there. Because when I first started using WordPress, the only way I was really able to wrap my mind around things like the loop in WordPress and just the querying of things and how to get menus is I would always be looking in the 2010 theme for WordPress. Like, “Where is this function? What does this do?”
So to have something available like that in Drupal, whereas I’m not going to have total control over my markup at first, I’m not going to have that ace in the hole with my first project, but as I go on, I can build towards that. I think that’s really powerful.
We’ve talked a little bit about what Drupal is, why you chose it, the module side, the granularity of that, theming, but you have all these tools. What sites would you even really want to use Drupal for? Because you have other systems out there that are maybe a little bit easier to use, such as WordPress. WordPress is actually much easier to use than Drupal.
So, you have things like CodeIgniter and Zend framework, and CakePHP, and all these other kind of MVC other frameworks. You have Expression Engine. Why Drupal? What’s a good situation to use Drupal?
Ronnie: First of all, that’s always a tricky question because it’s one of those things that everyone’s going to have a different opinion on. I’ve used Drupal probably for things I shouldn’t have.
Kevin: Right.
Ronnie: I know other people that use Drupal for everything. I think you can use it for everything. But what I would say is community sites are one place that has a huge strength and presence just because a lot of the core features of the users and the roles.
Kevin: Yeah, absolutely.
Ronnie: The ability to create different types of content and to give different groups of people permissions to access and create that content.
Kevin: Talk a little bit about that. I don’t want to jump in too hard on you. But talk a little bit about that permission stuff that you’re talking about right now.
Ronnie: Well, just it’s got a very robust system built into core so that out of the box you can, say, allow different groups of users. Those are called roles. internally you can create these roles and assign permissions. So you can, say, give only the editor role, for instance. In a site where you’re publishing content say, “We’ll allow these people to create the posts and edit the posts,” but they may not have permission to publish them. Maybe that has to be delegated to the publisher role, that sort of thing.
So, it’s just got a very granular system for determining that. Every module that you install typically has some sort of permissions associated with it that you can enable or disable on a per user group type of basis.
Kevin: Right.
Ronnie: So, when you get into a very complex ecosystem…
Kevin: Like a community site?
Ronnie: …a community site, for instance, again, going back to that example, that becomes extremely powerful because then it lets you have a large group of people collaborating and interacting in a way that makes sense and that’s sane.
Kevin: Right.
Ronnie: So, it’s definitely very powerful.
Kevin: Right, and that’s built into things like Views, for example, right? You can control the access to content?
Ronnie: Yeah, absolutely. Say you can, for instance in that context, you could say, create a display… Say you needed to create some sort of admin report or view for administrators in the site. You could build the report of the site data using Views and then you can specifically say, “I only want this group of users to be able to view this content.”
Kevin: Right, which is really cool.
Ronnie: Which is very, very powerful, so then it lets you start doing some pretty complex things really quickly.
Kevin: Right. So you can create a list of, say – you can create /admin/user log in dates, right? Then anybody on the same site can go and view user log in dates just using the Views module.
Ronnie: Right.
Kevin: You don’t have to go find some other module that’s going to do that for you. You can have full control over that. Another thing I’d like to point out with Drupal is that you can use multiple roles per user, correct?
Ronnie: Yes, you can have multiple roles per user.
Kevin: Somebody can be, for example, an editor and maybe they can be moderator, right?
Ronnie: Right, exactly. Yep.
Kevin: Very cool. So, I jumped in the middle of your community example of an example of a site that you would want to use for Drupal. So you were talking about how you had control over the users and that’s why I interrupted you there for a second to kind of go off on a tangent.
Ronnie: That’s okay, yeah.
Kevin: But as an example of a site that would be good using Drupal as the tool of choice, can you keep going down that path of why, outside of just the roles and stuff for the community site and things?
Ronnie: Yeah. I think there are a lot of current, relevant examples too. A lot of bigger companies, you see it happening more and more. So, for example, Twitter, Skype and eBay and a lot of these companies, they have developer sites and various certain customer community sites, things like that where they want to have people coming in and posting requests or posting feedback, things like that. So, you see big companies now using Drupal a lot in that.
Kevin: WhiteHouse.gov, right?
Ronnie: Yeah. WhiteHouse.gov is built on it. Yeah, so it’s between the permissioning – and I think because of the nature of the Drupal community, it is just inherently social. So, there are a lot of very stable, robust modules that have been contributed for the various social web type thing, so hooking your site up to Twitter. So, say, maybe when I post content on my site that automatically tweets, or integrating to Facebook, and all of these various things.
So, in addition to just having a lot of user interaction stuff built into the core system itself, there are a ton of contributing community modules that provide a lot of really great social functionality. I think that for me that’s sort of another key thing that I think about when choosing to implement Drupal. Is in a community site, you have a lot of users interacting together, often in complex ways. So, I think that’s one of Drupal’s strengths.
So, it doesn’t just have to be a community site but if you’re going to have a site with a significant amount of data that’s going to have a significant group of users… When I say “significant”, maybe if you’re going to have a group of, say, 15 to 20 people interacting and managing content and managing aspects of a website that’s pretty big.
Kevin: Right.
Ronnie: So, where there are times where…
Kevin: You’re not dealing with a small site that’s going to have one user that comes through once a month to update.
Ronnie: That’s right.
Ronnie: That would kind of segue into that, the side of when not to use Drupal.
Kevin: Right.
Ronnie: I’d say from my experience, I’ve learned that if I’m doing a one or two-page Mom and Pop site, they may or may not ever want to edit the content themselves, that kind of thing, that’s time to not use Drupal. Frankly, there are a lot of those times where it’s not used to teach any CMS really at that point.
But I think when you do get into the place where you, say, want to have a CMS that’s still the very, very simple site, very small, single-site owner, I think Drupal can be a little bit much sometimes for those folks, depending on who’s setting it up.
Kevin: Yeah, that’s true.
Ronnie: Because one of the caveats is I have a very…
Kevin: Does the person know what they’re doing, or do they not?
Ronnie: Well, I have a very standardized way that I set up all of my Drupal installations on the administrative side and I feel very good about that. But I’ve taken over some Drupal sites that that was not the case.
Kevin: Yeah, it’s always into no matter what platform you use, you can’t let the experience that you’ve had due to another developer guide that experience, I would say. Because I’ve had a lot of people come to me, and they say, “I just hate WordPress. It’s so awful. It does all these terrible things. It doesn’t allow you to create custom fields and custom post types,” when in fact, it does.
Ronnie: Yeah.
Kevin: It’s just your experience hasn’t been there.
Ronnie: Right.
Kevin: So, I think part of that animosity is also there for Drupal, right?
Ronnie: Sure, absolutely. Well, some of the negatives you’ll hear is the learning curve. So, even though there are a ton of resources, Drupal is built on a different paradigm than many systems, the whole hook system and modularity of it and there are some elements that are fairly complex. So, I think that’s where some of the negative stigma might come from.
Then also too, there are a lot of people that experience a Drupal or WordPress or any system for that matter and they sort of always scratch the surface and don’t really see the community and see the development beyond going, striving for improvement. I think that’s one thing I definitely recommend is to really try to get involved, look a little bit deeper and then that’s when you really see the power and it starts to make sense, I think.
Kevin: Yeah, very cool. Well, we have enough time to go in and talk about some really advanced stuff, which I am very excited. This is what really what I’m excited about talking about. But just to continue to recap along with way, we’ve talked about what Drupal means to you, the modules that you can use to get started, the resources that you can use to get started, themes that you can use to get started.
All this stuff is kind of basic, but there is a whole other level to Drupal that it just takes Drupal from a CMS to just an amazing platform for developing websites rapidly, even though you might not think that because of the learning curve that’s required. One of these tools that allow Drupal to become a platform like that is Drush, and there is a lot of module integration with Drush. There are multiple modules that use Drush.
But before I get too excited, or we get too excited about this whole Drush thing, if you could explain what Drush is and what it means to Drupal? Big question.
Ronnie: Big question, so what is Drush? The simple answer is Drush is a set of command line utilities.
Kevin: Right, so you go to the terminal…
Ronnie: You got to a terminal screen and you type in commands to perform actions in a Drupal site versus going into a browser and clicking buttons, and waiting and browsing, and that kind of thing. I would describe it as the Swiss Army knife of Drupal tools, if you will, because it’s not even a proper module, in a sense. You don’t go and install Drush in the control panel like you would with another module. You just essentially download it and there’s a little bit of configuration. It’s pretty simple.
Kevin: Right. There are plain tutorials. That means Google it, right? Google to install?
Ronnie: Yeah, always Google. Yeah, but definitely when you get into the discussion of Drush that really starts showing the power of Drupal and what the community has done, because it is very technical once you really get to the Drush one. So, the point is you can do things like, instead of going and manually downloading… Say I have five modules that I want to install and enable, for example.
Kevin: Right.
Ronnie: That’s kind of the “Hello, world!” once you really start to understand the power of Drush and see that I can type a sequence of very simple commands into Drush on the command line and automatically download those modules. It puts them in the right place, unpacks them, and you can enable them, versus that manual process of…
Kevin: Right, going to the website.
Ronnie: …one by one downloading them, unpacking it, and uploading it.
Kevin: Right, because that’s something that Drupal hasn’t been very good at is the web interface of updating and downloading modules, which is kind of been covered. Especially in Drupal 6, I know before I discovered Drush I would go to a website, find the module or click the link that it gives you. It says, download it, unzip it and do all this stuff.
Ronnie: Yeah.
Kevin: It’s just kind of a scary process, whereas WordPress – I’m going to keep coming back to WordPress because that’s the popular one, or that I just like. So with WordPress, you can just do one click, right?
Ronnie: Right.
Kevin: Whereas, Drush is kind of like – it’s the one-click but it’s even better than one-click, because you could maybe put that into an actual server side Cron job or something if you wanted to.
Ronnie: Yeah. The ability to update any module via the control panel in Drupal has never existed before Drupal 7.
Kevin: Right.
Ronnie: So, they’ve added in that. There are some debates there. I’ve always been more technical. I’ve been doing this a long time, so it’s, again, one of the reasons I lean towards a Drupal, is that’s a security concern as well, though. So, I can tell you from experience I’ve inherited, built and worked on all kinds of WordPress sites, for instance, that have gotten hacked. Granted, it’s not just that it’s WordPress, but there are features like allowing your website to download code and update and things like that. There are some just inherent security risks involved.
So, I think some of those decisions were in the past mostly a security thing. But now as technology is evolving and people are getting better and wiser with all of these things, Drupal’s brought that kind of functionality into core.
Kevin: Right.
Ronnie: But aside of this I don’t want to get caught up on that from what we were talking about. So Drush, the whole deal is it brings a lot of simplicity. It becomes a huge time saver when you get to the level of developing a fairly complex Drupal site, then the time savings that you’ll get from a tool like Drush become huge.
Kevin: Right. I know there’s some WordPress guy listening to this and like, “WordPress has a command line tool. WordPress has a command line tool,” and WordPress does.
Ronnie: Yeah.
Kevin: I don’t remember the name of it off the bat simply because I don’t use the command line tools for WordPress. But I can guarantee you Drush blows any of those out of the water. Because of certain – I’m not just saying that – because of certain features that we’re going to talk about right now, which are things like Drush Make files. It’s integration with Backup and Migrate features, just updating what you’ve already talked about and so much more.
Ronnie: Right.
Kevin: So Drush is a tool for you in your workflow. I know that you use – if you want to boot up, say, a community site, you have a list of modules already in the back of your mind that you’re like, “Okay, I’m going to use these,” whether it’s organic groups or Views, CCK or some SEO stuff. All of these in the back of your mind, and I know you use Drush to pull up that site quickly within kind of one command and that’s made available through Drush Make files. What is a Drush Make?
Ronnie: Well, there are a couple of different things you can use Drush Make files. So the simplest way to describe using Drush Make is essentially you can use it to create a manifest of all of the contributing modules that you want to use in a site. So, I think of it as sort of like a config file. So, I can generate it from a site that I’ve built and then I can reuse that, essentially, just like a shortcut to download a whole slew of things and enable them and do some real basic configuration installation that way.
So, again, as soon as you start building… When I started using Drush, I maybe was only downloading two or three modules at a time. Now I can encapsulate this inventory of a whole huge list of modules and set that up using Make and then have Drush automatically download and install that. Then the further evolution on top of that is to use Drush suite of tools to create and install profile.
Kevin: Okay. What is this?
Ronnie: So there you see like in many open source projects there are different distributions of Drupal, so like OpenPublish. There’s this one that comes to the top of my mind. There’s a ton of them now. There’s an eCommerce Kickstarter. There are all kinds. So, essentially in addition to capturing the list of modules that you want to install and enable, you can capture other configuration things.
Or let’s say you want to install sample data. You can take it and put it into an install profile. So, what that does is you essentially are creating your own distribution of Drupal. This is very common now. So, say, I built a ton of community sites and I know I always want a blog. I want all these pieces set up a certain way. So, I can capture that in an install profile and literally run my own installer.
The next time I want to create that similar kind of site, I go through what looks like the normal Drupal installation process. But I’ve got this choice to, say, install my eCommerce Kickstart site and it does a ton of tasks that I was normally having to do manually.
Kevin: Right.
Ronnie: So it makes your work easily reproducible.
Kevin: So that initial four hours that you would spend setting everything up is taken care of in a matter of seconds.
Ronnie: Right.
Kevin: I think that’s really great. There are many of those available on-line?
Ronnie: Yep. There’s a whole section of distributions on the Drupal.org site.
Kevin: Yeah. I’m going to throw a curve ball at you here. Is Aegir a part of that, or Aegir or whatever?
Ronnie: You know, I’ve never really known how to say it.
Kevin: I don’t know how to say it either.
Ronnie: I’m pretty sure that it’s on there, yeah. I believe that it is. That is true.
Kevin: So that’s a profile-based…
Ronnie: It’s an install profile-based distribution, yeah.
Kevin: Just so people aren’t confused, this is kind of my personal question to you. But what is Aegir?
Ronnie: It’s essentially a hosting environment for Drupal sites. So you can actually set up a server and run that distribution of Drupal. You can essentially manage… This is just specifically geared towards hosting Drupal sites…
Kevin: Right.
Ronnie: …so deploying them, managing them.
Kevin: Right. Managing your HT access, settings, all that stuff, cacheing, up and down times.
Ronnie: So if you were a consulting company and you specialized in Drupal, then you could manage a whole family of Drupal websites.
Kevin: Is Drupal Acquia a profile?
Ronnie: Mm-hmm.
Kevin: It is?
Ronnie: Yeah. Acquia Drupal uses an install profile. They pretty much all do now. But, yeah, that’s become sort of the common way to make your distribution easily reproducible, if you will. So that anyone can download it and go through the typical Drupal process.
Kevin: Right, so basically this Drupal Make thing is the equivalent of having the ability to make your own BuddyPress?
Ronnie: Mm-hmm, yeah.
Kevin: Or I think Forum Press is another one for… I’m not 100% sure on the Forum one. I just use BuddyPress most of the time. So that’s Drupal Make files. That’s really, to me – you’re the one that introduced me to that. I think that is probably one of the most amazing tools of Drupal, is to be able to say, “You know what? If I know I’m going to build a blogging site, I can make this profile, boot it up and I’m good to go.” Right?
So, that can be a real pain point of Drupal that’s just lifted just by using Drush. Now, there are other tools that have integration with Drush, such as Backup, Migrate and I believe Features also has integration with Drush, right?
Ronnie: Yeah, all of that really speaks to the power of Drush itself. Drush has kind of conceptually followed in Drupal’s footsteps in that it allows any module to implement commands, to make specific commands available to Drush so it has its own scripting format.
Kevin: So it’s not executing anything on the website into your terminal? It’s your terminal’s connection to the website?
Ronnie: Yeah.
Kevin: So, these modules aren’t going to go on your server and start running writing commands, right?
Ronnie: Now, you can set it to actually execute on remote sites. But to keep the conversation simple, take Backup Migrate is a very popular module for backing up and migrating – that’s just what it’s…
Kevin: Right.
Ronnie: So you can set up automated backups and things like that with it. It’s a fantastic tool. It’s one of the ones I use on pretty much every Drupal site. So they have added support for Drush. For instance, when I’m in my terminal environment and I’m updating and installing modules and doing things like that, I often want to make a snapshot of the database.
Kevin: Okay.
Ronnie: You can use Backup Migrate in that context. So I can tell Drush – and it’s got a shortcut command – I can just say, Backup basically with Drush and then it’ll dump to a specified location with all the databases.
Kevin: You can throw all that into a Cron job and backup your database on a schedule?
Ronnie: Sure. Yep, absolutely. It’s very, very handy.
Kevin: That’s very cool. Yes it is. It’s quite nice. So you have Backup and Migrate, which is like the backup solution. Then, we’ve talked a little bit about Features but Features is kind of its own beast. It’s almost like Make profiles for making modules on Drupal.
Ronnie: Yeah, Features module is created to battle an ongoing problem. It’s not just specific to Drupal. In a Drupal site there are quite a few aspects in your setup that are configuration and stored in the database.
Kevin: Right.
Ronnie: So, Features is a way to sort of extract that stuff that’s typically only stored in the database.
Kevin: For example, CCK fields and Views that you may have created and that you can’t exactly just port over.
Ronnie: That’s right. So there are a lot of different examples we can come up with, where I’ve done a certain thing, set some settings and whatnot and only stored in the database. Then if I want to, say, in a solid development environment, what I call a solid one, where I’m working locally and I might have a remote development server, staging server, and then I’ve got my production server.
So, I’ve got these various environments and I need to, say, be able to move configurations between these environments. You obviously don’t want to every time you make a configuration change that’s saved in the database, you don’t want to have to go reproduce those clicks manually across all of your environments when you’ve got changing data. You’ve got all kinds of moving parts across an environment like that. So, Features is a way to wrap that up into code.
Kevin: Right.
Ronnie: So then I can essentially deploy it and let the code update it instead of me having to manually go perform those clicks in the site.
Kevin: Right.
Ronnie: There’s an easy way to describe Features and that’s it.
Kevin: Right. So for example, based on your description, I can go into Views and create this list of blog posts with the author’s name and the title of the blog post and the body of the blog post. I can save that View setup into a Feature and then I can deploy that Feature once it’s made on a staging environment. Take that Feature and install it on the production environment.
Then I have my blog Feature without having to go in and worry about clicking the wrong things or messing up the display, and also being able to basically know that it’s going to be a one- for-one. I’m not going to have forgotten, for example, maybe if I used the Semantic Views that we talked about, that I wouldn’t have missed a class name or something in there, right?
Ronnie: Yeah, exactly. So it lets you reproduce those configurations easily.
Kevin: So then, what it sounds like to me, and this will be really cool if it’s possible, which is if I had a Make profile that could have Features inside of it…
Ronnie: Sure.
Kevin: …that I could have located on a certain server. So, if I was setting up a site and I had created a View to list the users and their last log in times, or to create a blog post, or a list of video pages that I wanted for a video blog or whatever, I can create those as Features, and then use those as modules within my Make profile, to construct it automatically. Is that possible?
Ronnie: Hmm-mm, you can. You can put Features inside of install profiles and you can, even when you create features.
So, when you create features you can specify an update server. What that does is by introducing a Feature module into a site you are sort of adding a little layer of complexity there that you are going to have to maintain that feature.
Kevin: Right.
Ronnie: In a regular Drupal site a returned update status module and I get notifications of when updates are available things like you can do that, mimic that same sort of thing. So if you do end up including features that you’ve built into an install profile, you can through this combination of tools make that maintainable is what I’m getting at. Once you create an install…
Kevin: Right. Once you have 20 sites right.
Ronnie: Once you create an install profile and as you go along, even just the core community modules, they get updated after a certain period of time, so that install profile’s just a snapshot in time, so you are going to want to update that. SO right now if I go and download the Ecommerce Kickstarter and install it, they created that a little while ago, some of those modules might be out of date so I’m going to have to update those modules.
Kevin: You can also update those from Drush, right?
Ronnie: You can also update those from Drush.
Kevin: So it’s all in one space.
Ronnie: My point is that you can do that level of complexity and it’s fantastic. There’s just things you have to be aware of.
Kevin: The Features really excited me about the blogging aspect of Drupal because, how often do you create a site and automatically we want blog feature, just so it’s there, or that’s what the client says, and when you look at the built in blogging functionality of Drupal, everybody just kind of deletes that and makes a View most of the time.
But when you do that you might lose the abiity to list posts by taxonomies. You lose kind of the ability to list things by author. So, to create these multiple displays within one Drupal View and then package that within a Feature, so anytime you wanted a blog you could have that same exact kind of core functionality.
So, you can create – something we haven’t talked about, which we could – which are blocks within Drupal. So I could create a block View to list my taxonomies all within kind of this one View, if you will, that I can just have access to via Features. Then in a stock profile I could have a blog that I like that I’ve customized. I think that’s really, really exciting.
Ronnie: Yeah.
Kevin: There are so many other things that you can do with that.
Ronnie: We could be nerdy all day here.
Kevin: Yeah. So, we’re kind of out of time here. Do you have any thoughts, anything that you’ve thought of while we’ve been having a conversation and you’re like, “Man, I need to mention this.” and you get to help the people that are listening to kind of, maybe, increase their learning experience or help them just kind of jump into the swimming pool that is Drupal?
Ronnie: No. I encourage people to just jump in and get their hands dirty. I encourage people to go look at code even if you’re not a super developer or anything like that. I find that going and really digging in there, you’ll learn a lot of things and a lot of comments, a lot of things like that.
I know that might sound kind of weird to say, “Go read the code,” but even before I became a solid developer I found that to be a great way to sort of go back to the source and kind of learn some things.
Kevin: Yeah. That’s common in the development world, which is, if you want to learn Cake, if you want to learn WordPress, if you want to learn Ruby, go check out that code base because it’s going to show you how things are done. So, you may go look at something in Ruby and be like, “Oh, that’s how they did this one specific thing and now I know next time I do it, I should do it in a similar fashion.” So, it makes you aware of certain new technologies within a system or a platform.
Ronnie: Yeah, but other than that, I would say that the big thing to tell you is to participate. It’s one of the beautiful things about where open-source software is and where we are culturally right now in being so connected. So, get out there on the forums, get into the higher seed channel.
There are a ton of in-person Drupal events. Now there are Drupal camps. There are Drupal Cons, two a year, and there are just more and more of those kinds of events popping up all over. So, I think getting involved and really seeing the community that’s built around it would be huge for anybody getting involved. [inaudible 00:42:04] the community itself.
Kevin: Yeah. Well, there’s so much more I’d love to talk about in Drupal that we haven’t talked about such as blocks and all of this other granular stuff. Maybe another day, another conversation, but, Ronnie thank you so much for coming on the show to talk about this. I very much enjoyed it. Where can people find you?
Ronnie: I’ve got RonnieTaylor.com is my website now and then I have an old school Twitter handle, @rontec76, R-O-N-T-E-C-7-6, on Twitter, moderately active. So those are ways people can get in touch. Thanks for having me.
Kevin: Yep. Thanks for being on the show.
Ronnie: Bye.
Kevin: Bye.
And thanks for listening to the SitePoint Podcast. If you have any questions or thoughts about today’s show please feel free to get in touch. You can find SitePoint on Twitter @sitepointdotcom, that’s sitepoint d-o-t-c-o-m. You can find me on Twitter @kevindees, and if you’d like to leave comments about today’s show check out the podcast at sitepoint.com/podcast, you can subscribe to the show there as well. This episode of the SitePoint Podcast was produced by Karn Broad, and I’m Kevin Dees, bye for now.
Audio Transcription by SpeechPad.
Theme music by Mike Mella.
Thanks for listening! Feel free to let us know how we’re doing, or to continue the discussion, using the comments field below.
Karn Broad
