Drupal Step-by-Step: How We Built Our Training Site, Part 1 [April 2, 2014]
Drupal Step-by-Step: How We Built Our Training Site, Part 1 [April 2, 2014]
Want to learn more about Acquia’s products, services, and happenings in the Drupal Community? Visit our site: http://bit.ly/yLaHO5.
This is the first part of a two part tutorial on building a site in Drupal 7. In this webinar, we’ll look behind-the-scenes at our site Training.acquia.com built in Drupal 7. We’ll also look at how the site was built to be flexible with room to grow, so non-technical content editors can make future changes to the site easily. You’ll also get an overview of great modules to make your site easier to extend and customize.
You will learn about:
• Building flexible content types
• Views with arguments and contextual filters
• Improving performance
• Simplifying maintenance
Moderator: Today's webinar is Drupal Step-By-Step, How We Built Our Training Site Part One with Dave Myburgh, who is the senior engineer here at Acquia. We're excited to have Dave on the call. Heather James will also be on the call, who's the Manager of Learning Services here at Acquia.
Dave Myburgh: Today, I'm just going to go through some of the site architecture and construction of how we moved our old training.acquia.com site from Drupal 6 to Drupal 7. A little bit about me, I'm a senior engineer at Acquia. I've been here for about two and a half years now. I'm the lead engineer on acquia.com I also have a bunch of other small sites that I look after, including now training.acquia.com.
The things we're going to cover today is a little bit about the site architecture, some of the modules that we used in building the new site. How we put together some of our content types. We'll talk a little bit about the data migration from Drupal 6 to Drupal 7. I'll show you some interesting views where we throw in a couple of arguments on contextual focus. Then in the last two little bits we're going to talk about how performance got improved a little bit and how we made maintenance easier for all of us involved in the site.
Who will benefit from this talk? Developers and site builders mostly. If you have some experience in Drupal, that will definitely help you out a little bit, but if you're new to Drupal as well, you'll definitely pick a couple of interesting and useful tips.
Just a preview of where we were and what we ended up with. On the left is our old training sites kind of 90’s style looking and I think we did a fairly good job upgrading it to a more modern look. Definitely a lot easier to use now as well.
Some of the requirements for this project; we wanted to keep the basic site architecture the same. The landing pages, content types more or less the same. We did drop some content and we did add one or two new things, but for the most part the main architecture is more or less the same. What we wanted to improve was a better editing experience for us as admins as well as for the partners, who are actually creating the events on the site for us. We wanted to better handle the Events Status, because sometimes we had issues where an event got cancelled and it was a complicated process on how to manage cancelled events. Publishing Workflow, we wanted to help make that a little bit better and if I need to use the management for the partners on how to deal with the bunch of stuff on the site for them to make their life a lot easier.
Some of the building blocks. Right. I'm streaming to a demo. I will show you a little bit of the site looks like right now. Here's our front page. I'm just using a local copy of the site just so that we don’t have any issues, technical difficulties. The site focused on events. We're going to look at the upcoming events. We have a nice map and at the top, we show online events and then we show our various in-person events. I'm just going to pick one of these guys. There's one group of module development.
This is the Event Page. We have all the various important information on the right side. We show some information about the course that the event is going to be doing. Click through unto the course that's related to this event. It'll tell you all the details; the level, the track that the course is in. So several courses can form a part of a certain track. You'll see the upcoming events for a particular course. I'll click you through to the track. So this is for developers and these other courses that you can find for this particular track. So we have three content types here that we're look at now. We're having an event node which has a node reference to a course which itself is a node reference to track. All right. So that's basically an overview of the most important part of the site.
All right. So next. So our main site architecture; events, courses and tracks. We have a couple of static landing pages for general information. I think resources, private training, that kind of thing.
Let's look a bit more in depth at some of the content types that we have. Event Nodes. The Event Nodes have the location, the date, the cost. That's the actual thing that you're going to be attending to learn about a particular subject. The Course Nodes, which are a node reference from the event have the learning objective, the pre-requisite, that kind of information. Finally, the Track Nodes are simply a grouping of courses. Like a category but we're using node reference to link all of those together.
Event Nodes. These are created by our partners. They have, like I have mentioned already, a node reference to a Course Node and by the node reference we actually displayed the course information or a brief part of that information at the top of each event node as you saw. The address for the actual event is handled with the Location Module. In fact, our Drupal 6 site and our Drupal 7 site both used Location Modules. That actually made our migration, which I'll talk about later, a little bit easier. Events can be in-person where you go to a place to actually physically attend it or they can be online. That designation will affect the display of the map. If it's online, obviously, there's no physical location so there's no need for a map.
Then we have Events Status Options. So when the partner is actually creating the nodes, they can set the status of the event. We have a Draft Event which is not visible to anybody. We have Cancelled Events which are, as well, not visible. Then we Tentative Events which are events that are probably going to happen. Finally, we have Confirmed Events. I don't know if you'll be able to see those two, but I'll show you a bit more in depth later. Some of the content type changes are quite nice, especially moving to Drupal 7. We have vertical tabs which make organization of the various fields a lot nicer visually. It's easier to follow the track of the node from where things are. It just makes it easier for everybody to handle.
All right. A little bit more detail on the Events Status thing because this is one of the more important features that we added to the new site to help everybody. As you can see, the field is a list field using radio buttons. So you can only select one thing at a time, obviously, and depending on which option you select, different things will happen to the node. You'll see a different badge or button displayed on the actual node itself. As I mentioned, draft and cancelled events are unpublished so people don’t get to see them - the point is if it's not happening.
Tentative has the orange button. Confirmed is green. We actually use pre-processed field function to install the button. Adding a class to the icon and the pop-up text. When you hover over something, you'll see some interesting texts. Particularly the Tentative Events, we link to another page which explains what the event is. Those buttons then get displayed on each Event Node right next to the event detail.
Let's have a like at the node form. I'll show you how the Event Node has put together. So I'm just going to use this same event that we looked at a little bit earlier. We edited it, we got the title, the usual kind of thing. We have our node reference link to the Course Nodes. So we just simply list the various course nodes to choose the one that the event is going to be on. Our Events Status is positioned just at the top right. That's pretty important so we did some special formatting just to have it nicely positioned. The regular body - just so in case you're wondering, I'm using [BU] editor as the default editor. I don’t personally like [BU Editor], they do weird things. Hopefully in Drupal 8 that will be much nicer.
A couple of other things. Text Formatting Help. I just took that out of the way. Here's a signup link. Each department will have their place that we actually go do the signups. We've grouped some of the details together in a vertical tab. So dates, costs, delivery, and the language. Location is the Location Module. You enter in your various address details, you got a little nice map that automatically geo-codes the latitude and the longitude which we'll then use later on the main Events Page. All the Event Nodes get shown here. Then Provided is just a bunch of things that will get provided at the event.
That's what the node form looks like. This is what the partners and the administrators are going to see. Let's have a look at how this was put together. Content types, and then managed fields. Using Field Group Module allows us to group stuff really nicely. Status for the Event Status section. That is a couple of external things we can add. Different types of fields, not just regular field bits or in case the details of the vertical tab. This one is using a HTML 5 site field type. It's just a way to differentiate. That allow us then to target the status field group and stick it over to the right. The rest of the stuff is just the main body. Group things together nicely. You can add classes and stuff to do whatever special styling, kind of things you need.
On the display sites of managed fields, this is what the form is going to look like when people edit the node. Display is obviously what gets shown up on the front end. We have Event Details. We have basically status, body and location. That's the only thing that gets shown through the node display settings. But if you remember, we have all the actual event details on the right hand side and that's done with the View and I'll show you that in a little bit later as well.
That's just the basic idea of how we put together at least the Event Nodes type. You can see here we use the module as field formatting class so that we can actually add specific classes to the fields for output. Sometimes, the default classes that Drupal has are not what we want or they're too generic. It’s always nice just to throw in your own classes. It allows you to do fancy things like have generic classes like adding a margin to the left and to the bottom if you want rather than having to style and add a specific CSS thing in your custom style sheet. You can just add in existing classes.
Let's carry on here. Some of the modules we used for that field formatting class like I mentioned, it's the custom class on a field for display. GMap actually outputs the map on the node themselves and uses the location information. Then obviously, Location is for adding the address. It does the actual geo-coding on the back-end for us.
Data Migration. Initially, when we said okay, we're upgrading from Drupal 6 to Drupal 7, the initial thought is usually, “Okay. You just run a regular update.” But with any site that has more than like one or two content sites, usually you're going to run into some kind of weird problems and you end up spending a lot of time trying to fix stuff. My Preference, and I don't think I've actually ever done a regular Drupal 6 to Drupal 7 update, is to actually migrate data.
There's a couple of advantages to this. One is that you can exclude data that you don’t actually want anymore. You can also finesse the data, or tweak it a little bit if you need to change some stuff. Sometimes, an old site might have the date in a weird format and you want to use the UNIX timestamp in the new site. During migration, you can actually do things like you can actually change the way the data is. To migrate the data in this example in the site, I used the Migrate Module.
Now, in other modules that I used that works with Migrate is called Migrate D2D. This is a Drupal to Drupal Migration Module. It's build specifically to migrate Drupal 5 to Drupal 6 to Drupal 7. In fact, this is more or less I think what's pretty much going into Drupal 8's core setup, which is kind of nice. The nice thing with the D2D Module is it gives you a user interface, but the one caveat at the moment is that you need to use these two specific versions of the module; the RC1 of Migrate and the 2.1 B21 of Migrate D2D. Without those versions, you don’t get the user interface. So just be aware of that.
The way we did the migration is we initially first migrated our user across. What that does is it allows the old user IDs to be matched to new user IDs. Then when we import our content, say, Joe Shmoe created a page or also an event or something, his new user ID which is probably going to be different in the new site will then get correctly assigned to the node so you don’t lose your authors for the various bits of content.
The other thing you better watch out for when you're migrating content is that you migrate content in the right order. So users usually come first. If you have files to migrate, you want to migrate those pretty much next. In our situation, we have Tracks, Course and Event Nodes which are all nodes referencing each other. We want Tracks first because Courses need them, and then we want Courses before Events because Events need a node reference to Courses. You've got to migrate that content in the right order. During each migration of each type of content, a map is created by the Migrate Module and the map says, “Okay. This is the old node ID. This is the new node ID.” When I'm migrating the Event Nodes and I'm linking to Course which had an old node ID of, say, 25. The new node ID is what, 300 or whatever, it will map correctly and you'll get data linking to the right stuff.
The only custom work I had to do in this migration was for Event Nodes, which is one of the major benefits of Migrate D2D. That's the link for the module. It gives you a very nice user interface where you can click what the source and what your destination fields are going to be. You can manually set some fields, and basically you have to write a whole lot less custom codes. I don't think if you can see this too clearly, but basically on the left-hand side you're going to get your destination fields.
This is all running on the Drupal 7 site. You already have your content types created with a field that you want. So they're all listed on the left-hand side. The source field, which is the next column, you get a dropdown for all the fields from the content type that you're importing from and you can map them to whatever fields need to be. You can set a default value, which is the third column there.
Then in the last column is called the Source Migration. Once you've migrated anything like your users, you can what they call a Source Migration. That Source Migration is the mapping of the old user ID to the new user ID. If we were importing Event Nodes here, you would a Source Migration for your Course Node reference field so it would then map the correct course node IDs to the new nodes.
The custom module that we did for the events, I had to do that. There was no avoiding it because Migrate doesn't know how to handle the location field at all. I think it was called CCK Location in Drupal 6, and it doesn't have any migrate settings for that, so I have to do it manually. The location is obviously on the Event Node. We also didn't want to import all the very old events. We just want to basically the most recent and anything obviously that's going to be still coming up.
Let's have a quick look at the code that I did. This is very, very simple. If you didn't use Migrate D2D, you would then have to create the same custom module but you would then physically have to write in here all your mappings for each field. What your source field is, what is the destination field is, all that kinds of stuff. You'd have to basically write a whole lot of codes to do that. In this case, the most important thing that I needed to do was make each location field - so address, address to, cities, state, country, that kind of thing - available as options in the Migrate D2D UI. Then I can just simply map it to the new fields. What we do is, in your migration class, you create a new migration class and you basically pull in the main query, the database query that Migrate is going to be doing. You join in the tables that the old Location Module in Drupal 6 used.
The last line in the field, basically you say which fields you want to map. So if for whatever reason you didn't want to map the latitude and the longitude field, you could just exclude them. You don’t list them there and then they don’t show up in the UI. I pretty much just took every single column and if I didn't want to use it, I simply don’t map it in the UI. I just leave it blank. By doing this, I would then have all the location bits of data. A separate field that I could then map to the new location field in Drupal 7.
The other thing we wanted to do was exclude the old events content. So in the function prepare road, you do this kind of stuff. This allows you to modify your incoming data if you wanted to. Like I mentioned before, if your data was in a weird format and you wanted to change it to a different format, you could do it here. The other thing you do is you return “false” or something and that basically makes sure it does not get imported. What I did is I checked the event dates which is using value “2” which would be the end time of an event, making sure that that has passed. I check what the current time is right now, what the time I'm doing this migration. If “now” is greater than the event date; in other words, has the event passed? I return “false” which means, “Just ignore it. Don’t bother with this road. Leave it alone.” Then afterwards, you just need to return “true” and so if now it lists an event date; i.e. the event in the future, it's going to return “true” and it will continuing doing with whatever it needs to do to migrate the data in.
That's literally all that I needed to do and write custom code for the migration anyway. A lot easier than having to write hundreds of lines of code to do mappings and that sorts of other things.
I want to do some interesting views. Most of the content is normally accessible. We don’t really to do anything fancy. Except for if you want to have content displayed in a nice way in certain cases like the events having all the details on the right-hand side in a little block. The simplest way to do a lot of our stuff is using Views. Views is great because it has caching. You can do pretty much anything you want with it and it's the most used module, so everything works most of the time pretty well. We have used Views in various places to show things like upcoming events, the courses in this track as you can see here. These are all using contextual focus and, in some cases, relationships to actually pull in the data from other nodes that are linking to your current page or actually in the case of the event sidebar, showing content from the Event Node itself in a block. We do it on Event Node, Course Node and Tracks and I have a couple of administration views for some advance content management where I can search titles and that kind of stuff. The default Drupal content admin is lacking a little bit in some cases.
Like I said, Event Detail. This is actually a block created by Views and the View actually just pulls in the fields from the node that it's actually on at the moment and throws them into a block. Let's have a look at how that View is built.
This is the Event Detail Block. Basically, we're just creating an unformatted list. We have the field that we want to show in that block; signup, costs, state, all that kind of stuff. Obviously, always by default have it published and content type is for events.
Now, how does Views know what node it's on and what field to actually use? If you just did it like this and you can see it shows you just basically get the fields every single event node on the site, which is probably not what you want. We use a thing called Contextual Filters. Now, we use the node ID as a contextual filter. Let me show you how that's configured. By default, it says display all results from the specified field when both the values are not available. But what we do is we select provide a default value and the default value - you could specified a fixed value but we use the content ID from the URL.
If you look at an event node on our site, the URL is events/something and the name, the title. So it's using URLs. But in reality, the actual node URL is always going to be node/a number. In fact, the node ID. So Views knows this and it can always find that ID. It pulls in the I'd, it loads it up and it looks for the use fields and then generate a block for us. This is the node ID of that same node that you saw a little bit earlier, the Event Node. If you don’t have anything here, by default the query shows you nothing. There's no node ID.
Update the preview and you see all the fields. This is just the fields and they're pretty much they're in a raw state. We'll do some pre-processing on the View field to make them look all pretty. You can see it provided for you is just a straight text in-person, but when you actually look at the display here, it looks a lot nicer. Basically, what we're looking at is a simple contextual folder we're were pulling the node ID from the current URL of the node. So it knows, “Pull the information from this node, not any other nodes.”
Now, if we look at our Course Nodes, on our Course Nodes we show a block of upcoming events. These are events that have a node reference to the node you're actually looking at. So I call this a reverse node reference or a view using the reverse node reference. It's a little bit more complicated. Here's the View. In that table, we want to be creating a table, obviously. We want to show the title, date, cities, province, various information. Then we throw in a link to actually go to the Event Node itself. We have some folders. We have the exposed dates folder and country as well as an exposed folder. The magic happens in contextual focus again, using a node ID, as well as in this case, you need to use a relationship.
Because right now, if you used a straight node ID and you'll see it's being to be using the same setup where it uses content ID from URL. If you do that, you're looking at the Course Node because that's the node you're on at the moment but you want the Event Node that actually reference this Course Node. So we need to use a thing called a Relationship. Basically the only relationship that you can use are node reference fields. So we're using the relationship of field course, which is the field name that we use in the Event Node.
We just simply add it in and then we make sure that our contextual folder, content node ID, is actually using this relationship. By default it does not use the relationship, but like I said then you'll only be looking at the Course Node you're on and obviously you won't find the event fields. We use the relationship, it can then go through the reverse node reference and find event nodes that are referencing the node you're on and then show the relevant data.
Don’t worry if this stuff sounds a bit confusing, because it is. I struggle through it about how to set up these things. Once I've done it, I write down my instructions on what to do so, “Okay. User relationships, use the relationship on the contextual folders for the node ID.” That kind of stuff. Then if I don’t use it for a couple of weeks or a couple of months, I always forget. I just go back to my list of useful tips and find out how to do it. These are somewhat complicated things. They're not very intuitive. That's probably one of the more complicated kind of setups that we have for Views. We do this kind of View in various places. You can see it on the Track Nodes which list the courses that is using the same setup.
A little bit on improving performance. The biggest performance gain that we really got was just using Drupal 7 over Drupal 6. It has been caching of modules we use as much as possible. We have very little custom code. We only used custom code when it was absolutely needed. We try as much as possible to do everything with Views like you saw. I mean, you could write custom code to generate the blocks yourself but why do that when you Views. It does it all very well and has great caching. We actually only have eight blocks on the entire site and seven of them are actually created by Views. We have one custom block that creates the login link and it will use a profile dropdown when you're actually logged in.
Then performance-wise, for myself as the admin as the developer on the site, we were initially on SPN which is horribly slow. We managed to switch over to get the new site and it just makes my life a lot easier.
Maintenance. This one of the things where us as the admins, we're struggling a bit with handling a lot of the data and the content, dealing with certain events not happening or cancellation as I mentioned. So we created the Event Status setup, which depending on what radio button is checked, the Event Node will then automatically be published or unpublished. We do it using the Rules Module. So it will enter the value of that field and do stuff accordingly whenever the node is saved.
We gave our partners a lot more power to manage their own events. The screen show on the right is what a partner would see when they log in. They can see all their events. They can filter automatically by Confirmed and Unconfirmed which is Tentative and Cancelled events. The partners are the only ones who can see Cancelled Events because they're unpublished. We gave them bulk operations on each of these lists so they could then select the whole bunch of events and say, “Okay. All of these are cancelled.” Or, “All of these are confirmed.” As we go. We gave them also the option to override some of the stuff that's published and unpublished.
On the admin side, we use a theme called Shiny. It gives you nice big buttons. The text is a little bit bigger. It handles a lot of contract modules, like Views. It has scheming already for that just to make our life a bit easier. We could use 7, which is built in Drupal 1, but there are a few things I didn't like about it too much. Shiny just looks a lot nicer and fitted more with the front end view. The front end theme is Bootstrap. It looks a little bit like it. We can't actually use for the Bootstrap as the backend because Views does not work with it. Bootstrap requires jQuery 1.7 and the Views UI tends to break horribly if you do that with jQuery. We run jQuery update on the frontend but not for the backend.
Custom Site Module. Pretty much every site I've ever built is at least something that you want to write custom. You want to modify a couple of things, maybe tweaks to the user interface. On the admin side, override some theme functions. Field processing, that kind of stuff. You can also do some of those things in the theme layer as well, but sometimes you also just want to do in the modules so it's always ineffective regardless of the theme. So in Our Custom Site Module, we have things like collapsing the text format information. Below text areas, usually on the Drupal site, you can have a bunch of information about the text format using full HTML, those kind of things. Most of the time, people don’t really need to see that stuff as it takes up space.
I basically did essentially like a full alter and wrapped that whole little thing in a collapsed field set. Just using regular Drupal collapsible field sets. So it does it all by itself. I don’t have to write any JS or anything for that. I also added a documentation link just below that that information, so it's below the text area. That allows people who are editing the nodes if they want to add in some classes, to get some kind of an effect. Maybe to make a button or a panel or something like that. They get a link straight to Bootstrap information. They can see what classes they need to use, how they need to set up an HTML if they want to do that. That link was added in as well just to make life easier for everybody.
Then the Custom Side Module is also going to include some custom actions, which is what you saw with the partner/admin Cancelled, Confirmed, Unconfirmed events. Those actions we created and they're all in the module. Lastly, we use the module for the exportable. So Views, Rules, whatever else you want to export. All right.
That's pretty much it. If there are any questions, feel free to ask them now. I'm just going to the next slide. I'm just going to show you is, some of the modules we use that I may have not mentioned earlier. One was draggable Views. That allows our admin side people to reorder stuff in tables on our course listing views. You want to be able to reorder the courses randomly. It's easy to drag. You just look at page and drag it around. The Google Analytics EP Module allows you to add custom Google Analytics events on things. You just write a little bit of code. It's very simple AVI. You write some code and basically, you can say, “Okay. On this track, every button clicks to this button or for that link.” It will do it and automatically feed into your Google Analytics account. You'll be able to see events there of how many times people have clicked on Google and those things.
The other one, Menu Position, is for bread crumbs so you can say, “Okay. All Event Nodes should fall under the Upcoming Events menu item.” Then they get the right breadcrumbs. Just simple things like that's pretty much the main module to use for the site and use both operations obviously. That's pretty much it. Custom Modules, the Migration Module and the Toolkit Module. That's it. Any questions?
Heather James: Yes, I have a question, Dave. [Laughter]
Dave Myburgh: Sure, go for it.
Heather James: Yes. I don't know if I ever asked you. I'm curious, why did you use Views? I'm talking about the event display and the detailed information from the event, you put it over into a visual sidebar but it's obviously all the same node. Why did you use that instead of Display Suite in this case?
Dave Myburgh: Yes, a good question. I have used Display Suite on other sites and I do like it. We're only really doing something fancy on Event Nodes, so I don’t really see the need for slapping in the whole mess of things that Display Suite to do something fairly simple. If we had more content types and we needed to do more fancy stuff, yes, we could definitely switch to Display Suite to do that. Literally, this is the only content site where we were doing something like this. I did add some little JS to make this thing sticky. That was the other reason I wanted it in a sidebars so that when people are scrolling down, they'll don’t use the signup link as well.
Heather James: Right. Oh, very good. Well, another thing I wanted to know then about this issue, this choice that you're going to use, is obviously someone might hear this and think, “Oh, boy. There's like a map every time an event is loaded.” But you've obviously done some caching because it's a very speedy site.
Dave Myburgh: Yes.
Heather James: Could you show us how the caching configuration on that View?
Dave Myburgh: Literally, you don’t have to do anything. You just run it. You set up your View and it's automatically cached for you. The other thing is we use Varnish as a frontend cache. That also helps. I literally have not selected any specific caching. The default uses caching. It works fine with this setup.
Heather James: All right. Creative, cool.
Dave Myburgh: It's pretty straightforward. There's no craziness that you have to do with using Views. It's built-in cache is pretty much sufficient for everything.
Heather James: Cool. I was going to ask questions about like the use of Twitter Bootstrap and Views and then I realized; oh, we're going to actually talk about that next week. I'm really excited about that. It's made my life so much easier as well.
Dave Myburgh: Right. Yes. So yes, next week as Heather mentioned, we're going to talk about the frontend side of the site. How we used Twitter Bootstrap; how Views and Twitter Bootstrap can work together quite nicely. Grid system, responsive layout and all that kind of stuff. One of the cool things with the site and in fact, I didn’t mention it earlier is that the whole thing is pretty responsive and works really nicely on the mobile phone as well. It all works out-of-the-box for Twitter Bootstrap. You don’t have to do anything. You have to tweak a few things here and there obviously, but for the most part, it just works straight out of the box which is great saving me a little pain and something.
Heather James: Yes, and it all comes free. There's so much stuff that comes free with the Twitter Bootstrap. It's kind of shocking.
Dave Myburgh: Yes. I mean, all these buttons are just bootstrap classes. This little popup that you see in the black, that's just a bootstrap thing. There's a lot less coding and customization that you have to do with Bootstrap.
Heather James: Brilliant. Oh, gosh. I'm actually amazed. Hanna, are there any other questions from the audience?
Moderator: Yes. The first question that came in is; in pushing from SPM, did you just start with a new “get repository” or is there a tool to bring over all the history that is in SPM?
Dave Myburgh: I believe there is a way to bring SPM history across, but because the site is in Drupal 6 we didn't really bother. We didn't have a huge amount of history anyway. I literally I got the SPAM checked out and then just made that into a rule to delete the SPAM folder. It was pretty simple and then did the Drupal 7 Bootstrap on top of that to override the whole thing.
Moderator: Great. If anybody has any additional questions, can you please ask them now? Okay, I think that's it for questions. Heather and Dave, do you want to end with anything?
Heather James: Well, I just wanted to say I'm so glad that you could come in and do this presentation, Dave. The whole site is just so simple and really elegant. It's kind of funny when you're showing some of these tricks, it's like, oh, it means I didn't have to do a lot of work. I love your version of lazy [Laughter] and doing things in an easy way.
Dave Myburgh: I figure if I do things simple like that, it's actually going to save me a lot of time and you guys didn't have to come back and say, “Oh, wait. We need this fixing. We need to do this.” It's pretty much all done automatically.
Heather James: Yes, thanks. I'm looking forward to next week, too.
Dave Myburgh: Yes, thanks everyone for listening.
Moderator: Yes. Thank you everyone for attending and thank you, Dave and Heather. Dave especially for the wonderful presentation. We can't wait until next week. The slides and the recording of the webinar will be posted on the website in the next 24 hours and we'll also email you a copy. Thanks so much everyone.
Dave Myburgh: Thanks, bye.
Heather James: Okay, bye.