Understanding Drupal

[Lullabot] [Nate Haug] When people ask me about Drupal it happens all the time that I'm trying to explain to people what it is that I do. It's a little hard once you answer the question "Oh, I build websites," and then usually that's enough for some people, and they don't want to hear anymore, and a lot of people, they wonder, well, what's special about what you do, and what's this Drupal thing? [Jeff Eaton] Drupal is a lot of things to a lot of people. At the simplest level it's a piece of software that allows someone to easily manage the content of their website, like all the blog posts or the news stories or something like that. [Addison Berry] And it allows you to edit the content through a web browser rather than having to pay somebody who knows a lot of HTML and how to do fancy code things to actually change things for you. [Angie Byron] In a traditional sense usually with web pages you have to edit some code by hand, and you have to manage these files everywhere and links and stuff like that. Drupal makes that a lot easier. Once you get it installed you can just click buttons to add pages and forms and all this kind of stuff. [Matt Westgate] You can go to a page, click an edit button, and all the content that was on that page is now in a series of forms and a series of text fields, so you can go there, you can edit it, save it, and then you're editing the content in real time on your site. [James Walker] Whether it's a social networking site that has lots of user interaction or my single user blog making sure that the code that runs it all as well as the administration interface works in all those different scenarios. [♪ Music ♪] [Understanding Drupal] [Jeff Robbins] A lot of people refer to Drupal as a content management system, a CMS. How I describe a content management system, first it's good to give a little bit of historical perspective on the way things have been. [1977] [1978 BBS] [1979] [1980 Usenet] [1981,1982] [1984] [1985 Free Software Foundation] [1989 CompuServe] [AOL] [1969,1971, 1975, 1987, 1986, 1988] [1991 World Wide Web] The explosive growth in the number of people who have discovered the power of the internet for learning, marketing, and just plain having fun has been incredible. The internet is changing the way we learn, work and play forever. [1991] [1993 Mosaic, HTML] [1994 Yahoo, Netscape] [1995 MySQL, Amazon.com, Internet Explorer, eBay, Altavista] [1996 Hotmail, Javascript, CSS] [1998 XML, Google] [1999, 2000] When the Web first came into existence the way people created web pages was each page on a website was its own page. [Angie Byron] Web pages used to be just a collection of little small files called HTML files, and they just have code in them. You would use a program like Microsoft FrontPage or Dreamweaver, or you would roll your own and you would code out every single page on your site, which is good and fine except if you're Amazon.com you're going to have a million pages, two million pages. The number of just files that were lying around was just astronomical, and keeping them in sync and making design changes was almost impossible to pull off without huge amounts of work. That's how the concept of dynamic websites really took off. They wanted a way to say, "Hey, this copyright is going to be on every page." "Let's put that in one place and then link to that within all of our other pages so that when we need to change the copyright we do it in one place and it spirals out through the rest of the site." It's designed to be able to run on the lowest common denominator hardware. It runs on the LAMP platform, which is Linux, Apache, MySQL, PHP. Where Drupal fits in with that is you basically have Linux on the bottom layer, and that's running your operating system. That kind of is keeping your disk drives running, really low level stuff like that. Then you have Apache sitting on top of that, and what that is is the web server. It handles when you go to www.example.com it will go and find a file on the computer it's installed on and then feed it back to you through your web browser. MySQL is a database, so that's storing all the content of your website as well as all your users, all of your sales reports. Things like that all go into a database, and then PHP is kind of the bridge between MySQL and Apache to sort of take this dynamic content out of the database and present it in such a way that someone can view it in Internet Explorer, Firefox, and that kind of thing. Drupal basically serves as an underlayer to generate HTML, but how it does it is instead of having hundreds or thousands even millions of HTML pages that are all individually written Drupal is very centralized in how it generates pages. [Angie Byron] A database-driven system works off the concept of all of your content being centralized in one place, and it's fed dynamically through template files and such to just output whatever the content of the page is at any given time. [♪ Music ♪] Instead of having, say, 200 pages you'll probably have about one or two, and then there's little dynamic bits called variables that just feed in, say, the content of a given page or the title of a given page. [Content Management Framework] The part I think that most Drupal developers get really excited about is the underlying framework of Drupal. The other thing that it is is it's a concept management framework, and what that means is that it allows you to hire a developer, or if you're a developer yourself, to extend Drupal to do additional functionality beyond what it normally can do. I've really, really grown to appreciate Drupal's capabilities as a platform to build additional solutions on top of because of its APIs and all of its hooks for additional third-party plugin modules to be built on top of it. I've found that if there is a feature that Drupal doesn't have the distance between starting with Drupal and adding that feature is much shorter than me trying to go and build something from scratch on my own. Certainly for developers the flexibility is kind of the key that I find. It's what helped me fall in love with it, the fact that it's got a very kind of clean, simple core with lots of hooks exposed that can be used to add in any kind of functionality that you want. Without having to actually dig in and actually even understanding code you can do a lot and really create exactly what you want by snapping the proper pieces together. The idea of taking all of these small Lego brick pieces and assembling them together into large sites with a lot of rich functionality is really, really important for the direction that Drupal has been growing in. The idea that you work with kind of a base platform and then you're clicking pieces together and that's typically-- at least the first portion of a Drupal install or Drupal site build is that you're clicking a bunch of these pieces together and tying them together. Not only can you pick and pull pieces out for free and try them out by installing them on your site and actually seeing how well they work you can also open them up and look at them on the inside and see exactly how well they're written, how good the code quality is and find out if it's a quality enough piece of software that you want to use as the basis for your website. What attracted me to Drupal was the code, the elegance of the code. It was commented. It was clean. It had a really elegant architecture to it. And when I started looking at Drupal's code it was amazing. I mean, it was like this I could understand and there was all this-- just a lot of stuff that really made me feel like the software was much smarter than me. There really was a lot of stuff underneath, and I just needed to sort of learn how to harness it, and then I would be able to do anything that we needed to do for this site. We already have a flexible content system. We already have a taxonomy system. This is stuff that you don't have to develop yourself, and instead you can build on top of stuff that just comes taken for granted from Drupal, and you can start doing stuff that really matters to your actual project. [Drupal's Core Modules] [Open Source] Drupal being open source was very important simply because I was looking for a way to get a head start on something by taking something existing and then working up from a point where I started really high up and then just could work higher from there. Over the last several years Drupal has really evolved a lot, and it's grown from just a prepackaged website that you can turn features on and off into a real platform for building really, really advanced large-scale websites. A lot of larger companies are starting to take interest because a lot of them are coming either from a vendor who they pay hundreds of thousands of dollars a year in order to maintain their content management system or something custom where they have to maintain a fleet of developers in order to just keep it running and maintained. Open source is a very appealing option to them because it allows them to leverage this community of literally thousands of people that are not on their payroll that can do things like adding new features, testing for bugs, and just making little improvements here and there. Closed software is liking buying a car with the hood welded shut, so if you want to change the oil or see what's going on underneath you really don't have a way to do that. You're dependent on taking it to another person. You're dependent on them giving you the features of the car that you are left with, and open source software is like sometimes you're lucky if you get a hood, but you are able to get in there and dig around and see how things work, change your own oil, and that's really liberating for a lot of companies. And by being free and open source, as developers it makes it very, very easy to get a much richer, much deeper understanding of the code, how it works and how best to use it and extend it. The fact that it is free as in beer and also free as in freedom in that you can change things on your own and that you're not locked in to what somebody else has given you, and you're sort of basically at their whim. By being licensed GPL Drupal kind of not only secures the code at its core to kind of live on as free and open source software but it also promotes and in some cases dictates that code that has been added on to it and extensions, so downloadable modules, are also GPL licensed and therefore freely available. [Community] Another feature of it--and why people might choose it-- is just the development community around it and the contributor community. It basically has a huge developer base of thousands of people constantly improving the software and the add-ons available. The growth has been kind of staggering and to the point where it's really kind of shocking to actually sit and think about the community as well as the software itself. It's just sort of this self-feeding thing where Drupal gets better and more people get interested because it's better, and then we have more people working on it, so it gets better, and then more people get interested in it again, and so it's just a fascinating process to watch and be part of. [Content] There's a lot of jargon in Drupal and it really increases the--it's referred to as the "I suck" threshold of there's taxonomy and node and all of this sort of jargon that you have to learn, and it takes a while to absorb that and soak it in and get over to that place where you start to feel confident that you can talk the talk. Yeah, nodes was probably one of the hardest concepts for me to get when I first got to Drupal. I remember being puzzled by the word and sort of-- I don't know, I just want to make pages, okay? I just want web pages. I don't know what this node stuff is. The idea of nodes of content can be a little confusing to people usually because they say things like "Well, why not just call it a post?" "Why not just call it a story or an article or something like that?" The difficulty is that a node could be any or all of those things. [What is a Node?] A node is the basic building block of Drupal. Drupal is a content management system, and a node is the content that is being managed. Yeah, if you've worked with Drupal for any given time you've probably noticed that when you look at a piece of content like a blog entry or a poll you'll see this weird node/1 thing. Drupal picked the word node for some reason to refer to any piece of content in the system. [♪ Music ♪] [Addison Berry] And so for me, learning what a node was, no matter how many descriptions I read or how many people tried to explain it to me, I had to just use Drupal to actually understand it but really it is essentially--I mean, it's just a piece of content on the site. What a piece of content means is does it have a title and an author and a description or a body? Does it have a create date? Things like that. Most importantly they have a unique ID, so they can be addressed via URL or referenced uniquely throughout the system. They basically stepped back at one point and said, "Okay, well, we have polls, and we have stories, and we have pages, and we have articles, and we have events, all kinds of stuff." And they said, "What are the main things that are common between these different elements?" And so they drew out those individual pieces like the titles and such and then put those into sort of a concept of an overarching content piece called a node, and then everything else just added stuff to a basic node. [Node Revision] Another huge advantage of the node system and being centralized and such is that Drupal can track revisions to nodes, which means that if you edit a piece of content and change a couple lines and hit save it can store a revision of that so that you could go back and revert back to the way it was before. [♪ Music ♪] [Addison Berry] If you want to you don't have to keep a copy of every single change that you make, but you can, and what will happen is that every time you make a change if you tell--there's a checkbox for make a revision, and what will happen is Drupal will basically take a snapshot of that data and put that into the database every time you make a change. This is particularly important for things like managing abuse. It's also important for things like--say you're running your entire user manual for your employee handbook or something off of Drupal. You want to be able to see how that document has evolved over time, and so Drupal can keep track of all that for you, and you can revert revisions, you can delete revisions, you can add new revisions, and it's just a way of protecting your content and kind of keeping a constant backup of everything. [Content Types] Generally speaking, on the end user side the visitor should never really see the word node. Throughout the user interface the guidelines for writing Drupal modules is that you don't talk about nodes. The first rule of nodes is you don't talk about nodes. Oftentimes where you hear the word node is in the developer speak. You hear it less sort of on the end user side of things. In the Drupal administrative interface it's called a content type. But the truth is that all the developers refer to these things as nodes. One of the things that Drupal can do with this content management component is it can allow you to create different types of content. The way Drupal works is it uses this concept of content types, and it's really incredible and I think one of Drupal's strengths. Drupal allows you to divide up the content on your site into different kinds of content so that each different type of content-- like events or blog posts or uploaded photos-- can be treated differently. Different node types can have different attributes. They can have different default settings of whether they're promoted to the home page or not, whether they show the user submission information, the date it was posted and stuff like that. I can make those look different. I can list them in different ways, and so I can loop them together. I can split them apart and sort of rearrange how I want my data, my content to be displayed on the site. And you can also set different permissions on content types as well. Any content type in the system you can control who can create it, who can edit it, who can delete it, who can manage all of those things and even who can manage all content across a site altogether. [Content Construction Kit] When I started building WordPress blogs the thing that I was always missing was the ability to add more fields. I wanted more than just this, the title and the excerpts, synopsis or whatever they call it in different things and different web applications and the body. It starts out with just the title and the body. It's a basic node, and then you take those two basic pieces, and then you start adding additional things on to them like adding in taxonomy information and publishing information and using CCK, adding in additional fields but make it so that you can tack on all kinds of additional information around the basic node. CCK is the content construction kit and really is about creating custom content types, so moving beyond blog posts and simple stories that have title and body and adding extra additional fields of information. With CCK that Holy Grail of being able to add as many fields as you want to the content type is starting to be realized in Drupal, and this is really, really powerful stuff. And fields can be anything from text fields to image fields to number fields to date fields. There's even some really fancy modules out there that let you attach embedded videos or complete addresses and all kinds of stuff. The flexibility that you get from that is really amazing. It's like you don't get this block of content and you're just stuck with this monolithic block, and that you have to use it the way that it is, and it's always going to be this way, and they're all the same, and you can't distinguish between anything. It's like no, different types of content have different meaning to me on my site, and I want to be able to do different things with them. You don't want to have just one form on your entire site for all of the content. Instead building out different content types allows you to basically build specialized forms for whatever kind of content you're actually talking about. [Addison Berry] Basically creating--especially when you have other people that are going to be creating content on your site giving them a form to fill out that has the exact fields that are descriptive of what the information is you want to elicit from them is hugely helpful in getting the right information. CCK really allows you to--completely through the interface-- just add those additional fields and configure them, add default values and things like that to really make the data entry or the content creation on the site very simple and streamlined. Now, from a developer's perspective this is great because this sort of stuff we do day in and day out, and it gets old and tedious to do those sort of same things over and over again when you're just playing with the same type of code, so if we can hand that control off to an administrator, a site editor, so that they can go in and set up these systems that gives us time to do the fun things. Building out separate content types is basically the first building block of your website, the first step to actually getting a new site under way. Boot up Drupal, install CCK, start building your content types that all contain the various fields that you need to describe those pieces of content. [Users] For a long time the history of the Web was very much one of small teams of people going and building a website and putting it up for other people to come and view. Although it was a lot more flexible and a lot easier than older publishing models before the Web was available it still meant that it was one team of people making things and another consuming things. Drupal is part of a trend in the evolution of the internet towards the people who come to a website and who visit it, actually helping build and develop the content for it. A lot of companies have started looking at Drupal seriously as a content management system because they're really interested in sort of playing catch up to all of the sites that are around now where users interact with the site. It's no longer an informational site where you just go there, and there's information, and you click around, and that's it. Now a lot of big corporations are really interested in interactive sites. The idea is that it's not just my team publishing and that group of people reading but my team building an environment where other people can come in and share what they're interested in or what their thoughts on something is. [♪ Music ♪] [Users] A visitor to the website is called a user in Drupal speak, and there are two types of users at a base level. There's anonymous users, which haven't logged in yet, and there's authenticated users who have. The first and simplest is an anonymous user. That means just somebody who is coming and is asking to see a given page on the website but has never logged in, and Drupal has no real way of identifying who that person is. Basically you have an anonymous user who is just anybody just wandering around the Web, a random "Oh, look, here's a site." And what they're going to see could be drastically different from someone that's created an account on your site and therefore you know and want to give them something different to see. In a lot of social networking sites you have to log in in order to actually get that functionality. A similar concept in Drupal is what's called the authenticated user. That just means someone who comes to the site and has created a user account and given some sort of identifying information so that Drupal can know "Oh, this is Bob," or "This is Mary, and they're interested in this particular kind of topic." "I should show them that on the front page." And it goes through and basically has to check and build and say for this particular person at this particular time I need to build XYZ page for them and then display that for them when it gets to the end, and it can involve all kinds of things like do they even have access to the page? Because if they don't I'm not going to show it to them. I'm going to go over here, and I'm going to redirect them to a busy signal because you're not allowed to access this page, or it might be, well, they are allowed to see the page, but I'm going to display it to them in a slightly different way. It could be something as simple in terms of theme layers like a collar, but it could also be actually in the amount of data that's displayed. You don't necessarily get all of it. [Roles and Permissions] Blogs and blogging software, which tends to be one person running their own site where there's that level of trust of everyone who has the permission to post things on the Web using this site is usually either one person or a small group of people who all know each other. With Drupal kind of anyone can come and register for the site, and then you need to decide what you're actually going to be able to trust them to do. And still one of Drupal's strengths is how well it works as a community tool, and it's not limited to just one person on the site, a static sort of site. It's different roles, different permissions. Drupal at its heart uses a role-based permission system, and a very flexible one at that, so as a site administrator you can define any number of roles that a user may have within your system, and any role that that user has will then dictate what permissions and what things that user is allowed to do within the site, which allows for varying levels of interaction. In addition to that you can define additional roles such as a manager role or an administrator role or a lawyer role or something, and they can have additional privileges above and beyond what authenticated users have. Usually when we create a Drupal site the first thing we'll do is create a new role for administrator, and we'll usually call it admin, and basically you go through and check off all of the boxes so that anyone in the admin role has all those permissions. You don't need to have one user account that everyone in the company has the password for that's the root user account that has all the permissions and then somebody goes and leaves the company, and they decide to deface the site and stuff like that. It's no fun. Instead you can set up this admin role and people have their own user name and their own password, and they have all the permissions for everything basically. As more and more people are contributing and interacting, more and more users are logging into your site, you can clearly define and cleanly define what each of those users is allowed to do within your sites, whether it's creating different types of content or you have users that are allowed to publish things or promote things. That all can be cleanly separated out using the role-based permission system. [Single Sign-On] I'd say one of the great strengths of Drupal and one of the reasons why a lot of people get involved in it is because it has the flexibility to do so many things, and behind all of that now is just a single user login system. And this is one of the really powerful things about it. I mean, if you're writing your own content management system you have to handle all of this yourself, but with Drupal Drupal automatically just knows a bunch of information about the user. Drupal does all of the heavy lifting work of maintaining contextual information about who a user is, what they've been doing. You can do things like keep track of what pieces of content they've written versus what pieces of content other people have written, when their last visit was, things like that. All of the process of keeping track of who the user is that's logged in and what permissions they have and sort of what else is going on in the site is all handled by Drupal's framework. The user login system is part of core, and then everything else gets put on top of that. It's a very central piece and something that not a lot of systems have, this great luxury of every single module, everything that's built on top of Drupal has the convenience of knowing who the current logged in user is, what their credentials are, information about them. [Blocks] Blocks are another one of those pieces of Drupal jargon that you've probably heard but not known what they are. The good news is that if you've built the Drupal site you've interacted with a block before, knowingly or not knowingly. The user login form is a block. It shows up on the side bar. Drupal calls these blocks, kind of a nondescript name, but it's what they're called. They're little blocks that can appear across the site. And what blocks are and how they're different from nodes is nodes are the main content, and blocks are the accessory information, the additional information usually shown in the side bars, the navigation system, a little search form maybe, a block. Basically there are kind of two ways that content is represented in Drupal. Nodes is the big one, and that's for sort of content pieces that you generally are going to write once and then leave alone. You might go back and make minor edits, but in general once you've written your about us page it's written, and it's done. Blocks are another way. They are generally more for dynamic, up-to-the-minute content, so for example, Drupal ships with some blocks like who is online and recent comments and things like that that are going to change a lot over time. Other examples of blocks would be recent comments, recent forum topics, all that accessory information that you would see that goes along the main content area of your site. You might want to have--as we do on Lullabot.com-- show the latest posts on the site. What's the latest article on the site? What's our latest podcast? And have a link to that that goes across all the pages. It might be ad banners. It might be stuff that tends to appear on multiple pages on the site. And the other thing that blocks are for is kind of supplementary information to the current content. For example, there's an author information block that you can enable which if you look at any post by a given person it will bring up more details about their user profile and stuff like that. You can also put actual content in a block. Sometimes people will use blocks for things like a sale of the week kind of thing, but in general I like to make the distinction where like a node is permanent content that you want to be searchable and things like that and a block is more either transient content that changes constantly or it's just like supplementary information to sort of enhance the rest of the content on the page. [Modules] At the heart of Drupal in all of its functionality is the concept of modules, and what a module is is essentially it's just a little piece of code. Modules are Drupal's plugins. They add functionality. A lot of the Drupal system is built around this idea of modules, plugin software that can either change the default behavior of a given feature in Drupal or add new features entirely. If you want to add a new feature or a new function to your site you would use a module to do that. And examples of modules are things like the blog module which lets you post blog entries. [New Content Type] [New Permissions] [New Block] All of these things that we're talking about modules basically have the ability to fundamentally add and/or modify what Drupal does, and it makes it really powerful. A given module can add new features or change behaviors without any of the other modules on the Drupal site knowing what's happening or even being aware of that, this idea of all of these different pieces that weren't written explicitly to work with each other but can be combined, and using Drupal's APIs they can all interact effectively without clobbering each other. That's one of the really effective and powerful aspects of the software. [Lean and Flexible] Core--which is what we refer to the Drupal that you download by default--comes with a handful of modules. Most of them are pretty simple, and then there's a couple of utility modules that you kind of have to have like system and filter that take care of very low-level tasks. Drupal prides itself on having a very small core library that it uses, and it always wants to make sure that core library is as efficient as possible. [Nate Haug] Drupal comes with very little functionality right out of the box. Instead what it is meant to be is a system where you start out with something small that does basically what every website needs to do, and then by enabling modules you add additional functionality on to the website. The community has gone to great lengths to make Drupal a tight, lean, secure machine. And the philosophy is to keep things as efficient and effective as possible and as light as possible. That's where the flexibility of Drupal lies is that it's really small and compact when you start out, but then by just enabling whatever modules you feel are necessary the site can get a whole lot of functionality really fast. [♪ Music ♪] [Hook System] Drupal operates off the concept of this crazy thing called the hook system. The hook system is something that makes Drupal really extensible, and it's something that is really, really simple just at its core but adds so much flexibility to Drupal that it really gets developers in and working with Drupal in a really shortened amount of time. You can think of Drupal as an event-driven system. All along the process of spitting out a Drupal page there's different moments along the way where it says "Does anybody need to do anything here?" [Would any module like to change this data?] [♪ Music ♪] The module that's responsible for rendering the page will stop occasionally and ask all the other modules in Drupal "All right, I'm at this point with processing the data." "Is anybody else interested in changing the data?" And other modules will all get a shot at changing whatever data is currently being processed, and that might be loading some additional things from the database and adding it to the node object. All along the way there's these things called hooks which basically means that a module developer can hook into it and say, "Okay, I want to do something at this point," and Drupal will pass along the context. It will say, "Okay, here's the user that's logged in." "Here's the content that they're wanting to view," and now I as the module developer can change that up, manipulate it, do whatever I want. One example is when you view the user permissions screen and you get a big list of check boxes of all the different permissions in the site. What it's doing there is it's querying all of the installed modules in the system and asking if any of them would like to define permissions. Any time I've gone to add in a new bit of functionality all of the kind of hooks to add my extra code were already there and available for me and easy to integrate with. And so that's where Drupal gets a lot of its flexibility. It's not just the node module that has this ability. Every module in Drupal can at any point decide to ask other modules what they want to do with what data is currently being processed and have a chance to change it. [Core versus Contributed] The difference between core and contrib is manifested in that they're actually two different code repositories, which sort of serves as a metaphor for how those code repositories are treated. The core of Drupal is what you download when you download the zip file of Drupal from Drupal.org, and it's sort of the base libraries and things that Drupal needs to get started as well as a collection of around 30 modules that are common features that most sites will use. In addition to those there's also the contributed modules, which are the rich community supplied modules, and those can do all kinds of crazy things like event management, photo galleries, neat little JavaScript clicky, draggy, shiny, pretty things. All that kind of stuff. Drupal is moving towards a world where there's lots of small pieces, modules and add-ons that do one or two things really, really well, but a website is built by combining lots of those things together. The fact that things like CCK and views and image handling things are all in contrib means that almost every Drupal site and Drupal implementation requires both pieces so that the contrib modules aren't just optional add-ons that tend to be very core pieces that Drupal requires. The number of additional add-ons for Drupal, plugin modules that are available, has exploded over the past couple of years. We've gone from having a good solid 700 modules to thousands that are now available for a huge variety of different functions. The Drupal contrib repository, the contributions are add-on modules, and it's much more the Wild West of Drupal code. It's much easier to get access to maintain modules there and the maintainership is--the level of maintainership depends on the individual who is doing the maintaining. [Menus] On a basic level the menus system is a way to create a navigational system for your site. The menus system allows you to manage all of the navigation links that are available for users who are surfing around the site and clicking around and trying to decide what's even available when looking around. When you install a Drupal site and you log in as an administrator and there's all those links that you can click on, the create content, the administer site, that's implemented as a menu, as a Drupal menu. There's one menu, the basic navigation menu, that Drupal automatically builds for you and will maintain. As you install third-party modules, they can add new menu items to that without any other interaction. It's the way to navigate your site, and it knows about things like parent and child relationships so you can have links that are children of other links and that sort of stuff, so if you want to have some sort of hierarchical navigation system you definitely use a menu for that. But again, by default Drupal has this concept of primary links and primary navigation, and then it also has secondary links, so when you go to one section of the site you might have further links that help you get there, so if you have an about page or something like that you need to put that somewhere so that someone can actually find it, and so you would add that to a menu in Drupal, and then it would appear on all of the pages. [Menu Paths] It's really important to keep in mind that there's a very small amount of information that the Drupal software or any web platform has to go on. All that's really there is the URL that a user has asked for, and if they've logged into the website there's going to be a cookie storing session information, just a unique identifier for that person. As far as what's coming in from their browser that's all you have to go on. A big thing when I got started in Drupal is I couldn't figure out "Okay, I just have this path, and I want to make something appear at this path." In traditional development what that means is you make a series of folders, and then you put a file in where you want to take over that path. When you see a path like user/1 you might think that under the hood of things there's a user directory and then there's files for user 1, user 2, user 3 and so on. But in actuality all of the requests that you make to Drupal.org run through a file called index.php. Because in Drupal there's actually only one PHP file that's called for every single request. There is no about.php and news.php. There's exactly one file, and it's index.php, and that file is called on every single request, and the very first thing that's fired up is the menu system. The fact that it is a dynamic site and that your pages are built dynamically on the fly is a much more complex process then people would realize just on the surface when you're used to just plain HTML. The menu system is a lot more than just menus. It's not just what you see along the top of the page or along in the side bar. Rather in Drupal the menu system is actually what defines what gets executed on the entire page. It's like a page router. Underneath the hood the menu system keeps track of every single valid URL path on your website. It's sort of the switchboard operator of Drupal, taking an incoming URL and determining what module and what PHP function should be responsible for actually building the content at that URL. [Clean URLs] One of Drupal's innovations early on has been the clean URL system, and what we did is we said, "Look, these URLs that most dynamic content management systems generate tend to have a lot of gobbledygook in them and tend to make them hard to read for humans, hard to remember." If your URL has a bunch of question marks, ampersands and tildes and all that other stuff it's hard to remember it let alone say that to another person. "Just go to index.php?/ squiggly line." What we did is we came up with a way to hide all of that stuff to sort of make it not visible but still work, if you will, and so we did that through using clean URLs where instead of pages being index.php?q=node/11 it's just node/11. The pages are being built dynamically. The beginning part, your example.com part of your URL saying that's the website that I'm on, but everything after that is a query because that's how Drupal is actually building that page is you're actually querying the database. It's building the page and returning it, so the q= is all this query stuff that's going on. It's all the dynamic stuff that's happening. It's what's happening afterwards. And then we decided to take that one step further. We said, "Why restrict it to just node/11?" "Let's have it be /fishing or whatever you want it to have." We added another layer on top of that with a path module, and what we did is we just mapped those already clean URLs to more search engine friendly URLs or whatever URL you want to have on your site. [Themes] I tend to think of Drupal actually in little layers, so there's the theme layer that sits on top, and basically you're generating content, and it's sitting in a database, and it's all related to each other in Drupal's little world. But at the end of the day it needs to be presented on a browser screen to your end user. Theming is Drupal's presentational layer. It's the display layer, and it's separated conceptually from Drupal's framework, the functionality layer. [Nate Haug] The idea of the Drupal theme layer is to separate logic from display. When the logic is all done it's handed to the theme layer and says, "Okay, the logic is done, just print this out." And then the theme layer, that's when it decides exactly how that data is actually going to be output. There isn't processing done before it. It just kind of gets the data and knows what it needs to actually output, and then the theme function can actually decide to take that object and print it out in any way you like. It's really cool that you can have these things separated like that because it means that you can really quickly assemble the functionality of your site and then choose the look of your site separately, and these things are not interrelated. Also you can have two different teams working on the site at the same time. You can have people working on the functionality while meanwhile the design people are working on the theming aspect of things, or you can download existing themes and basically change the look of your site. [♪ Music ♪] Drupal has the ability to output things however you'd like. It's got the basic node data, but the node data is not at all tied to how things are displayed. Things can be displayed however you want and not necessarily in HTML. You could output them, say, in JSON for JavaScript, or you could output them in XML for RSS feeds or for any format you wanted. The theme layer is something that you can affect, and you don't have to drill deep down into the guts of Drupal in order to change how something looks, which is really nice. [Site Configuration] [Error Reporting] Drupal has a lot of different ways of informing you of what's going on in your site, if there's things that you ought to pay attention to or if there's errors that happened and that kind of thing. The most obvious way is if you click and something bad happens you'll get a little red error on the screen that you're looking at that says, for example, the user name field is required or something like that, so that's an easy feedback way to know that, oops, I messed up, and I did something wrong. Drupal has two main error reporting modes, and essentially the difference between the two is the difference between your development or your kind of working state and then your production final state, so whether you want to log all errors as well as print them to the screen, so any time PHP runs in to a parse error or there's a warning or things like that it will log that error using Drupal's logging system, and then you can also have it printed to the screen. As you're developing and working on your site you can actually get those errors right there so you don't have to go check the logs. They're there, and you can address them in your code. Most people--in terms of the end user--you would really rather them just get a blank screen than have a whole bunch of nasty code and weird warnings and things that are sort of frightening and scary sounding and they're like "Oh, my gosh! Do I have a virus on my computer?" They're just not sure, and so silence generally is sort of the best rule there. Instead of actually having it printed out to the screen you would rather just have it log. There's also the concept of a watch dog error logging message. If you go under the administration panel and reports you can see a whole log of all the system events that have happened, which logs everything from really bad database error, PHP error kind of stuff, but it also logs things like who is searching for what terms and when was content created or deleted, and who did it and so on, which is good to keep track of, especially if you want to do some sort of security auditing kind of things and also just to keep track of pages that aren't found. [Status Report] There's the concept of a status report, and at any given time in your site it will kind of keep track of the state of the site and if there's anything that you need to be concerned about. That keeps track of things like what version of PHP are you running, what version of MySQL you're running, when was the last time that Cron ran, when was the last time that your system was checked for security updates, and it will also inform you there if there's a problem that you need to address. And so it's a good thing to just go and check that every once in a while. It's sort of like a healthy little status report, like is there anything odd going on with my site? It's obviously not going to cover every nook and cranny, but it's just covering some of the big basic things about where your site is running, how it's running and what you may need to attend to that might silently be happening in the background that you're just not aware of. [Cron] After you get Drupal installed, one of the first things that you have to do is set up what's called a Cron job, and most people have no idea what that is, and it is kind of a funny word. What Cron basically is is it's something that runs on a schedule, and you can set up how often, like every 5 minutes or every hour, every 6 days or something like that. On a given website it's often important for different tasks to be performed at regular intervals. That could be updating a list of what the highest rated content on the website is, or it could be clearing out old log information that's no longer necessary. That's performed by a utility called Cron that works with Drupal. It's a Unix utility that's present on lots of different web servers that can at regular intervals, like say every 30 minutes or so, just run a particular command. Drupal has a system that utilizes that Cron software to execute cleanup tasks and perform different tasks at regular intervals. We had this one client that didn't run Cron on their system, and we asked him how many records they had in one of the tables in Drupal, and they said they had over a million, and it was the cache table, which is supposed to hold all of this temporary information that can be built up and lost and built up and lost for performance, and as soon as we cleared that table for them the site was snappy and responsive, and we were able to get Cron up and running, and their site was fine. Cron is important because it does things like clean out your old log files and re-index your content for the search engine and kind of general maintenance tasks that only make sense to do once in a while. It will send out emails on a certain schedule so that you don't do things all at once and take down your site. It will batch things up and do them a lot over time. If you have search enabled Drupal has to go through and actually see "Oh, you've got new content," and "Oh, you've got new words in that content, and I need to know about that." It doesn't do that on the fly every single time because that would be rather intensive, so Drupal does that on a Cron run. [Performance] Because Drupal is a database-driven application a lot of times people will get nervous about the fact, well, is it going to scale? Just a static HTML page is really easy to serve, but when you start bringing databases and PHP and stuff like that it becomes quite a bit of extra overhead. But there are things that you need to keep in mind as you're making the transition from tinkering around and building websites and learning how Drupal works to actually making one that can stand up under the load of being linked to by Slashdot or being mentioned in an article in a magazine or something like that. A lot of the performance and scalability with Drupal actually comes from the other layers that comes from the operating system, the database, the web server, and Drupal is sort of the last thing that you optimize because you can optimize Drupal all you want, but if you're reaching a bottleneck with the other layers that are coming before that you're not going to see the performance increases that you would otherwise notice. We've helped set up a lot of large-scale clients with these 20-server installations where they've got multiple database servers and load-balanced Apache servers and separate file servers and all that kind of stuff, so each of the different aspects of the website which might all run on one server if you're running it on the $5 dollar a month hosting can break off, and you can actually dedicate an entire server or group of servers to that functionality, so it scales pretty well. Drupal provides a lot of ways to improve the performance of your site and help it to scale. At a basic level some things that you can do are you can turn on CSS aggregation. What that will do is take all of the various style files that are coming from different modules and themes and different places and smush them all down into one file, so that's only sent across the wire once, and that will make your site a lot more responsive for your visitors. Traditionally the solution has been to rework the internals of Drupal so that it's easy to plug in new capabilities for, say, advanced caching or new ways of optimizing speed for certain kinds of information look ups or whatever but not to require those so that people with modest hardware or small needs can just install Drupal out of the box and start using it whereas people who really need to squeeze performance out of it can begin optimizing and replacing certain components with highly optimized replacements. [Caching] Caching is a really important concept in Drupal and actually in a lot of websites. The idea behind caching is that there are some kinds of content that can be really expensive to build from the perspective of a server that has to spend time pulling information out of the database and formatting into HTML and taking into account all of the information like who a user's friends are and what content they've recommended to that person and stuff like that. It's not that bad on a simple website, but on complex websites that have lots of rich context and time-based information there are certain pieces of information that just take a long time to build, and if you have a lot of traffic coming to your website each person asking the web server to build that complex bit of information can be a serious problem. Caching is basically just the practice of only building that once if it doesn't need to be redone. The HTML parts of Drupal, the HTML pages can't be cached because they're dynamic. You're always updating that. People are adding comments. You are creating new blog entries. All that stuff lives in the database, not static files like those other parts, so what we've enabled inside of Drupal is a page caching mechanism where if an anonymous user visits a page at the end of that request we take all of that and stick it in the database. The next time an anonymous user visits that same page we can say, "You know what?" "Nothing's changed yet, so let's just load that page that we have on standby," and that's generally what is referred to as caching. It's slightly less desirable because it only works for anonymous users, not people who are logged in, and the other problem is that it will make the content stale for a certain period of time, so for example, if there's new comments in the last 5 minutes they might not see them except every time the cache flushes, which might be every 10 minutes or so. It's also possible to do smaller bite-sized chunks of a page and cache them after they're built so that even logged in users who may see a different mix of content may still be seeing a cached piece of content or a smaller chunk of the page if it doesn't change very frequently. And what we've done is we've evolved from just a page caching system to a module caching system as well, so now different modules-- if there's parts of their code that tend to be CPU intensive or a little more involved from an algorithm standpoint-- developers can cache that now. They can create their own cache tables, store that information, and just call on that rather than going through all of the steps over and over again. There's also a relatively new feature called aggressive caching that strips out a lot of the API calls that Drupal will make to third-party modules to allow them to do their work and focus on doing nothing but pulling that cached page out of the database and presenting it to a user. That means that Drupal does a lot less work to display a page to a user, and that means that your website can serve pages to more users as they come and visit the site. There's also modules such as memcache and advanced cache to do crazy kinds of caching, but generally you only need that if you're talking about several different back ends that you're using. For the typical person who is just using a blog site or even just a really popular site with not a lot of logged in users you should be fine with the default options. [♪ Music ♪] [Featuring] [Addison Berry] [Angie Byron] [Jeff Eaton] [Nate Haug] [Jeff Robbins] [James Walker] [Matt Westgate] [Understanding Drupal] [Part of the Lullabot Learning Series] [www.Lullabot.com]