Drupal Step-by-Step: How We Built Our Training Site, Part 1

Unfortunately, the live event for this webinar has passed.
No need to worry! We always post the recorded webinar and slides within 24 hours of the event. Check back soon!

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:

Click to see video transcript

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.

Moderator: Great.

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.

Drupal 7 Tutorial: Features Module

Unfortunately, the live event for this webinar has passed.
No need to worry! We always post the recorded webinar and slides within 24 hours of the event. Check back soon!

Join Prasad Shirgoankar, Curriculum Developer, Acquia Learning Services for a step-by-step introduction to Features in Drupal 7. Features helps you package up configuration so you can move it more easily between environments. Prasad will also cover best practices when creating Features, and give you some tips to make it easier.

In this webinar you will learn:

Click to see video transcript

Moderator: Webinar is a Drupal 7 tutorial with the features module with Prasad Shirgaonkar who’s the Curriculum Developer for our Learning Services Department here at Acquia. We’re really excited to have Prasad on the call. Thank you, Prasad, for presenting to us today.

Prasad Shirgaonkar: Hello, everyone. So good morning, afternoon, evening to everyone. We are going to talk on the Features module today. Just a quick introduction of myself, I work as a Curriculum Developer for Acquia Learning Services. I design and conduct training programs on Drupal as well as on Acquia products. I worked for over 20 years and I have been working on Drupal since Drupal 4.7. Today, we are going to talk about one of the key challenges faced by Drupal developers. That is the configurations management challenge. Let’s talk about challenge first and then obviously we follow by the solution

Prasad Shirgaonkar: Yes. Perfect. Okay. So we’re going to talk about one of the key challenges and that’s about the config management or the configurations management challenge and obviously it will be followed by the solution. Let’s first look at the challenge, what exactly is the challenge first. If you followed Drupal’s recommended development practices, you will typically have a well-defined development workflow. A typical Drupal development workflow consists of multiple environments where your code resides. For example, you may have a local development environment, and a staging environment, and production environment there remotely. You do development on your local environment, you post your code to your staging environment, you do some testing over there, and once the testing is finalized, you push your code to the production environment.

Now, a Drupal site. Typically, the components of a Drupal site as you are aware are the code which are your modules and themes, the configurations which are the content types and views and vocabularies and all the configurations that you do using Drupal’s GUI and the content, that’s the nodes, and terms, and users blocks, all the contents which is added by users to the site. So typically, code resides in code files, so modules and themes are in their own individual files, the .module files and .tpl.php files, java script files, and CSS files, and so on. The content on the other hand, that resides in the database so the nodes and terms and users, they’re all form of the database. Up to Drupal 7, the interesting part was the configurations that we do for building a site like the content types and views, they also reserved. The definitions are also stored in the database.

Now, when you are doing the initial development of your website, copying your code and data or the database from your one environment to another environment, it’s a very straightforward process. So if you’re using some version control system like GIT, you just check-in your code into GIT and check-out on your stage environment and database, you simply take the database down from the environment and push it to another environment and all your environments are getting synced, obviously. When you go down the development stages and when you are doing the continuous development of your website, copying code is simply straightforward but copying database from an environment to another environment becomes increasingly difficult. In some stage, it might become even impossible.

Now, this is because the developer develops the code locally, he adds his own data and does the testing, pushes the code to staging environment. On staging environment, the client test users might add some data independently and when they add the data, they do their own testing and then the code is pushed to the production environment. In production environment, then there’s a live data, the actual data added.

Now, if you copy over your database from one stage, one environment to another environment, it wipes out the data off the target environment. That’s why it becomes almost impossible to copy all the data on the database or actually the configurations that’s stored in the database from an environment to another environment. So this is one of the most prominent challenges faced by Drupal developers. So how do we manage Drupal’s site configurations? How do we move configurations from one environment to another environment without affecting the data or content of the target environment? That’s the challenge that we are going to discuss today and as everything else in Drupal, there’s a module for that. That module is called as features. So what is features module? So this is the URL from where you can get features module, it is drupal.org/project/features. Features modules, as its own name says, it enables the capture and management of features in Drupal.

Now, a feature can be defined as a finite, a defined set of functionality or entities which taken together can satisfy a certain use case. So take the example of, say, a news article. So you have content-type name news articles. You can have a view in which produces various pages or blocks. You could have some taxonomy terms which are used for that particular content type. On that bundle together can create a news feature for your website. What features module does is that it converts and stores site configurations in code rather than in the database.

Now, here are various applications or use cases of features module. We can move your site configurations from database to code which makes it extremely easy to move between environments like the development, staging, and production. We can also check-in in a version control system, like if you just define all your configurations in the database, it’s impossible to check them in in a version control system. Say for example you want to revert back to a previous version of a view, which might be an extremely complex view, it’s absolutely impossible to do it without Drupal’s UI. If you convert that into code and if you version control it properly, you can very easily revert back to a specific version in the past. Another great application that it has got is that you can distribute these features as independent features or independent modules and re-use them across various sites. So suppose you are developing a large set of sites and all the sites require, say, use functionality or requires a user listing functionality or requires, say, a products catalogue. You create it once, you convert that into a feature, and you can use it across multiple sites to minimize your effort or minimize duplication.

So how does features module do it? Let’s have a quick demo of features module. I’m using my local environment and on my local environment I have this dev site and staging site. Now right, now both of these sites or both the environments are on the single machine but they could have been on completely different machines or completely different places, but for this demo purpose, I’m using it on just a single machine but two different code bases completely. So both the sites have almost the same set of modules, but different data. As you can see, the site names and the home pages and everything is slightly different. Now, suppose my dev site is having, say, a content type. That’s news and also a view, news, which pulls the data of that content type and displays it as a page. That functionality is not there on my staging site. Now, if I want to push this specific functionality from my dev environment to my staging environment, I first of all check if I have features module enabled, so I had downloaded and enabled the features module. So enable the module. Features functionality is available on the structure and features. There is no feature right now so I’ll just create a feature. I’ll give a name to my feature, let’s call it as “News”. Just give a unique description. A package, I can just give, say, “My features” and I’ll give a version for this particular feature.

Now, on the right-hand side, I can see various components that I can select. So inside this, what I’m going to select now is the news content type. It could automatically detect the various dependencies that are required to give news content type and I’ll also select news view. So I select all the features that I want to be bundled in this particular feature. I could either download the feature so that it will create code files and download it into a tar or open “Advanced options” and I’ll give a path where it can generate, give an existing path where it can generate the feature and I will click “Generate feature”. Now, if I go to my code base, I’ll find that under the site, so we’ll use the path which I’ve specified. It has created a new folder called the “news”. Inside, features has created several files which are these feature files. I’ll go back to my URL and go to features page again and I can see that it has created a new feature, the news feature which is currently disabled, so I’ll just enable it on the current environment.

Now, we’ll see the use kits; why we need it too or why we should enable it on the source environment. That we’ll be in a few minutes. So this is enabled, I have the news feature of news content type and view, now that’s bundled into a feature.

Now let’s move that to my target environment so just copy this module with folder, you go to my target environment and you’ll have the same folder features custom. I’ll just put it as that folder. Going back to my target environment, I’ll just check. I’ll verify features module is enabled, so you see that features modules is enabled. I can also see that this item module might be just inside that group, it’s the news module. I could either enable it from here or I can just go and check from my features site and I’ll see the news feature is added on my staging environment as well. I’ll enable it and bam, I have a news view added over here and the content types. I have the news content type added over here. So this has absolutely saved me a lot of time of rebuilding that content type as well as a view on the stage. It could be actually a bundle of like multiple content types and multiple views. You can bundle inside a single view, a single feature, and post it from one environment to another environment. So that’s the basic use case or basic use, basic application of features module.

Going further in the workflow of features module, what happens if we make changes to our configuration? So in the content type, say, news content type. If I want to add a new field later on, and I added a new field which is the location field and the text-based field. Now, this on the dev site, if I go to structures and features overview page, and I’ll also add inside the view, if I make some changes, say, I don’t know the behavior. So “no data”. So I’ve made some changes to my content type, I’ve made some changes to my view. If I go to structure and features now, it shows me the state as overridden. What that means is that the configurations which are stored in the code of features are now different than the configurations which are stored in the database. So I need to either to match them, I need to regenerate the code on my source site. So I’ll just click see what’s happening so that you can be sure that the database is different and I go to recreate, and under recreate, under advanced options, and just generate the feature. So after I generate, I’ll just view it again and make sure that it’s in the default state. Now, I need to copy the newly generated code from my source site, that’s my source site from where I’ll just copy this new and better code and I’ll just replace the code on my destination site.

So I’m just doing it fairly crudely over here. I really should be doing it and checking it in a version control system and checking out from that system in the real world. Now, if I go to my staging environment and go to structure, and features, just let me try clearing the cache. Okay, so it has the empty text as well as I can see that it has created on content types in news as either the new feed. So basically whatever changes I do on one environment, I can keep on adding, keep on just reflecting those changes or transferring those changes from one environment to another fairly easily with features module. Going back to our – let’s have some discussion on some other features of the features module. So some intricacies of features modules and how do we extend features module. There are some unique terminologies with features module. Those datasets that we saw on the features page, sometimes, that shows a state that’s overridden that we saw. There’s an option to revert or there’s an option to update the feature. So when we want to save, make changes, use site configurations in the database. When we do revert, actually what it does is that it changes the configurations in the database to match with that in the features module’s code. When we update a feature, what it does is that it creates and produces a newer version, a newer code versions between the configurations from the database.

So these two terms are used quite often with features module. The key question that people asked is that what exactly can be ‘feature’ized? So these are the things which can be ‘feature’ized or which the configurations can be stored in features module. From the core, we can store content types, we can store vocabulary definitions, user loads, permissions, field definitions, text formats, menus and menu items, and image styles. They all can be exported to a feature. From contributed modules, we can store the views definitions, panels, mini-panels, rules that we use for sites, context, as well as the display suite configuration. These all can be ‘feature’ized and many, many other contributed modules. They can export their own settings to features module. What cannot be ‘feature’ized are field like content. So things like nodes, terms, users, and your custom blocks that you add, and the native blocks that you add to the site. These cannot be ‘feature’ized because that’s content and they cannot be stored as a part of code.

A couple of advanced usages of features modules, if you use the module called the Strongarm module that exposes Drupal’s entire variables system to features which basically means that you can export things like your site name, the site slogan, or your team setting, and anything that is stored in the variables table that can be exported into a feature. If you use Diff module, you can actually compare when it shows that feature is overridden. It shows what exactly is the difference. That, you can be using Diff module. Features module has got fantastic integration with Drush. There are lots of Drush command like we can lift all the features, you can see the components of an individual feature. You can see the differences in the feature, in the database and the code. You can expose features, you can revert features, and of course you can update features. So these are all the extensions or advanced uses of the features module.

Just a little slide on resources, where you can find all these, so features module on drupal.org is at drupal.org/project/features, then comprehensive documentation along with examples on drupal.org, and the links for Strongarm module, and Diff modules. So this was a brief presentation about the features module, its use cases, and how to use that module. I’m open for questions now.

Moderator: Great. Thanks, Prasad. If anybody has any questions, could you please ask them now in the Q&A section? We had one come in so far. Can installation of features be automated during Drupal installation like installation profiles in some way?

Prasad Shirgaonkar: Yes, perfectly. It can be. So when you create features, they actually become like your modules. Sorry, just a minute, I just stopped sharing my desktop. Okay. When you create features, they become like modules and you can include them as part of installation profiles and they can be automatically enabled while installing new sites.

Moderator: Awesome. The next question is using Drupal 6 here still. Is there a very big difference between 6 and 7 in the features module?

Prasad Shirgaonkar: Yes. The main difference is in the URL features module but the core, I think, that it does. The core content, the core entity that can be exported. That hasn’t changed.

Moderator: Okay. As a reminder, slides and recording will be posted to our website. I think that’s it for questions. If anybody has any follow up questions, you can reach out to me or Prasad and we can get them answered for you. Prasad, would you like to end with anything?

Prasad Shirgaonkar: No. I just would like to say that for doing the normal day-to-day, Drupal Development workflow, and if you are especially working on complex projects, features is an absolutely must have step in your Drupal workflow. It saves a lot of time for development as well as keeps our code, our configurations completely under our control. So it’s absolutely worth spending time and exploring that module. Make sure that you use it and make it a part of your day-to-day workflow.

Moderator: All right, thanks so much everyone. Thanks Prasad.

Prasad Shirgaonkar: Thanks, bye.

- End of Recording -

Why Interscope Records Ditched the Digital Marketing Suite

Unfortunately, the live event for this webinar has passed.
No need to worry! We always post the recorded webinar and slides within 24 hours of the event. Check back soon!

Don’t let another vendor determine your roadmap and digital priorities. Your customers are unique, and your digital experience should be too. It’s time to adopt a digital marketing platform that lets you pick the products you need, to drive your individual business results.

Adding Multilingual Capabilities to your Drupal Site

Unfortunately, the live event for this webinar has passed.
No need to worry! We always post the recorded webinar and slides within 24 hours of the event. Check back soon!

Adding Multilingual Capabilities to your Drupal Site

Drupal comes in 180 languages and is used by people in 230 countries/territories. In this short webinar, our architect will take you through the process of setting up a multi-lingual site.

You will learn how to:

  • Create page-level and field-level translations
  • Translate interfaces
  • Translate menus
  • Add a language selector to your site
  • Auto-determine the visitors language.

Create a Symfony Application from a Drupal Perspective

Unfortunately, the live event for this webinar has passed.
No need to worry! We always post the recorded webinar and slides within 24 hours of the event. Check back soon!

The inclusion of the Symfony framework into Drupal 8 can bring with it many questions and concerns from Drupal enthusiasts, both beginner and veteran alike. In this session, we'll create a simple Symfony 2 project from start to launch, including a quick template with Twig, and correlate each step of the process to the equivalent Drupal steps.

Attendees will come away with:

45 Modules in 45 Minutes

Unfortunately, the live event for this webinar has passed.
No need to worry! We always post the recorded webinar and slides within 24 hours of the event. Check back soon!

Drupal is a great CMS, but not all features come right out of the box. That's where modules come in! Did you know there are over 7,000 extensions (or add-on features) for Drupal 7? Figuring out which modules to use can be a real challenge!

Don't worry, the help you need is here. During this session we'll walk… jog… okay, actually run through 45 of the best and most popular modules in 45 minutes.

In this webinar, you'll get an overview of each module, including:

Story of Multnomah County: Migrating from Vignette and Building a Drupal Ecosystem

Unfortunately, the live event for this webinar has passed.
No need to worry! We always post the recorded webinar and slides within 24 hours of the event. Check back soon!

Three years ago, Multnomah County took an aging Vignette website and migrated it to Drupal. They have not looked back.

The cost benefits and development options led them to launch 23 other sites and applications on Drupal—including two that won awards Multco Commons (intranet) and Multnomah County Library web site. (MCL is the second largest Library in the U.S. by circulation with nearly 9 million visitors per year.)

From PSD to Drupal Theme

Unfortunately, the live event for this webinar has passed.
No need to worry! We always post the recorded webinar and slides within 24 hours of the event. Check back soon!

The problem with creating a Drupal theme is—once you know how—it becomes intuitive. Themers spontaneously transform design files into complete Drupal themes without realizing all of the little steps their brain takes to achieve the final solution. It's sort of like those “learn to draw a cat” books which take you from a basic circle to a perfectly sketched cat in four "simple" steps. In this webinar we'll remove the mystery and teach you the step-by-step strategies themers use to create amazing, extensible themes.

Click to see video transcript

Hannah: ...from PSD to Drupal Theme with guest speaker, Emma Jane Westby, who’s the educational development coordinator at Drupalize.Me. We’re so thrilled to have Emma on the call today. She’s been teaching people how to theme for years and in her first book, Front End Drupal, it was consistently cited as the best book to learn Drupal theming. With this video series, she’s brought them up to date with Drupalize.Me and she’s going to highlight everything on this webinar. We’re really excited to have you, Emma.
Emma: All right. We should now be able to see the slides as well. Hopefully that’s something that you can see. I'm going to get started. I'm going to try and keep things onto under an hour so we can have some questions and you can get back to your day. I do tend to get excited and ramble on about side bar topics. So I’ll try and stay focused as we go through this today.
As Hannah mentioned in the introduction, thanks so much Hannah for your introduction, my name is Emma Jane Westby. If you do want to communicate with Acquia and with me on Twitter, I'm “emmajanehw.” Or you can also get in touch with me at “drupalizeme”, all one word, also of course at Acquia. Those are how to stay in touch during this presentation.
A little bit about me. There we go. As I mentioned, my name is Emma. I work for Drupalize.Me as the education development coordinator. I am a beekeeper in my spare time. Of course, being from Canada, it’s the middle of winter right now and my bees are inactive. It is something that I enjoy doing, outside of the Drupal realm. Let's see if I can make this even bigger again. There we go. Don’t lose my Skype window for communication. So we’ll put that over here. Then come back to - oh no, I lost Chrome. That’s always the challenge with these things. There we go. Are the slides back? [Laughter]
What we’re going to talk about today and that link in this slide is actually to a copy of the slides, so if you want to follow along in your web browser instead of following along in the WebEx screen, that’s the way to go ahead and do that. Today, we’re going to talk about PSD To Theme Strategy. I'm going to talk about theming by component, which I think is the most solid way of approaching the PSD to Theme problem. We’ll talk a little bit about front-end documentation and then toward the end I've got a section of useful tools with links, and if you're grabbing the slides then all of those would be linked for you.
Let's go ahead and get started on strategy part. A sort of fun quote that I'm going to kick us off with here is, “Are you new to front-end web development? Here’s a secret. No one else really knows what they’re doing either.” That’s from Nicolas Gallagher. It’s just kind of a check for yourself to say, “This stuff seems confusing or frustrating or in any way overwhelming, it’s okay." Because quite frankly, this industry, in terms of front-end development, is moving so quickly and it’s kind of complicated for everyone who’s involved. This strategy is one that I'm been working on for a number of years, but it doesn’t mean that it’s the only way to approach the problem. There’s going to be lots of other ways of doing this. This is one that I found works for me and for the students who’ve been learning theming from me over the years.
It basically looks like this. We’re going to go from PSD to Theme step-by-step. By doing that, we’re going to focus on the individual components. The first thing we need to do is we need to identify the design components. Then create a library of basic styles according to SMACSS convention; adjust Drupal class names to match style component names; then finally, look for bugs and refactor component styles to match the design. I said the word SMACSS there, that’s one specific way of structuring your style guide. I’ll talk more about the actual implementation details and what SMACSS means towards the very end. I don’t want us to get overwhelmed or bogged down with some technical jargons that it just kind of doesn’t matter. We can look at the essence of what SMACSS is and get huge value from it.
For the essence, what we’re going to do is focus on three questions to identify our design component. We’re going to ask ourselves: What’s the shape of our design? What’s consistent? And what can be moved around like furniture? Now, let's take a lot at how this actually played out using a very simple design. This is a design that I've been using for years with my students. It was originally designed by Betty Biesenthal, who’s a Canadian designer in the Ottawa region, and it’s been modified by students to be any number of different designs. The thing I like about it is that it’s very simple and yet has a number of Drupal elements in it for us to play around with.
So, going through our three questions. The first one that we’re going to focus on is “What’s the shape?” These are essentially your layout tools for SMACSS conventions. What does that mean? The first thing that we need to do is we need to identify the grid. It’s really important when you're doing the design to theme process that you talk to your designer and ask them ahead of time to select the grid framework that they’re going to use to design the webpage design. Knowing ahead of time what the grid framework is is going to very quickly snap elements together later on. What I've got here is a design that was originally created with a 960-grid framework. Now, this isn’t necessarily the best starting point for you today, but at that time this was absolutely appropriate and the one that we decided on together. It means that when we actually snap things in place, I can very quickly use the class names that the designer had in mind when she created the design. Number one, identify the grid.
Number two, identify the containers. We went from 12 grid columns down to a three-column layout. Working from left to right, we can see you’ve got essentially a navigation column, a feature column where stuff is highlighted and then over on the right hand side we have our content column. Once those containers are in place, what I’d like to do is essentially abstract the design to a wire frame where you may have started with wire frames, this is taking you back to that abstract concept. The reason why I want to do that I is I want to be able to use text words to describe our design. I want you to, as you're thinking about your design, write down the layout rules that you would want to apply to your design.
This is essentially the shape of your website, including the number of grid columns for each of those containers that you identified. For example, the banner area with a large image and it was 12 grid columns wide. The navigation area, the left column has two grid columns, the featured area with four grid columns, et cetera. Using text at this point seems a little bit weird because we’re working with a design but as we’ll see in the next section, this allows you to really easily convert your design into code, if you start using words at this point. That’s the first one, our layout rules.
The next one is “What’s consistent?” These are typically your base or global rules when we’re talking about these SMACSS conventions. What do I mean by “What’s consistent?” I mean the things that are essentially represented by HTML element elements within our design. For example; the headings, the paragraphs, the links, what’s going to be the same from page to page regardless of where it is in your design? Of course, using again our words, I'm going to get you to write down your base rules as part of this process. For example, what are the colors that have been applied throughout the site? We had most of the text was dark gray. Our headings were a lighter gray. We have two different accent colors. Some were green, some were brown. What were all of the things that were the same, but instead of using a picture use some words to describe it.
Finally the third part, “What can be moved around like furniture?” These are going to be our components. In the SMACSS convention, Jonathan refers to them as modules, which for Drupal purposes has some pretty obvious meaning convention clashes. So we call them components instead. Now, think about furniture. It’s anything that you can pick up, move around and put in a different location. The tool that I like to use for this is stitch. Basically, a screen capture. Anything that I can draw a box around in my design is a really great candidate for a component. So if we pause at this point and take a look at out screen, we can see that we’ve got how many - and just in the chat window - how many navigation components does it look like I have? I'm going to try and find the chat window, hopefully, as you write in your answers. I may not be able to find it because I'm doing full screen. [Pause] There’s my chat window. Okay.
Let me make this bigger again for you without going full screen. Great. Okay. I see your answers coming in here. You're absolutely right. Two or three navigation components, potentially, based on the way that I've caught up this design. It’s difficult to know, isn’t it, because our furniture linens and dishes are those navigation. We have no idea. So it’s really important as you're developing these components to have very clear conversation, or communication channels rather, between your designer and your front-end developer, because the information is not necessarily captured in the design alone.
Now down on the bottom right hand side, I've got a pink box around portfolio. That’s another one that we’ve got a component there, but it’s supposed to be two things or is it supposed to be one thing? I would say that the furniture is anything that is at its smallest unit. For example, portfolio looks like trends. Those are replicating one another so the component would actually be only one of those and how they get displayed in context could be another component. We want to make this stuff as reusable as possible. So, again, following along with our rules. First we identify things and then we need to write them down. These kind of get difficult to capture in words at some point. For example here, I've got that plate with the furniture linens, dishes and we don’t really know if that’s going to be a set of links or if it’s just a picture of words. Writing down the components and handing them back to your designer allows you to have that conversation to say, “Is this what the design means? Is this how I should be building this out?” In a way that you wouldn’t necessarily have a conversation if you were relying on pictures alone.
Now that we’ve got our three areas defined; our base rules, our layout rules and our component rules, the next thing that we need to do is actually document those rules. I use plain text or mark down to create the style guide or not really a style guide but a text description of the design. This is a really difficult one for me because text seems so inelegant. In the chat window, can you go ahead and write down what are some of the other ways that you have used to describe how the design works to your front-end development team from the design team. So what are some of the tools that you use to make that communication more efficient? I really like plain text, but I know that it’s awkward to work with. On the little sent-to box, if you go ahead and click that you can send your message to all attendees and then everyone can see what the other people in the webinar are using.
We’ll let those answers scroll past. Again, the question was, “How do you currently communicate the design decisions to your front end development team?” I said that I really like plain text, and I’ll show you why on the very next slide. I know that this is a little bit unconventional. The permission may be turned off for all attendees and I may have it because I'm a panelist. I’ll get Hannah to double check that one. All right. I have the answers come flowing in.
Let's take a look at why I love working in plain text. Here is the reason. By working in plain text, I can very easily convert that information to code. In other words, by using words to describe your design files, you can easily convert the text representation of the design into code. I sort of used my air quotes on that one. SASS and CSS. Using the SMACSS convention. Our shape definitions become lay out rules. Our what’s consistent definitions become the base rules and the furniture become the component rules. SMACSS has all kinds of ways of storing the SASS files, storing the CSS, that will directly relate to these plain text styles that you’ve been writing up until it makes that conversion really easily. That ultimately is the essence of why it’s so hard to go from PSD to Theme because you're going from picture to code. Plain text I found to be a great intermediate.
Let's take a look at how this actually looks when we’re working within our SASS files. Quickly in the chat window, can you let me know, have you ever worked with SASS before? So just a quick yes or no. Hopefully, you’ll be able to convert by the end of this webinar. [Laughter] I think for mostly people who haven’t - oh! This is so exciting as I get to convert all these new people. Yay! [Laughter] Okay.
The reason I love working with SAS is that - you know how CSS based layouts are really frustrating and difficult and impossible to be semantic, right? Take a look at this code snippet that I've given you. We have here - what’s that, maybe a dozen lines of SASS and what I have done. Now the green bit should look familiar. Those are your ID selectors in CSS. What I've done is used a little bit of fancy magic in terms of the SASS fancy magic as well as a plug-in, shall we call it, for the 960-grid framework. All I do is I say when nav is used, I want you to use all the fancy magic to make it two-grid columns wide. That’s it. That’s all I have to do. So my layout SASS file is basically only this. If you follow the link from the slides - and I’ll have to link again at the very end of the presentation - if you follow the link to those slides, you can get to the repo to see this finished theme of how all this stuff fits together. It’s super simple, right? Where we had our text based description of how the layout worked, we had like - bare-12. All we need to do in our layout file for SASS is to say, @include grid [12]: and everything else it taken care of for us - so much better than the old way of doing things.
All right. So that’s the layout. That’s the easy one. Next we go into base. The awesome thing about SASS in this case is that I have variables accessible to me. Thank goodness. Trying to remember to change all the instances of #336677 or whatever your colors are is a complete pain in the butt, isn’t it? So with SASS, what I can do is set up my variables and them simply reference my variables throughout my SASS files and get consistent colors all the way through.
Finally, we had our components and this is where things get verbose, shall we say, because there’s going to be a lot of components in any of the particular designs that you're working with. The component should be reusable. This is going to take a fair amount of refactoring as you start working with your design and building at your Drupal site to make sure; have I got the right unit of design in my description so that I can reuse some of those components? In other words, .news/teaser, that class name, can I use it in as many - very similar to less, Laurie. Absolutely. Yes. Can I use it in as many places as possible? Is it the most reusable style that I can have for this particular component throughout my site? It takes some playing to make sure that you’ve got the right amount of detail. That’s kind of the tricky part is that components sort of balloon out. On a complicated site, you may have 100 different components that you're working with. All right. Now, that’s all the style stuff. That’s the description of what we’re doing, but we haven’t touched Drupal yet.
Let's take a look at how this actually gets applied to Drupal. The very first thing that we need to do is we need to build our Drupal site. With your components in mind, you can actually take all of those stuff files that you’ve got and start building things in Drupal. Now, the reason to start on the design side is that you need those descriptions in place to figure out what to build, but the Catch 22 here is you can’t actually apply the styles if you don’t have things being rendered on a page. So there’s this horrible kind of seesaw or back and forth where you need to have both things existing before you can move forward. Which one do you do first? Some people love to build out their Drupal site entirely and then come back to their theme. Some people love to stub out - stub out is kind of a short way of saying, “Create what you think is going to be the right thing and then fill it in later.”
So which one do you want to work with first? You want to work with the theme first or the Drupal site first? To be honest, it right depends on the project for me. I don’t have a right answer on this one. You have to have your Drupal site built before you can finish your theme in any kind of sane world. All right. With that in mind, let's take a look at what we need to do to establish our theme. What we’ve got here is the theme folder. You can see that I've got a .info file and that I've also got the CSS, the SASS or SCSS files, JavaScript images and templates. Templates would be like our page.tpl.php files; that can take - RB file is part of the SASS and Compass set up.
Although optional to work this way, I think you’ll find that using the tools that I've outlined - again, I’ll have all the links at the end - using the tools that I've outlined to build this up means that a lot of these decisions are already made for you. My kind of protest, my hesitation on this one, although I don’t use a base theme when I'm giving the example of how this theme is built. Which again, you can download at the end. I don’t use it base theme because I'm trying to simplify the process of design to theme. If you have specific requirements; for example you want HTML 5 not XHTML - is it 1.0? I can remember what Drupal core is for Drupal 7. If you want HTML 5, use a base theme. Goodness gracious, don’t do that by hand. If you want a grid framework, it could be that something like - grids or Omega or Fusion. There are lots of base themes that will provide you with a grid framework out of the box. Use a base theme. If you need accessibility compliance, I wouldn’t try and do that stuff by hand if I'm also doing some heavy theming. I’ll rely on a base theme to take care of that for me and also the responsive people. So although I don’t use a base theme in the sample theme, it’s because I'm trying to focus on something else. People are saying all kind of different favorite grids and we’re actually working with Susie on the Drupalize.Me site. So that’s another one to throw into that mix.
Okay. We’ve built our site in Drupal. We’ve got our theme kind of sketched out and now, the next thing that we need to do is we need to adjust to the template file page.tpl.php and apply the layout classes from your style guide. Now, in this case we can also insert some hard coded images, for example, the banner. This is a fraction of the page. You can see over on the right hand side, it’s there and all the rest of it. There are two things to note in here. One is that this is not semantic. Now this was the old way of doing things and the disadvantage of not using SASS is that I had to use the class names provided by the 960-grid framework. So grid-12, grid-4, grid-6. There is this Omega thing and an Alpha thing. It makes it more abstract. It makes it more difficult to understand. But when you download the new version of the theme, you’ll see that all of that stuff is semantic - so much better to work with. Okay.
We adjust page.tpl.php to match the class names that we’ve given our theme. We’ve got all these things ready to go. The next step is to finally launch a minimum viable theme. We haven't really figured out anything for sure-for sure, but chuck it onto your site and see how does it look. Did the layout work? Did things happen correctly? Are things broken? Is my layout happening in the right way? Once you’ve got that minimum viable theme, now it becomes much easier to do the dance between the design, with the theme files and the actual Drupal site. It’s easier to go back and forth once you’ve got something as a starting point.
Finally, we’re going to apply the remaining styles. Now, there are two kinds of style on this one. The easy way to apply a style is to alter the SASS files with extend so that you're not renaming any of Drupal’s weird class names. You're basically saying my semantically correct class name is the equivalent to Drupal’s weird class name. This is kind of - it’s not exactly the purest way of doing things, is it? The purest way to do something is to use template.php and actually insert your class names so that your class names appear on the rendered page. I have to admit taking the high road takes a lot more work. You’ll need to decide for your particular project, is this something where the mark up and the semantics really matter? In that case, go with the high road. If it doesn’t really matter and you just some cheap and easy wins, just use SASS’s extend and get your CSS output using Drupal’s weird class names. But the original sort of definitions and use yours semantically awesome class names.
Then as you go through each of those pieces of your site, each of those components, you can look at them as those individual little screen shots. Those little blown out boxes and you can refactor the things that aren’t working. Remove the styles or fix things that aren’t working. Don’t forget to clear cache as you're fixing things. Then repeat. It becomes easier to target each of those individual components if from the very beginning you’ve thought about how your design is structured as very separate and unique pieces. Then you see them in the Drupal site and pull them back in together. You can isolate out those elements. I find that a lot of where people who are learning to theme get overwhelmed is that it’s all one big page. If one thing’s broken, the whole thing’s broken. So how do you separate out each of those different elements or each of those different components? Do it right from the design phase and it’ll make it a lot easier to fix things at the Drupal level.
Now let's get into the guts of the tools that I've been talking about. I'm going to go through basically four different kinds of tools. Again, if you want to be able to follow the links, go ahead at lb.cm/psdtotheme-acquia has a link to the slides. You can check them all out. If you are on the HTML of the slides already, quickly hitting escape on your keyboard will zoom you out and make it much easier to navigate between the slides. I'm using reveal.js for this one.
Let's take a look at these tools. For our style guide. There’s not really a tool here but what I've done is I've described my components as text images and code. My pro tip on this one is make sure you weed your style guide daily. Do not let that style guide get out of date as you're building your theme. By using plain text, we can put the information as close as possible to the code and also very easily store it next to your code. For the Drupalize.Me team, we actually have our text based style guide inside the project repository with all our Drupal files. It becomes really easy in terms of location to keep the information up to date.
Hannah mentioned at the very beginning of the webinar that there’s a video series that goes along with this sort of quick overview and that’s the link to this specific video within that - I think there are 21 lessons altogether. That’s the link that goes to the specific lesson. You’ll need to be a Drupalize.Me member to view that particular video or an Acquia Enterprise participant. That gets you a seat in Drupalize.Me. I'm sure Hannah will be able to help you out with those of you who’ve got Acquia subscriptions but aren’t quite sure how to access that. So it’s number one. Style guide.
Let's go onto the next part. SASS and Compass. My tips here are to ensure your styles are modular and that your CSS is reusable. Use a relevant startup kit for your particular project. Now in my case, I was using the 960-grid framework plug-in, which I found in GitHub, which had a little starter script for me. Your starter kit does not need to be a Drupal base theme. If you are completely new to SASS and Compass, we’ve got an entire learning series on SASS and Compass.
The next one, the grid frameworks. Choose a grid framework during the design phase and either use the extend directive in SASS to make your good framework semantic or as I mentioned before you can use the high road or the hard way. [Laughter] What the template .php edits. We've got a video lesson for this one as well. The next one here, these three are all links. You’ll definitely want to go ahead and grab the slides to follow those links. These are the resources on applying SMACSS to Drupal. Now, the thing that I haven’t really told you up to this point but I think you’ll be kind of excited about in Drupal 8? In Drupal 8, the CSS coding standards that we used are based on the SMACSS principles. I'm just going to put into the chat window here. I took out the slides that talked a bit more about SMACSS; Scalable Modular something CSS. Can someone follow that link and type in what the SMACSS stands for, please, because I also get it wrong.
The Drupal 8 conventions are specifically using SMACSS. You don’t need to wait for Drupal 8, though. These are lessons that you can start applying in Drupal 7. Paul was mentioning that the Zen starter theme is also based on the SMACSS conventions. There are other conventions as well. There’s - as the name in convention. If you were a front-end developer, please go ahead and put in to the chat window what some of these other conventions are. Those links there are some of the resources that you can use. But dominate the theme layer is a video that of that method whose last name I will butcher so I won’t try and pronounce it. He's in Munich? If you want the high road or the hard way of getting those class names into Drupal. He gets some really great tips on how to go ahead and do that for the advanced front-end developers in the group.
Those are the resources. Now, let's go through quickly the summary. “Theming by component makes stronger connections from your static design files to Drupal much easier.” “Incorporating the right tools early in the process makes it easier to snap pieces together later.” Think back to that slide where I only had about 12 lines of SASS and that was going to snap together my entire layout for the site. Then finally, “Theming can’t exist without a Drupal site." You can’t theme something which doesn’t exist. You can create styles but you can’t truly apply those styles without the underlying markup and that dance between Drupal and the design files is what makes theming so exciting, I think, for front-end developers. Do I want to change Drupal? Do I want to change my SASS or my CSS files? At what point do I make decisions for one or the other?
Here’s the link again to those slides. I think there are half a dozen or more slides at the end. Just some extra resources in terms - I'm just going to hit - here we go. There are some extra diagrams here, a couple of extra links if you go and take a look at that deck.
I think we have maybe about 20 minutes for questions. This is the end of my formal presentation, though. If you're short on time, click the link. Make sure you got those resources but that’s all I've got for you in terms of a structured presentation. I would love to be able to - I will put into the chat window. Yes. You could copy and paste. lb.cm/psdtotheme-acquia, there we go. That should be clickable. Let me try that again. If you start putting in your questions - there we go.
Hannah: Awesome. Thank you so much, Emma. If you have any questions. Could you please ask them in the Q&A section? We had a first question come in. “I love the idea of variables in CSF. How much time can I expect to begin using SASS and Drupal as a novice themer who has never used it before?”
Emma: I found it really easy to pick up, in part because it was a tool that I had been wanting for so long. Now, there are more complicated ways and less complicated ways of doing SASS. The concept of a variable, just in terms of assigning colors, is super easy to do. So that part of it doesn’t need to be complicated. If you just look for general resources on SASS, and Compass gives you some extra preset shorthand things that you can take advantage of. You don’t need to use Compass in order to use SASS is what I'm trying to say. There is a lot of resources on the internet, but just using variables and just using SASS I would say that’s something that could figure out within a day.
Hannah: The next question is, “How do you handle responsive elements from PSD to Drupal?”
Emma: We could do a whole video lesson on this, couldn’t we? Or a whole webinar. It’s a really tricky question. I think that one of the ways to approach it is to start thinking in components that have the context of a page or a larger viewport. When you're thinking about an individual component, how does that component behave at large or small screen sizes? I get really frustrated when people say, “Oh, a designer shouldn’t be using Photoshop anymore.” That’s crazy. That’s your creativity tool. You should be able to use whatever you want as a designer in order to think creatively about a problem. That doesn’t mean that it’s the best delivery tool for the front-end team.
If you have the HTML slide pulled up, remember that picture that I had where I had boxes on top of the gray box of the different components? If you can get your design team and your stakeholders to start thinking about components instead of just pages, I think it becomes easier to design responsive sites. Because you're thinking about how does that component exist within the context of the viewport. Hopefully that answers your question although it is, like I said, it could be an entire life [laughter] worth of trying to figure it out. It is a tricky problem.
Hannah: The next question is, “I have Drupal commerce site that I’d like to convert SASS Compass in the next re-design. How do I convert an existing theme to these frameworks?”
Emma: Really interesting question. There are a few different things to think about. One is what are you trying to get from the grid framework or from SASS? Then the next step is to figure out - are you just sorting CSS into different files in terms of their components. Are you adding in a good framework? SASS itself doesn’t give you much. It gives you the ability to do variables. It gives you the ability to do components. SMACSS gives you the idea of conventions in terms of the base and the layout and the component rules. So there are lots of different pieces. You don’t need anything in order to do that rewrite into SASS. It’s more how are you going to use SASS to take advantage of things? Are you going to be adding in a grid framework. If you’ve already got a good framework and you want to rewrite things in a more SASS-ish way, is there a conventional or is there a plug-in that’s set up which can give you some pointers on that? What can the tool do, but also what do you need it to do?
Hannah: The next question is, “So using a base theme to start and then create your own theme using SMACSS and add extend base theme class is a legitimate Drupal theming process?
Emma: If you can make Drupal look the way you want, I would say that it is a legitimate theme. It may not be a best practice, but best practices are constantly changing. Three years ago, I taught people to make really specific CSS selectors that targeted very tiny bits of HTML fragments of various specific used cases. That might have been like; include a note ID as part of your CSS selector. I would never advocate that today. Yet, it’s only because of SASS coming in that I can say, “Be more semantic in your markup.” It doesn’t add a huge cognitive overload when you're just learning it. It doesn’t add a huge amount of time, necessarily, because we didn’t have a new tool. There’s a lot of different things that I've introduced here today if you're completely new to front-end development, but pick the pieces that work for you. Certainly, I encourage you to learn these new things but also, if it’s not working and you just find yourself banging your head against the wall, just make it work for you. [Laughter] Don’t let the tool get in the way. What’s the expression that Jeff Robins uses? “Done is beautiful.”
Hannah: We had some more questions come in. This person was just wondering if they missed this but wondered, “If Photoshop isn’t the best tool for design to front-end, then what is?”
Emma: That’s not what I meant to say at all. What I meant to say is that designers should be able to think creatively in any tool that they find useful. Many designers are trained in Photoshop and they find that Photoshop is the best tool for them to be able to think creatively. I do not advocate against designers not using Photoshop. I think designers should be able to use whatever tool they want. However, when you are working with Photoshop you are confined to the idea of a page so the way that you combine the components within Photoshop can be difficult to create the variations for responsive web design.
As you're doing a design delivery, don’t simply think of delivering a single page as a designer, but perhaps think about delivering components which have been designed in Photoshop. Photoshop as a great tool for idea of creation, but the static PSD file is not the way that the web behaves. Use it to think creatively, but - it would be crazy if you did a Photoshop file times every single different combination of factors that existed on the web today. Designers, you don’t have time to do that. There would be so many variations that you would have to hand off. Instead of thinking about designing pages in Photoshop, think about designing components and what’s the context that it’s going to fit in, what are the relationships between like a full screen desktop layout versus a handheld? How does that component behave in those different places?
It’s not right or wrong to use Photoshop. It’s just what’s the handover piece. In some cases, it’s going to be a Photoshop document. What is in that? Is it a component? Is it a fraction of a page? Is it a whole page? Is it here are 50 different components and three wire frames that they fit into? How does that work? I see someone in the comments saying, “I use pencil and paper for design." Absolutely. Designers should be allowed to use, whatever tool they feel most comfortable in for the idea of creation process. I’ll get off my soapbox now. Go ahead. [Laughter]
Hannah: Thank you for clarifying. The next question is, “Do you use PSD slices, name your slices in export or is that overkill? Or is it just situational based on the design?”
Emma: Definitely situational based. My dirty little secret is that I do very little work in Photoshop. I mostly use GIMP, which is an open source equivalent to Photoshop. There’s a lot of built-in things for Photoshop in terms of layer effects or effects just generally which don’t translate well into GIMP. So I generally - when I'm working with a designer, I have them export exactly the assets that I want to insert into my design. Whatever process works for your team is the right process to be using. Just I have a conversation with your frontend developers. Do they want slices? Do they want things made in Photoshop? Do they want assets extracted with a pane that shows on how it all fits together in the context? Like I said, whatever works for your team is the right approach.
Hannah: The next question is, “What framework should I be choosing from the beginning of a project?”
Emma: That’s a really difficult question, because I don’t know what you're support network uses. I always advocate going for - when you first start, what are your friends using? The reason why is that you can get free help from your friends, hopefully, if they’re friendly. [Laughter] But seriously, ask around, see what people are using and see who’s got the best approach in terms of answering your questions that fits with you and start there. It doesn’t mean you’ll stay there, but start with your support network.
Hannah: The next question is, “Is it safe to build your grid based on wire frames?”
Emma: I don’t think I understand that question yet. Is it safe to build - I think the question is saying, “Do I need to get to a completed design or can I just build my rough Drupal theme starting from the original wire frame standpoint?” If that’s the question, my answer is yes, but you may not want to show it to the stakeholders. You can start thinking early but you wouldn’t necessarily want to get client sign off. Some clients can’t picture things the way you and I can picture them. So it depends on your client. If I've heard that question correctly.
Hannah: Yes. I think that answers it. The next question is, “Is there a good responsive base theme that let’s a site builder do most of the design through UI instead of writing files?”
Emma: If you want a pointy-clicky base theme, I would recommend for Drupal 7, not for Drupal 6 and not for Drupal 8, looking at Omegas 3 or Fusion for base themes. That said, I gave a presentation in Munich on how to evaluate base themes. I can’t remember the name of the presentation or the link off the top of my head, but if you search for my name - I will find the link and post it in this chat window. [Laughter]
Hannah: [Crosstalk] Great.
Emma: Not that these are complicated it was my maiden name instead of my married name.
Hannah: The next question is, “As someone who hasn’t implemented SASS yet, can a PSD be easily converted using SASS or Compass?”
Emma: As long as you go through the steps that I have outlined in this process, which is to go PSD text description and then work on your SASS files, I think it’s relatively easy. If you don’t go through that text description of the design first, then it’s very difficult, I think.
Hannah: The next question is, “To come back to the base theme, what makes you decide to use a base theme or build your own theme from scratch?”
Emma: Well, it depends what you're trying to accomplish. For example, let's say I have a project where I know that I want it to be HTML 5. I can either go through and rewrite all the Drupal core - again focusing on Drupal 7 - I can go through and rewrite all he Drupal cores default template just in case one of them gets used accidentally. I can write all of my own template files for only my specific instance, or I can just grab a base them that’s already done all about work for me.
Base theme are essentially starting points. A base theme is only a good fit for you if it uses the same starting point or the same advantages as what you need for your particular theme. In terms of what should I use one? Should I not use one? How do I make that decision? What are the requirements of the markup and what does the base theme provide you with? Then, it’s an amazing base theme to teach you how to theme. It is incredibly well documented. But if you want a pointy-clicky layout tool, it’s not the right base theme. What you want is Omega 3, not 4 but 3. Again, it depends what your requirements are to be able to decide if the base theme is right for your particular project.
Hannah: The next question is, “We use Bootstrap and LESS in our last project, I just read in a chat that similar to SASS and Foundation. What would you recommend? What are your thoughts on that?”
Emma: That’s like saying what’s better, Joomla or WordPress. I don't know what’s best for your particular project. They’re similar. They both have followings. They’re both popular and if LESS and - sorry, did you say Foundation? If LESS is meeting your needs, stick with LESS. That’s fine. You don’t need to switch to SASS. SASS has, I think, more energy behind it moving forward. I think it has therefore more resources, more help available online. Ultimately, depending on who you ask, too, perhaps some more sophisticated concepts or capacity than what LESS offers. But if LESS can do everything that you need today, it is adding a bit of overhead to go and learn something new just to learn it. It’s cool if you have time, but if LESS is meeting your needs, that’s fine.
Hannah: The next is, “Have you use brackets to ID which converts Photoshop images to HTML tags auto-magically?
Emma: No.
Hannah: Okay.
Emma: I don’t trust auto-magic things when it comes to images. I'm pretty old school. [Laughter]
Hannah: The last question is, “What are the general hurdles to expect when working with responsive theming?”
Emma: The general hurdle would be no matter how many devices you’ve tested it in, your stakeholder is going to have a device that you didn’t know about and they’re going to want it to look perfect in that device as well. I think that’s the biggest hurdle that you're going to have to deal with.
Hannah: Great. Thank you. I think that’s it for questions. If we missed them, I apologize. Again, thank you everyone for attending and a big thank you to Emma for presenting to us today. Really excited that she was able to be on the call. Emma, would you like to end with anything?
Emma: I just want to say a huge thank you to all of the folks who are still in the recording. It’s hard to watch in webinars. It’s a lot of staring at the screen and trying to stay engaged. Thanks so much for everyone who participated in the chat window and hang out with us for an hour. I had a lot of fun. I hope you did as well. Thanks, Hannah, for hosting, too.
Hannah: Of course, we’ll be sure to send the recording and the slides out in e-mail as well, so you should be seeing that tomorrow. Thanks, everyone. Have a great day.
Emma: Bye.

Drupal 8 Preview: What to Expect

Unfortunately, the live event for this webinar has passed.
No need to worry! We always post the recorded webinar and slides within 24 hours of the event. Check back soon!

Curious about what’s coming in Drupal 8? Have some idea but still haven’t gotten your feet wet? Or if you are already playing around with D8? Wondering what to expect from D8? Well, we have Drupal Core committer Angie Byron (you know her as “webchick”) to the rescue! Angie will walk you through what’s coming in D8. She will clearly outline how D8 will help you if you are: an end-user, site-builder, front-end developer, or a hardcore nerd, you won’t want to miss this exclusive preview!

Click to see video transcript

Female: This webinar is The Drupal 8 Preview: What to Expect with Angie Byron. You guys know her as “webchick”. She’s a Drupal Core Committer and the Director of Community Development here at Acquia. We are so excited to have Angie on the call today.

Angie Byron: Right. So, welcome to the Drupal 8 Preview. I’m Angie “webchick” Byron. A little bit about me. So, I’m one of seven people who can actually make changes to Drupal Core itself. I was the Release Manager for Drupal 7. That’s now been passed to [David Rothstein]. Now I’m a Core committer across all three major branches. I also work at Acquia in the office of the CTO so Dree, the Project Lead is my boss. No pressure there. [Laughter] I’m also the Drupal Association, a founding member of the Drupal Association board member. I wrote a book about Drupal once and I’ve been involved in the Drupal Project sans Google Summer of Code in 2005. So, kind of old school. Been involved in the Core development team ever since for every major release since 4.7.

So, an agenda and a little bit of an overview of what we’re doing here. We’re going to cover what’s coming in Drupal 8 for various target audiences so any users and clients, site builders, designers and themers as well as developers and we’re possible I’m going to try and show off some of Drupal 8 with actual live demos. So, I actually got a copy of Drupal 8 installed from yesterday so hopefully there’s no bug and [Laughter] and we’ll kind of see how that goes then we’ll talk about some frequently asked questions like when can I use Drupal 8 and how can I prepare now for Drupal 8 coming in the future.

So, I just want to point out, I’m going to try and go up to these slides kind of fast because I think people want to see what Drupal 8 can actually do but it may run over an hour so if that happens, Hannah is just kind of interrupt and tell everyone thanks for their time but feel free to stick on. I’m happy to answer any questions that you have. Alright. So, whoops we didn’t want to go quite that far. [Laughter]

So, changes for end users and clients. The first major area of improvement that you’ll see in Drupal 8 is around the authoring experience and one of the things that was an Acquia initiative is the spark effort and spark was basically an attempt to go and look at all of Drupal’s major competitors both proprietary as well as open source and sort of like see what was out there in terms of functionality especially out of the box functionality and what we might be able to enhance Drupal with in order to make it more competitive with other solutions. So, what you’ll find in Drupal 8 due to the spark initiative or things like WYSIWYG and Core so this is a pretty major big deal. Drupal 7 doesn’t ship with any kind of a WYSIWYG editor. We did an extensive evaluation process and we actually landed on CKEditor as our WYSIWYG editor of choice and I’ll be able to show you that in a moment here. We also had a feature called “In-Place Editing” which allows you to without having to leave the page or content that you’re on, if you spot a typo or something like that or you’re adding Joomla to awesome you can do it right in place, quickly edit, save and get out of your content without having to go back to the backend form. This works even on things like taxonomy or other kind of complex fields as well. There’s a newly designed context creation page that came out of the Drupal usability, a team’s initiative and what they intended to do there was sort of take the most prevalent things in the form and put them off to the left and then some of the stuff that you set left off and kind of push out to the right. This borrows a lot from like WordPress is doing this to make the content forms that is easier to parse and it isn’t quite in Core yet but it’s in progress, a real preview system which is attempting to address a lot of pain points with the altering experience in Drupal 7. So, let’s actually see how that works in action. I’m going to flip over here. What I’ve got over here – how am I going to do that? Sorry. Too many things. What I’ve got over here is just a stock Drupal 7 site with nothing on it and people I think on this webinar mostly from a Drupal 7 but just in case you’re not, I’ll show you how that works if I’m going to add a piece of content. Let’s say I want to add an article, I can say here’s a title. It’s Vancouver. I live near Vancouver and I think it’s pretty awesome and it has mountains. So, I can say, “Behold the city of Vancouver” and let’s leave the typo in there. It’s great and I’d say, “Come visit us at any time.”

If I wanted to put Vancouver in bold text, I have to start typing HTML by hand which is always a lot of fun. It’s the only thing that’s kept me up to speed on my HTML skills since 1994 though so I’m very thankful for that. If I want to add an image right here there are a couple of steps. First, I have to scroll out of my content area and choose an image from my desktop here and upload that. Once I’ve done that, I then need to copy this link address, come up to the top here and start doing this kind of thing, putting in some alt attributes and anyways it’s sort of a pain in the butt. This is all stuff that contrib. modules and Drupal 7 can smooth out really well but the out-of-the-box experience of Drupal 7 is just not very good for content authors. Then you have are left with all these different advanced settings that looked like they’re important because they’re in the main section so you just end up kind of going around and around on them. So, if I save that, what I’ll notice is that while my image is showing up, it’s not actually showing up where I put it and the reason for that is because we have to set an input format so I’m going to go back here and set this to full HTML. I’m going to hit save again and now I have a huge image that’s super big and if I want this one not to show up, it’s a whole process. So, I don’t know, have people encountered this sort of thing before? Is this sort of your experience with sort of content authoring in Drupal? If I look back here, I can’t see it. But anyway, I think most people have probably encountered these issues and tend to work around them. Yes, definitely. Exactly.

So, let me talk about what we’ve done in Drupal 8 to make this a whole lot easier. So, if we get to Drupal 8 it looks pretty much identical to Drupal 7. The toolbar is a bit different and we’ll talk about that in a while but I’m just going to go ahead and show you the create content experience. So, I’m going to create an article entitled do exactly the same thing as I did before, awesome. Let’s, yes, go ahead and leave that typo in there. That’s cool. I think I said mountains or ocean or something. Here I have a WYSIWYG editor so I can say, “Hey, it’s Vancouver or BC. Wooo!” I could bold that. I could add a link to it if I want. All this stuff is available right here out of the box. If I could view source you can see that the source that it’s generating is pretty clean. There are Symantec markups, strong tags and such so that you’re dealing with a whole bunch of like nested spans and dibs and all that kind of stuff that sometimes a WYSIWYG editor can be fraught with. So, I’m going to go ahead and add my image here again and this process is going to be a little simpler so I can enter my alt text right here and say, this is Vancouver BC. I can also check out if I would like an image caption and if I save that, you can see that it added it right into my text and I can click in here and say Vancouver skyline or whatever, that kind of stuff. Then all I have to do is click save and publish and I’m done and there’s my nice image and it’s got the nice caption on it. Everything is all ready to go and I didn’t have to spend any time configuring WYSIWYG editor or setting input formats or any of that kind of nonsense stuff that you have to do in Drupal 7.

When you want to edit a piece of content, that’s a whole another business. You have to kind of click. I’m back in Drupal 7 again. You have to click on this edit tab and this will take you to this format that looks nothing like what you just saw, right, like this is what your content looks like and this is what the form looks like. So, how do I know if this image is wide enough or too wide and I could try putting a width equals like 500 or something but I’m not sure if that’s quite right. So, if I click preview, what happens is we’ll see I get my image there twice, one is up here and one is down below in my admin theme so I don’t actually see what this is going to look like when I click the save button. I just kind of have to close my eyes and hope that when I close the save button it’s going to look okay once it gets on the front end. In Drupal 8 we’ve added a feature called “Quick Edit” and how this works is if I’m on here and I notice like whoops I misspelled my tag and I want to add an extra O to Wooo, I click my contextual links. I say quick edit and then I can just click directly into this field and start editing right in place. I can click up to my tags and I can say, “Oh! That’s supposed to be awesome”, and let’s also mention oceans because those are cool and I just click save and instantly the edits are done. So, if I go back to my front page you can see mountains and oceans are both showing up. I have my extra O in Woo and so that took about two seconds and I never once had to go back to that backend form unless I’m trying to edit something that’s not a visual property of the content. So, that was something that we spent a lot of time on and I think it’s going to be a really great improvement in Drupal 8 for content authors.

Another major improvement area around the sort of Drupal for customers and end users and things like that is around mobile improvements. You’ll find that everything in Drupal 8 is done mobile first. You can install Drupal on a mobile device. You can enable modules on a mobile device. We actually like went through all of the admin page’s poll sales and are going through the process of making sure that every single one of them works on a narrow screen size. One of the things that allowed us to do this is the whole responsive themes images and breakpoint things so if I have a website that looks like this on a desktop and I pop open a web browser, you can see that it condenses down into something that fits really nicely on the screen. So, the Home and About Us links end up being sort of wide so they have a bigger hit area. The big Drupal rocks picture condenses down into a smaller one that fits nicely on the page. We also added mobile friendly administration so you’ll see this new toolbar module in Drupal 8 that’s got icons in it. Wow! What a concept. So, that looks like on a desktop that’s stretched across the top and you can go in and click do it but on a mobile device what will happen is it will actually shrink down to use only the icons and not the rest of the stuff. Actually I see icons with little dropdowns and stuff like that. The other things that we’ve done is added some additional APIs for people who are building these types of screens to be able to use them with their content author. So, one of these is their responsive tables so you can see that - whoops sorry. This screen by default has status, rules, member forms actually a bunch of different things but when you’re on a mobile device you can actually fit all of that stuff into the same page without a whole lot of scrolling. So, what we do is we have a responsive table API which allows you to declare columns that are important or less important and then they’ll drop off as the screen size gets narrower and narrower. So, that what you’re left with is the most important information.

We also have a feature that’s currently in progress and not part of Core yet called “Responsive Preview Bar”. So, if you are not someone who keeps $20,000.00 worth of hardware sitting around in your office, you can actually quickly flip back and forth between different devices or presets or whatever you want and you can preview an approximation of what that’s going to look like which his really great for content authors in trying to educate them on the reality that we live in which is that things all over the place are if you can’t depend on the thing that you’re authoring, being this thing that someone’s going to view your site on at all. That’s especially true now and it’s definitely going to be true in 2014 and beyond when Drupal 8 is actually out. So, if I look at the response of the Preview Bar I could say, “Let me preview out in an iPhone 5”, and then there’s this little button where I can flip the orientation of it and see quickly what it’s going to look like in landscape versus portrait mode and you can quickly flip through devices and get an idea of what are your content is cutting off at a certain point or these kinds of things.

Accessibility is another big improvement. I’m going to try this. I’m not sure if it’s going to work but I have a little video so if you can’t hear it, I’ve got the YouTube link here but you can look at just a short little thing from Dries’ keynote. [Pause]

Female: Angie, we have seem to lost your audio.

Angie Byron: Okay. I thought that might happen.

Female: Okay.

Angie Byron: Cool. So, anyway, that’s a cool video you should watch at some point because what it shows is that all of the features that I just demonstrated, the content authoring experience, in-place editing and all that sort of stuff, that all works with people who can’t see the screen as well. So, screen readers can benefit from that. People who can’t use the mouse because of physical disability and can only use a keyboard navigation can use all these features so Drupal 8 will be fully accessible out of the box as well even more so than Drupal 7 was which was already pretty impressive.

Then the last mobile feature I wanted to cover is the fact that we have a replacement for the overlay module. The overlay module is a module because all the Core developers really, really don’t like that module at all. I’m not sure how the uptake is with - and the rest of the community but one of the things that we’ve been able to do in Drupal 8 again from this mobile first mentality is actually replace the overlay with a mobile friendly version which effectively is when you are in the admin context, you get it back to site button that remembers where you were on your front page or, I’m sorry, on the front end of your site. When you click it, it just returns you right to that place. So, if you bought about a node real quick to go and ban a user or something like that, you can quickly go back to the discussion you are reading without having to remember where you were so it’s actually a really nice usability feature that we managed to get in and we also managed to remove a module that a lot of people don’t like very much [Laughter] at the same time so yay.

So, let’s go ahead and see these things in action so I’m going to flip back over to my Drupal 7 and 8 sites. So, back on my Drupal 7 site, Drupal 7 came out in 2011 before a lot of certain modern best practices around mobile and responsive were available so what you’ll see is when you shrink Drupal 7 down stuff like the toolbar starts to do things like this which is not very nice and then you also have like this endlessly scrolling thing happening here because it doesn’t know how to format the content in a way it would be pleasing. It actually gets even worse. If you preview it on an actual mobile device, if I go here and I - 7x. First of all, my screen looks super tiny. I can’t actually see what’s happening there. I have to like double click to try and zoom in to different places and then if I log in as an administrator, I find that the toolbar is completely unusable without me having to like zoom in and then once I do start zooming in what happens is it just does this and now pretty much half of my available view side is taking up by this toolbar and it’s really basically unusable on a mobile device out of the box. Again, in Drupal 7 there’s lot of contributable modules including a back port of the Drupal 8 toolbar that can help address this but it is an area of contention when you’re comparing out of the box experiences between Drupal 7 and other sort of frameworks. So, if we look at what Drupal 8 does, here’s my full desktop with and you can see it as I shrink this down, all of the sudden the toolbar will change navigation from horizontal to vertical when it detects it can no longer fit. You also see their responsive images taking effect so the screen is going smaller and it’s shrinking the image down accordingly. Then if I go super small down what’ll happen is it’ll actually move the text from these toolbar things entirely and what you’ll get instead is just the icon representation so you can see that if I go here. Come on. You can do it. [Pause] There we go. That looks much nicer, right? I get to see my content just as I would on the desktop. I’ll go back here as you can see and if I want to do something administratively I can just click the menu toolbar here and everything I need is right available for me. I can even do things like invoke quick edit mode if I want, maybe not from exactly here but basically all of the things that we did in Drupal 8, how they work there. They work the same on mobile so that’s a really, really huge improvement. Then one other thing I wanted to show is this “Responsive Preview Toolbar”. So, if I’m looking at a piece of content, it’s my Vancouver page, what I can do is I can say, “Hey, show me what that looks like on an iPhone.” Okay that’s cool. I can flip back and forth between the different navigation site and say, “What about a Nexus 4?” and it will go ahead and pop back and forth between those. These are all fully configurable so you can click on configured device as you can set up whichever smart default make sense in your situation. So, if everyone in your company has issued a MacBook Air as part of joining in the company, you can set that up as a preset and then sort of figure out how that would be viewed by everyone in here who matters.

So, getting out a content authoring experience and getting it a site building improvement, there’s a ton of stuff here as well. There’s a lot of work done on what’s called the entity and field API system in Drupal 8 so you’ll find that out of the box we have improved data modeling tools for example entity reference fields so you can add say you are a music site and you want to create album then you want to associate them with artist and associate the albums with tracks and so on. You can set up entity reference values in order to create those relationships between your different pieces of content. We also have a native date and time field that you can add as well as link, phone, email and we actually make comments of field as well so you can configure easily that you want comments available on forum posts and they should be this way versus you don’t want comments available on press releases and that sort of stuff. We also add a new entity types so these are sort of the top level building blocks of Drupal to which you can attach fields so now you can attach fields and think like contact forms so sort of like web form module and Core light as well as you can add fields to block so for example if you have a type of block that’s called an add code block, you can attach a field where you can paste something from Google, Google AdWords or something like that or double click. We also added form displays as a correlated or display settings so in Drupal 7 you have a lot of control over where how the content and display once you get to a page like whether the image was up on a thumbnail view or a large view or these kinds of things but one thing you can’t really do very much is actually customized what the entry form looks like without something like displaced meter, things like that so we actually added form displays the Drupal 8 native concept so now that’s available as well. So, if you want to say make your comment form ten rows instead of five rows on this particular thing you can totally do that as well.

Views in Core was a huge improvement so a views module is I think now is like the number three most used module or something like that but it effectively lets you to click together things like blocks, admin screens, listings of users and even in Drupal 8 you can do REST export so we’ll get into web services later on but basically it lets you take any of list of content your site and export it as JSON which can then be sort of consumed by some sort of an API like a web services API. So, this is a major win for Drupal 8 and that you can finally with Drupal 8 build a really useful sites right out of the box.

For those who don’t know what Views is, Views basically allows you to build fully customizable admin listing, sidebar content, image galleries, slide shows, REST output, whatever you can imagine as long as it’s the list of things, a calendar for example you can do all that with the zero lines of code just by clicking it together. It’s one of Drupal’s really killer features. We’re also in the process of restyling the administration interface kind of giving that a new refresh look which is going to help with it looked a lot cleaner and be a lot more accessible to folks. Multilingual improvements is a huge area where we spend a lot of time trying to figure out. So, one thing you’ll notice right out of the box is your community, basically in Drupal 7 the first thing you do in the installed process is you pick which installation profile you want which is a really weird concept especially if you don’t speak English natively. [Laughter] So, in Drupal 8, the very first screen in the installer is a multilingual language selection so you can actually do the whole install from start to finish in your own native language because once you select Hungarian or something like that, what’ll happen is it will download the translation from Drupal.org automatically and incorporate it into your website. Then further any additional updates to those translations can all be updated through UI as well so translations are much easier to work with than they were in Drupal 7. We also added language to pretty much everything. So, you’ll see language attached to both all the content entities so things like files, users, comments, notes those kind of thing as well as blocks, views, menu items, anything that’s configuration as well is translatable. So, the whole gamut of the things that are available in Drupal are translatable including things like the title fields and stuff like that which is really important because in Drupal 7 in order to get equivalent functionality you needed roughly 30 modules in order to achieve this and in Drupal 8 it’s going to be all available in I think three or four modules depending on what exactly multilingual figures that you want. So, we have translation on almost everything. Here’s an example of blocks so there’s a language switcher block and you can translate blocks into Swahili, Norwegian, and Catalan, whatever language that make sense for your site.

There are a number of changes as well for designers and themers we can talk about. The first is HTML5. HTML5 is not even a new standard anymore but it’s definitely what you should be doing nowadays and we now do an HTML5 in addition to having a better Symantec property. It also have some nice stuff like HTML5 form elements and what this allows you to do is say I want a date field or a full number of fields or whatever and then as advice that knows how to process HTML5 form fields will actually show you a different keyboard depending on the type of field that you’ve chosen so you can see that for date field you get a little date slider. For a phone app field you get just a number pad and not the full letter field and then for an email you get a little app key at the bottom of the keyboard. We’ve also had a number of new front end libraries. So BackboneJS and Modernizr normalize that CSS and Twig. I’ll talk about Twig here in a second but essentially what these are allowing us to do is focus a lot more on making front end applications that actually interact with Drupal as well as being able to selectively turn on and off different features and capabilities based on whether or not the device is a touch device or what sort of inputs it has.

Twig is replacing PHPTemplate in Drupal 7 and what it is it’s a different syntax for sort of declaring dynamic information in HTML and so I’ve sort of given you an overview here so there’s HTML5 pegs on the market now so you can see like article and footer. You see little braces and then a property that’s basically printing out of variable of some kind and one really big improvement from Drupal 7 is you no longer need to know as a themer whether something is an object or if it’s an array or whatever it is, it’s always something got, something got something and that will handle it all magically for you. You can also do logic. You can also do comments but the key thing here is you can’t put HTML or I’m sorry. You can’t put PHP in these templates which are a huge boost for security. It should also be a huge booster performance and things like that as well.

We also provide native schema.org output which is a big fancy term for better SCO so the output that comes out of Drupal 8 has its machine coded so that organizations like search engines like Google or other sort of machine things can parse out the things and figure out, “Oh! That’s the title and that’s an image, that’s a byline and that’s actually a person” and so on. So, that when your site shows up in search results you actually get more Symantec data added to it.

We also managed to kill most of IE. We killed support for IE 6 and 7 in Core and most of IE 8 as well. So, IE 8 will still work. It won’t fire off any errors but it definitely gets a much degraded experience basically along the lines of what a mobile device would get. That’s important for maintainability as well as a number of other things and this is a move a lot of other services have done, Facebook, YouTube and so on of all then is and we’re just pretty much following the suit there.

Now in terms of changes for developers, this is my favorite part but we are about to get geeky so I’ll just warn you. The first and probably the biggest one is the new configuration management system in Drupal 8. So, this is trying to solve the problem of moving from dev to stage to production or other sorts of things and typically what happens in Drupal 7 is this happens so if you are trying to move something like say you’ve configured a content type or you’ve changed permissions and you try and move that to your live site, you have a problem because one of the great things about Drupal is that you can configure all of the stuff in the UI and when you click around the button, things happen but the problem is that the configuration and the content are both stored in the database so if you try and move the database tables from dev to production you’ll end up overwriting real content and so people resort to all sorts of workarounds for these. There’s features module. There’s update hooks. There’s writing it down on a napkin and going through all of the stuff individually which is my preferred approach. I’m just kidding. But anyway, in Drupal 8 we fixed all that with the new configuration management API.

So, I’ll walk through how this will work conceptually and then we’ll actually see it in action and then that will be really exciting. So, let’s say here’s your dev server and your production server and then your files directory there’s a config a big automatically generated key because you don’t want someone to get in here and then there’s two directories in there, an active directory and a staging directory and the active directory is where your site pulls its current configuration from and staging as it where put stuff that has yet to be deployed. So, as I’m on dev and I’m clicking around and clicking various stage configuration buttons, what’s happening is that’s writing things out to the active store which instead of being a database table or five is instead a series of YAML files so files on the file system that you can then track and as a version control and such just as you would any other file like a module and such. Then when I’m done making my changes, I go to a configuration UI and click export and then that will give me a hardball which I can then move over to the production website. Now on production I’ll go on to my configuration management panel and what I’ll get is I have changes in staging directory is I’ll see something like this. So, it will say, “You have ten new things to import and some change things and stuff like that.” I can click view differences and actually get an idea like, “Okay. This added a file and here’s the kind of stuff that was in it.” Then if I choose to import it what happens is it moves it from my staging directory, my active directory and then that becomes the work that my production web server. That the configures like my production web server looks at. So, kind of conceptual let’s go ahead and see that in action so this will be fun. So, I’m on my development server and you can tell the difference between development and production because production has content on it and my dev server does not.

So, let’s start with something really simple. So, let’s go to configuration, site information and let’s just add a slogan like, “Hello world. I’m not feeling very fancy today.” As I go to my home, I can see that now Drupal 8 dev has a “hello word” slogan but if I have to move back to my production server I see that it is not. It’s still just Drupal 8. There’s no slogan. So, if I go to configuration and I go to configuration management and I do an export then it will give me this thing called “Config 3” which I can go back into production and do the same thing, go to configuration management but this time go to import instead of export, download those Config 3. I click upload on this. It says, “One file were successfully uploaded, ready for import”, and now just as I showed you, we see that one file has changed. It’s a system site file. If I click view differences, I can see the slogan changed from nothing to “Hello World”. I can say, “Well that looks pretty good. So let’s go ahead and import that.” It’s clearing a bunch of caches so this part takes a little while. [Pause] There we go and if I go to my home link I can see now my production site has “Hello World” slogan as well which is really handy. One thing I wanted to show is what is happening on the file system so I have my site checked in to get. If I do a get disk you can see that these file changes will also show up on in your version control system so you can manage in that way as well. So, okay, so that was fine but that’s really woozy example.

Let’s try a fancier example, shall we? So, we’re talking about Vancouver. Let’s say that our site is going to be a tourist website so let’s make a new content type and call it, “Tourist attraction” or something like that. I’m going to save in managed fields and let’s say one of the fields I want is a type field which is a list of text and the type might be something like entertainment. It might be museum. It might be – my taxonomy is dialing to me this morning but it might be – in the museum. How about one more which is like show, something like that? Alright. So, now we have a tourist attraction type and if I go to add content, I’ll see tourist attractions is one of the things I can add and I probably also want to create a list of tourist attractions so I’m going to go to structure and then I’m going to go to views and I’ll add a new view which is tourist attractions and I want to only show content. That’s a type tourist attraction and let’s create a page and let’s give it a menu link in the main navigation. This is the views module that I’m demoing here. Again, I didn’t have to turn anything on. This is all just available right out of the box so I’ll save this and then if I go back to my site again, you can see I have home and I also have tourist attractions so there’s nothing in here but if I created the tourist attraction and then it’ll show up.

So, now we’ve demonstrated creating a piece of content, adding a field or sorry, creating a content type, adding a field to the content type and adding a view that shows what that content type is like. So, let’s see how it deals with this problem. So, once again I’m going to go back to configure management and I go to full, import, export, and export. There’s a lot of exporting. Flip back to production. Again, I can tell production doesn’t have this change because I’ve only got article and basic page. I don’t have anything about tourist attractions here so I’m going to go to configuration, configuration management and then an import, config 4 and while we wait for that to upload I’ll just go back here again so we can see, you know, what’s happening in get world and stuff like that. So, now it’s telling me you have new configuration file successfully uploaded, ready for import. So, these are new files that weren’t there before and you can see it’s got the note that I made. It’s got a field. It’s got a menu item that I made as well as a view so let’s go ahead and import all of those. I’m sorry. It wasn’t showing up because these are new files I actually have to click to get status instead of get dev but you can see that these are all showing up in my file system as well to be managed there. So, this is where I normally ask the audience if they know any good jokes but I can’t actually hear you guys so this isn’t going to work very well. Alright. So, let’s see if that works. So, we see our tourist attractions and that’s showing up cool. If I go to add content I see there’s a tourist attraction so let me add one which is called “Science World” or something and it is – I type museum and now if I go to tourist attractions I see Science World showing up there. Pretty cool eh? This is something that was not that easy to do in Drupal 7. There’s a bunch of work around. Features and models to actually really good like Drupal 7 wise. The problem with features model though is it doesn’t work for everything because it’s not in Core so it’s only module that it be explicitly opted in which at this point is pretty much everything but there was definitely very hanky times when it wasn’t quite like that so with this functionality being built right into Core, it means that support across the board in Drupal be available. If you don’t like clicking buttons, there’s also Drush Integration for automating this stuff. So, if you prefer to work on command line tools and you want to wire, you don’t have to check in job and those other kinds of other developer things, you can also do that.

So, let’s talk about web services. That was the other major initiative in Drupal 8 for developers so web services is trying to solve the problem where right now Drupal believes in Drupal 7, Drupal default assumption is that it’s generating its fully themed HTML page as it’s intending to go to a desktop browser and that is totally not an acceptable assumption at this point in time because you have no idea what that thing is on the other side and well it could be a browser on a desktop. It could also be a browser on a mobile application or it can even be another Drupal site or it could be a flash kiosk application in the mall or a number of other things. So, what we’ve done in Drupal 8 is leverage the Symfony framework in order to make Drupal more like a native REST server that has the CMF built on top. So, how Drupal now behaves is essentially gets an incoming request in and a return of response and while that response may be a fully HTML page, it could also be a glob of JSON or it could be something like XML. It could be a lot of different things and essentially each module has the ability to dictate what sort of thing it wants to come out of it. Symfony for those who aren’t familiar with it is a collection of loosely coupled components. It’s got sort of a library in order to make web developing applications easier so we don’t use it as an entirety of the Symfony framework. We use a number of different components and essentially most of what Symfony entails isn’t really going to affect you as a module developer other than the new routing system in order to do this sort of input and output from the page but in terms of HTTP foundation, HTTP colonel and a lot of these other sorts of things, much of that is sort of buried into what used to be like the includes directory and stuff like that. If you want to get data out of Drupal there’s the REST for web services module and this lets you send a Core request or whatever have you and it will get back at JSON representation of your page. So, that’s a wonderful thing. If you’re building say an Android or an iPhone application and you want to display a list of nodes in that application you can enable the REST for web services module and you can enable the REST export on your view and then everything that the people visiting your site, that will actually be visible on the mobile application as well. Or if you want to parse some other third party service and get that into Drupal, we also ship Drupal with a third party PHP parser and it worked something like this where effectively you pull out an HTTP client and then you send a get request to that client and then you return the JSON response and you then do whatever you need to do with it, save it into the database or email it to somebody or whatever sort of think you have there. I want to point out too, it’s not just gets. We also support post. We support update, delete, insert, all of the major HTTP operations with the REST for web services library.

Those kind of leads into a larger topic which is within Drupal 8 there’s sort of been this movement towards getting off the island and what we mean by that is rather than sort of having this culture of not invented here and we can do it better and these kind of things, we actually spend a lot of time in Drupal 8 during the development cycle looking at what other PHP projects were doing and what the best practices were outside of the web, what’s the best tool that we can find to do HTTP request and let’s just use it instead of trying to build our own thing. So, when you look under the hood of Drupal 8 you’ll see much more modern object oriented code so using concepts like classes and inheritance and interfaces and such and that code is embracing the latest PHP standards so standard ways of structure and directory names of choosing new PHP features such as name, space and traits. We’ve found a number of different places where we actually swapped out our own custom code for sort of better tools that are maintained to do only one job and do it well and then we sort of integrate with those tools as well. So, when you use Drupal you actually get the benefit of being able to use these tools for things that Drupal may not be the best fit for. So, Drupal’s great for contact community and commerce. It’s not so great for a very highly customized bespoke application but on the other hand if you learned Symfony and you know Drupal, you can actually cover a wide spectrum of all of the different things that you can do with a PHP project which is really, really exciting.

If you want to catch all of the EFI changes and there are many, we have about list changes URL at Drupal.org and that’s sort of a database that we’re tracking everything that’s been changing between 7 and 8 and it’s a lot. So, I’d like to give a shoutout to more than 1,700 people. I think it’s 1,766, I checked last night, who contributed the Drupal 8 so far. There is an enormous development team behind Drupal 8 and they’re all super excited about this new direction and trying to get it done.

So, when can you use this awesome stuff? When it’s ready. Wah wah. I know. It’s not a fun question. I want to talk a little bit about the Drupal 8 timeline just to give an idea of where we’re at and where we have left to go. So, development for Drupal 8 opened on March of 2011 and we spent from 2011 to 2012 basically pumping features in both users facing features as well as developer facing features and then have about three months window between December and February where we could actually get those things to completion. Then in the summer we did an API freeze and that the intent behind that was to get all the different stakes in the ground regarding the new way we’re going to handle HTTP request, a new way that we’re going to write entities in fields and such and now we’re currently in a phase called API completion where we’re sort of putting out monthly alpha releases in order to get developer experience feedback in order to fix performance issues and those sort of things.

What you’ll see happen probably in Q1 of next year is we’ll start putting betas out and this is when major APIs are locked down and at that point what we’re trying to do is get feedback more from end users than developers and how are the features working and sort of roughing up the right rough edges as well as getting ourselves done at zero critical bugs and then we’ll start releasing release candidates and then finally release Drupal 8.0. So, when it’s ready is when we have zero remaining critical bugs and critical test and you can actually check this list if you log into Drupal.org it’s going to be on your dashboard and we track this over time and see how it’s trending. Lately, it’s been sort of flat lined but we are starting to see some movements towards getting it to a downward direction. A lot of this as we had kept a lot of backward compatibility layers in Drupal 8 for a while, while we are moving things around and not as a matter of like getting everything converted to the new APIs and then getting polishing up some stuff.

So, we’re still hoping for an 8.0 in say mid-2014 kind of timeframe but there are also still lots to do. So, if you’re still inclined we can definitely use your help. We need help finishing API conversions. We need help fixing up performance, developer experience meaning like as module developers actually downloading Drupal and giving feedback on what it’s like for you and see if there’s better ways that we can handle it. The migration pads also need help, documentation examples, tools, whatever testing you can do. Drupal 8 right now has been looked at largely by the same people who built it. It’s great to get people who didn’t build it in there to start giving us not only some additional outside feedback but also sort of bolstering the Core development team because they’ve been working really hard now for almost three years and we could use an extra injection of help to get it right across the finish line.

So, as end user, when should you use Drupal 8? What I usually recommend is people keep their eyes on the project usage graph for Drupal and sort of let the community dictate that for you. So, this is actually the graph of Drupal 7 versus or – sorry. Drupal 6 versus Drupal 7 but – actually Drupal 7 versus Drupal 8. I would basically say that if you’re a module developer, you should really be starting to use Drupal 8 right now because right now the APIs are still malleable enough that if you find something horrible, it isn’t working or you see that we’ve missed an area to code entirely that means you can’t port your modules to Drupal 8, there’s still plenty of time to fix those things and get those in. If you’re an early adopter or you have a launch in say mid-2014 or thereabouts then when you may want to start using Drupal 8 as around when we start releasing datas and release candidates so an early to mid-2014. If you’re a late adopter and you’re on a conservative approach then what you might want to do is wait until those lines cross so in other words when Drupal 7 is on the decline and Drupal 8 is on the upswing and now Drupal 8 – the number of Drupal 8 sites have eclipsed the number of Drupal 7 sites, that’s actually a really good indication that that’s kind of a sweet spot for moving to Drupal 8 because by that time there’s a lot of contributed modules reported. People are actually able to use Drupal 8 in a real production way. If you’re ultra conservative, you may want to wait even later than that but be careful with that because if you wait until the platform is too proven you might have a situation where the community is not even caring about Drupal 8 anymore now they’re looking at Drupal 9. It’s sort of equivalent to like if you were trying to build a new site in Drupal 6 right now, you sort of hit this point of a community where even though Drupal 6 is still supported, it’s not actually actively looked at by most people because most people have their eyes on Drupal 7 and then the new shinier things.

Something we’re playing around with speaking of Drupal 6 is this idea of a new released proposal so this is in progress and there’s a link there where you can go and participate in this discussion that effectively what we’re trying to do is introduce a couple of different things. One is the concept of a long-term support release so things like – which we effectively have right now but mostly just due to how long it takes the current version of Core out but effectively what would happen is we would declare a long-term support release as well as allow minor feature releases of Drupal Core rather than leaving the Drupal Core as it is as it shifts on whatever data it shifts on leaving it that way for three to six years instead doing incremental improvements on a six-month schedule. So, what you would see here is when 8.x dev turns into 8.0 we’ve got 8.0.x and we would fix bugs and such on that and then we also have these non-BC break in, or sorry, non-backward compatibility break-in features that we might add to an 8.1.x branch and 8.2.x branch and so on. We wouldn’t actually make a Drupal 9 development branch until there was something to do there. So, I know until initiatives have sort of been moving along and there’s like a good heavy head of steam behind whatever that we’re working on, at that point we would branch for 9.0 and that’s also when we would branch an 8.3.x or whatever version it is would be the long-term support release and then that would be supported all the way until Drupal 10 has a long-term support release. So, that could potentially be five years or seven years or longer and then what we’ll do is we’ll hit security fixes only period once 10.x is branched.

So, what this attempts to do – well I mean it sounds way more complicated than this. But what it’s attempting to do is allow us to iterate faster in Core and allow people to get features faster so like WordPress is an example of a project that founds us really well where they have very fine grained six months release cycles and they just do little incremental improvements like,
“Oh! Look at this new media browser” and “Oh! Look at this.” So, the idea would be to free up Core to be able to do some of that kind of thing as well as have a version that does operate a lot like today which is that rock solid. It’s stable. It’s not changing any time soon but have that point later on a development cycle when we sort of flushed out the initial bugs and so this seems like it strikes a really good balance between those who want the bleeding edge features and want to sort of stay on that cutting edge and those who are more conservative and just want to build their site once and then we’ll leave it sit there for years. I think both of those audiences will be well served by this. The main thing that’s holding this up is building enough of a community around Drupal 6 to actually make sure that security fixes can be supported after Drupal 8 comes up.

So, what about the upgrade path? You may be asking. So, the upgrade path in Drupal 8 just as it in any major Drupal version is going to be pretty rocky because we changed the APIs in order to follow the latest and greatest in what’s happening out there. We have a saying that’s called the “Drop is always moving” and so the advantage of Drupal 8 is it’s going to have all of this stuff built in out of the box to assume native REST server and assume mobile first as multilingual first and all of these other things but it does mean that custom code that you had in particular needs to be rewritten from one version to another. So, what’s happening with the upgrade path is there’s work actively ongoing to add a content migration path from both Drupal 6 and Drupal 7. So, in other words your nodes, your users, your taxonomy, everything else that you’re keeping in your Drupal 6 site win Drupal 8 shift or shortly thereafter there will be an ability to just click a button and suck all that stuff out of your Drupal 6 site into your brand new Drupal 8 site and that’s something we have not done before it support two releases back. Normally what you have to do is do a huge migration path from 6 to 7 and then again from 7 to 8 so this is going to be a huge improvement for folks.

Contrib. module upgrades are ongoing. There’s not too much in that way yet. One nice thing is that Drupal 8 shifts with most of the well-used contributed modules that hopefully you can actually start building real sites of Drupal 8 on the day 8.0 shifts because it uses their NAB references and all these other types of things but there’s a project called “Upgrade Status” which allows you to sort of track what’s happening in Drupal 8 that way. For your custom module upgrades, there’s work ongoing in the coder project to make a coder upgrade module for Drupal 8 and what this did in Drupal 7 is it essentially scans through your existing code and would attempt to convert it to Drupal 7 as far as I could take it and that basically leads to be used for everything else and it basically turn what would be like say a weeklong reporting project into like an afternoon-long reporting project. So, if you’re interested in helping out with that, that’s a huge area that still needs some helping hands. In general though, what I recommend is to avoid your upgrade pain. You should stick to well-vetted contributed modules over custom code where you can. In other words if there’s a way to build what you’re trying to build with views and constant types and entities and such, do that because Core will handle that rather than sort of going off and writing your own custom version of panels modules because you can. [Laughter] So, that would be my advice there. There’s a bunch of other tips on the Acquia blog here under this getting your site ready for Drupal 8. One of the other big things you can do that that article mentions is you can – there’s back ports of a lot of spark stuff for example as well as back ports a lot of the mobile features like fixed responsive images and responsive themes and stuff like that. You can start using that in your Drupal 7 site today to sort of get your content authors familiar with the new paradigms. Then Sahana also provided this D8 readiness resources which is a bunch of Acquia resources to how to get further up to steam on Drupal 8. Sahana, are you on? Do you want to cover this?

Sahana: Yes. I’ll just take a minute. So, for all of you really interested in Drupal 8, now is the time to start getting yourself trained and familiarized with Drupal 8. So, I’d just like to give you a bunch of resources so do check out some of the blogs that we have on Acquia.com. They’re just plain how-to educational blogs where Drupal 8 and what happened in this week in Core and OOP and we have a couple of webinars including the one we did today which was awesome and a bunch of live panel discussions. Also there’s a place for developers alone called the “Dev Page” on Acquia.com where we have weekly updates on what’s happening in different parts of different technologies and Drupal 8 included. So, keep yourself posted and be up to date using any of these resources. They’re very helpful. Go ahead.

Angie Byron: Awesome. Thanks, Sahana. Okay. That’s all I’ve got. So, I’m happy to answer any questions that folks have and I’ll slip over to WebEx.

Female: Awesome.

Angie Byron: Sorry. I know that was kind of fast but I figured it was being recorded so people could go back and…

Female: Definitely. A lot of questions come in so we can start getting to them and we’ll just try to get to as many as we can. So, the first question is, does the WYSIWYG editor include more editing options such as video, links, images, et cetera?

Angie Byron: Yes. That’s a good question. So, out of the box it definitely have links and image support. Video support is not in Core but the plan is for the media module Drupal 8 would be able to provide that. But the ways CKEditor especially the 4.3 version that we’re using, the latest version, is set up in order to allow for modules to very easily integrate with the editor in order to extend the buttons that are available. So, like CKEditor actually like really works hard with us. They actually redesigned a big chunk of their WYSIWYG editor to make it work with programs like Drupal so there’s this new concept of what’s called the CKEditor’s Widget system and the widget system is – when I showed the image caption stuff that’s leveraging the widget system. So, it’s the ability for you to actually like get in there and customize what’s provided from CKEditor out of the box and actually extend it with additional information. So, that allows us to put image captions on, also to in place edit those image captions and know the plans as far as I know the media module from Drupal 8 are to make sure that that’s the ball works really seamlessly.

Female: Awesome. The next question is will the import export system be complete replacement for the features module?

Angie Byron: Probably not a complete replacement so a couple of things that in Core are the ability to selectively import only part of a deployment. Right now it just does a full import or a full export and it may be that we don’t get to doing partial imports or exports until when Core shifts or even until 8.2.x or one of those other versions. So, that may be an area that features module may work. Also, feature modules has a really nice UI for sort of collecting things into a module and that is not something the configuration system does so that’s also an area that I think features module can continue to be really helpful is saying I want to feature called blogs and I want to have this content type and this view and such but what it does mean is that you won’t have to use features module for all the deployment stuff anymore so features can just stay based around that concept of creating really easy one check off a module that actually combines a bunch of different things together.

Female: Awesome. The next question is, is there a sanity check during the import process to make sure that the config file being imported corresponds to the right site i.e. I don’t want to import the wrong file accidentally into a multisite environment?

Angie Byron: That’s a good question. So, there are two things. One is no. It doesn’t yet but there is a critical task to figure that out before release particular adding a validation stuff because the problem with the YAML files is like if you want to, you should not do this but people probably will then you could hand edit those YAML files and then if you start doing that, you’re importing stuff and you don’t actually know what it’s doing. So, there is a critical task to get a validation step in there which would allow for that. As far as how CMI works with multisite though, I don’t know that there’s much we can do in order to prevent you from importing into the wrong site. That’s kind of up to you to view the disk and be like, “Wow! Wait a minute, that’s not what I meant to do” because there’s nothing intrinsic about these YAML files that explains which site they’re part of by design so you could move a view really easily from one site to another or a block or any of these relation expense. So, yes on the validation. That I get figured out before release but know on anything specifically about tracking which site things came from. Although, I’m sure that people will use the config 8 APIs in order to develop sort of additional deployment tool like that once Drupal 8 gets a little bit more release ready.

Female: Alright. The next question is what are the immediate complexities of upgrading from 7 especially with custom modules?

Angie Byron: So, the immediate – so upgrading from a major Drupal version for those who have not seen the process before, it’s a couple of different process. So, there’s two parts there. One is your data of your website so that’s like your content and configuration and such and the other is the code that makes your site work. So, oftentimes what people will do, what they do nowadays in Drupal 7 is they actually build a second site so in your case, you’re build these Drupal 8 site and Drupal 6 site and then you set up your Drupal 8 site using the modern best practice. Let’s say like you’re moving from a site in Drupal 6 and that we are using some module for images that we don’t actually use anymore or it’s been abandoned for seven years or whatever, that sort of thing. A lot of people will actually configure the places for things to go in Drupal 8 almost as though it was a new site in a way and then what we’ll happen is you’ll use the migrate pass that is going to ship with Drupal 8 in order to take all the content from one site to another. If you’re not using custom code, oftentimes your process can just be like install Drupal 8, grab copies of all of your contributing modules that you need, run, update that PHP and you’re done. When you have custom code in there though then you have to go through reporting process and that’s where that coder upgrade tool that I talked about getting actually completed ideally with some funding behind it from someone is going to make that a lot, lot easier. Because a lot of it changes honestly could be scripted as long as somebody just sat down and actually did the thing. Right now the process would be search the list of change notices so that list changes link I gave and then just kind of fix the errors one by one and actually find them but that’s a little bit of junky process. That’s not ideal. By the time Drupal 8 ships what I’m hoping is that that coder upgrade tool will be available even if it’s only in a beta or incomplete state. In Drupal 7 anyway we are able to expand that. So, the Drupal 7 version or coder upgrade can like convert all the database queries to the new database subtraction layer. It knows that these hooks got renamed to these hooks and it transforms things that way. That’s really what we need to make that tool or make that process a lot more seamless but currently if you try to port your modules today, the process is copy the module in Drupal 8 directory and start fixing things until it works and it’s long. It is a great way to learn Drupal 8 though [Laughter] so there’s that but yes a major version upgrade in Drupal is no small undertaking because of that drop is always moving philosophy. But the good news is with the migrate module in Core and as long as if you try to avoid custom code when you can, the upgrade process could actually be pretty seamless for you. You just sort of wait around or help get all of the contributed modules you need ported and then set up a Drupal 8 site, move your content over and you can do it on a rolling basis so like everyday import the content that was just posted that day and then when you feel like everything is ready, you make a cut over and then you port it.

Female: Awesome. We have quite a few more questions but I’m going to end with this one. I think we’ll try to get everyone else’s questions answered and maybe put it in a blog post or something. We’ll try to let you guys know but the last question is, if I want to get involved and help out, where do I get started?

Angie Byron: Yes. That’s a great question. Could I maybe present again?

Female: Yes. Sure.

Angie Byron: Alright. Share my desktop. Cool. So, the link I’ve pointed to in the presentation is the contributing link which I like because it demonstrates. There’s actually a lot of different ways to contribute to Drupal. There’s user support. There’s documentation, translation, testing, design, blah, blah, blah or yes by the way development too. So, there’s actually a number of different ways. A lot of people think, “Oh I don’t know PHP so I can’t possibly contribute to Drupal,” but that actually couldn’t be further from the truth. There’s a lot of different ways for people to get involved in all sort of things. Even marketing, I mean that’s an area where like we’re a bunch of developers, right, like we do a lot of marketing ourselves so the Drupal Association is trying to do a huge push around Drupal 8 because obviously we only hit one of these big milestones once every three or four years. It’s really good to make a huge splash when that happens. If you are a developer though what I would recommend, if you never contributed to Core before there’s a page on Drupal called Core-mentoring and this page basically covers the fact that twice weekly so once in sort of the early morning and one sort of in the afternoon UTC, what happens in Drupal on IRC there are actually Core developers there who are there to answer any questions you have. Everything from like how do I set up a development environment to what’s a good issue for me to work on if my skill sets are this, and they actually keep enormously good track of this if I can find the – I might not be able to do this on the fly. Yes, I can’t. But anyway they have like this awesome website that’s got everything. Oh here it is. All kinds of tests in the issue queue kind of pre-vetted. It’s saying this would be good for a novice. This would be good for somebody who has experience with frontend development and all those kind of thing and they can actually point you directly to something that would be useful for people. So, I would really recommend then as an entry point to Core if you are sort of not familiar to Core. If you are familiar to Core and you’ve done Core development before then hands down the easiest thing to say is you should help us fix the criticals. So, 37 critical bugs, 89 critical tests, some of those are really gnarly, some of them are like you need to be one of three people in order to actually solve those but there’s actually a lot of them especially in the bugs that often at times they’re just like oh shoot that’s just like a one character fix and we’re just going to have test coverage for it or these kind of things so there’s actually a number of things and also in the critical test, there’s a number of things that are sort of like port this thing to this API which are not only fairly possible but they’re also something that actually helps get Drupal 8 to release faster and they’ll bring you up to speed on what those APIs are early because once Drupal 8 actually shifts there’s going to be a huge cry out for people who have Drupal 8 experience and if you start now, you can have potentially six months of Drupal 8 experience under your belt but at the time Drupal 8 shifts, you’d be able to put up on your resume or your website or whatever. Then finally also with this block is this novice issues so if you want a really easily try pick up between phone calls or something these are all things that are sort of like would take one of the Core developers maybe 5 minutes to fix and maybe would take someone else 25 minutes or two days or a week to fix but they’re all sort of bite-off-able chunk things so if you’re looking for something sort of easy to cut your teeth on, that’s definitely an area that you can do.

Female: Thanks so much, Angie.

Angie Byron: No problem. Thank you everyone for coming.

Female: Yes. Is there anything you want to end with? I think we’re out of time.

Angie Byron: Well it’s actually a wonderful thing to end with so please help us make Drupal 8 awesome.

Female: Perfect. Alright. Thanks, everyone. Slides and recording of the webinar will be posted in the next 24 hours to our website and we’ll also email you out a copy. I know there’s a lot of unanswered questions so we’ll figure out a way to get those questions answered and sent out to you or put them on a blog post somewhere so thanks so much. Have a great day.

Angie Byron: Alright. Thanks, everyone.

– End of Recoding -

How to Migrate from .NET to Drupal

Unfortunately, the live event for this webinar has passed.
No need to worry! We always post the recorded webinar and slides within 24 hours of the event. Check back soon!

In today’s ever-changing marketplace, maintaining a competitive advantage is paramount to an organization's success and growth. So why do so many organizations stay with CMS platforms that aren’t scalable and flexible enough to adapt to those demands? Don’t let .NET slow you down, migrate to Drupal and get more by spending less.