 So that's kind of my cue here. Hey everyone, it's 2.16, so we can go ahead and get started now. Can everyone hear me okay in the back? Yep, good. All right. So this is the future-proofing your Drupal 7 site. I couldn't find like a good song for future-proofing, so I had to go with bullet-proof. So this is close. And I've given this talk before So if you actually have seen this before in like a Drupalcon Austin, I probably would recommend go to something else But if there's a lot of good information here, so if you haven't seen it, please say. And my Twitter handle is Dave Reid, if you'd like to tweet along during the presentation. My tweet notifications are turned off though, however, so I will not see them. And if you can follow along the presentation as well, there's a github link. Dave Reid.github.io slash future-proof And that's up-to-date with what I'm presenting right now So you could follow along because there's lots of links here, too. So it's a good link to have and I'll post it on the session page afterwards. Because we're gonna go through a lot of good modules and information here. So yeah, let's get started. And there we go. So a little bit about me. I'm Dave Reid. I'm a senior developer at Lullabot. Been working with Drupal for about eight years now. It feels like it's been forever. And again, my Twitter handle there. I like to use my real name everywhere. So I'm an IRC as Dave Reid as well. And I kind of had this reputation in the Drupal community as being the module guy. And I've got that reputation because I have written like 120 modules so far. So I like do it in my sleep. I do it in my spare time. I write modules when I'm at work. It's just kind of what I seem to do. I like doing that challenge. And I think we calculated it out. That's like at one point I had touched like almost 2% of all the contributed modules in Drupal. And then I actually wrote a module to count how many modules I'd written. And then I wrote another module to count how many modules on a site were like that you had enabled had been written by me. So those two don't really count. So yeah, and I have two cats, Rodney and Athena. Rodney's kind of like the unofficial Drupal mascot. Well, that's the kid. That's Rodney and Athena. He's the orange one. And my kid Oliver. I love him to death. And he's going to be a big brother too soon. So yeah, I'm excited about that. So that's a little bit about me. So yeah, I know a lot about modules. So this is a great presentation because it's like things you can do in Drupal 7, modules you can pick, ways to architect APIs to make your site a little bit better for Drupal 8 when it comes out. So again, for your site builders and your architects, people are actually putting the sites together. Some informed choices they can make, modules they can pick, themes they can use. That'll help ease that transition. And I like to ease that transition because every new version of Drupal comes with this cost, cost to the people that are actually working on the site every day to retrain them on how to use Drupal because we change everything, every major version. We love that as developers, but the people that actually end up using the site, you have to spend time training them how to do it. So if there's little things you can do throughout this process to make these changes as minimal as possible, I think that's worth it. And the unofficial title of this session is to backport all the things. So one of the ways that I write modules is, oh, that sounds like a cool new Drupal 8 feature. I'll backport that to Drupal 7 because I know that I can't use Drupal 8 on client projects yet for at least a year still. Even though we got Beta 1 today, yay. I want to use this stuff now, which is kind of what I do a lot now. All right. So we're going to chunk this up into separate parts. There's going to be some more that it's like the module choices and user interface things that we see every day. There's going to be more of a developer portion, but we're not going to get too in depth about code or anything. It'll just kind of touch briefly. So that's kind of the two big chunks here. So we'll just dive right into user interface section. So this is all the front end goodness, things that you can see as a site builder, that kind of stuff. It's not just code. And I can't really touch on too much more of the user interface parts before talking about the Spark distribution. It was a team and a install profile started by Acquia year or two ago to try and improve the content creating and editing UI process in Drupal. And what they ended up doing is making all these new modules first in Drupal 7 with the intent to bring them into Drupal 8 to kind of experiment with them. And I actually love them for that because that's how I love when we experiment with things with the current version of Drupal and to get it feel like you to get it right first before we put it into the actual version of core that's coming up next rather than say a module like overlay, which was experimental in putting it into core first rather than trying it in contrib. I don't know how anyone if there's anyone a fan of overlay. I'm sorry. Okay, good. There were no hands. Okay, the jokes are going to be much better throughout the rest of the session then. Good. So one of the big first projects to touch on is NavBar. So it's, you know, the administration navigation throughout your site. Core ships with the default toolbar. And that one's okay. Most people install the admin menu module. And I actually like that one a lot too. But there's this new navigation called NavBar. And the purpose of it is to make sure that's a responsive friendly navigation. So you can see kind of see here in the screenshot, you know, with your desktop viewport, it kind of looks more like a normal navigation bar, maybe a little fancier with some fancier icons. And then when you shift down to the mobile viewport, you get actually different gives more of a vertical menu. And that works with Drupal's administration menu and lots of other integrations out of the box. So I really like this NavBar project. I think it's a really good one for like the content creators and content editors, not necessarily the administrators on the site. So if you'd like to use this like with admin menu at the same time, there's actually a separate project called admin select that I should link here and I'll write in my notes afterwards to do so that lets you assign a default module to use per role. So like your administrator role can get an admin menu, but your other roles can get NavBar. And it's just kind of nice if you don't need to expose all that crazy admin menu options with all the dropdowns, they're right invisible, they can get this one instead. So I really like using this one. Another really interesting feature that landed in Drupal 8 was inline editing. So like if you're actually viewing a node, you can actually like hit a little contextual menu for quick edit. And instead of going to the node form, you stay right there on the node view and you can like edit fields and change the body text and change the title text. And it's very handy for that use case. Some would say that workflow maybe isn't the best, especially if you have like the concept of revisions and unpublished content and that kind of stuff. Like it's good for quick fixes I think. So if you'd like to use this functionality in Drupal 7 now, there's called the quick edit module, very aptly named. It has a couple of dependencies, but it's pretty much a straight back port of what's in Drupal 8. Yeah, there was some weird naming. It used to be the edit module, now it's the quick edit module because it got renamed in core and all that fun stuff with having keep up with Drupal 8. So one of the things I am just most excited about in Drupal 8 is we have officially decided on one supported WYSIWYG and that's CK editor. So it ships out of the box with Drupal core in Drupal 8 and it kind of has like a, if you're familiar with the WYSIWYG module where it lets you select which editor to use for which text format you're using. We kind of have that light functionality in Drupal 8 as well. But I just love that we've like, yes, we're going to support CK editor out of the box for everything. Because I maintain another module called the media module that has had a hard time trying to support all the various different WYSIWYGs and like all the different formats and when you're trying to do advanced stuff like embedding images and media, they can get kind of hard to do. So I'm really, really hopeful that in Drupal 8 moving forward, those modules that have those advanced things can have a much easier time. And as a developer I like having an easier time. I hope you do too. So there is a module called CK editor that you can use right now in Drupal 7. A lot of the people that were involved in making this in Drupal 8 were responsible for back porting this and kind of keeping it up to date. You can use up to the CK editor like 4.4 or 4.5 version like whatever the latest is, which I would highly recommend. So I think if you even have an existing site and you're using a different WYSIWYG, I would see if you could switch. It may not be an easy switch, in which case I'd just say stay on the current version you're working with. But if you're choosing a new site or you can make an easy switch right now, I would definitely start using CK editor. So I'd switch to that. We have a new theme in Drupal 8. The Bartik theme was added in Drupal 7. And as a Drupal 8, that theme is now responsive by default. But the one that we added in Drupal 7 was not. So some lovely people have back ported this to a theme in Drupal 7. So if you're one of those people that use the default theme to show off Drupal or on their personal website that may be www.davery.net, I'm not naming any names for people that use the default theme, but it may be me, you can use this one instead. And if you're just needing to show Drupal off as a demo, it'd be nice to have this used. That way you can show at least Drupal can be responsive out of the box. So that's a nice one to have. One that I was fairly involved in the Drupal 8 process with contributing to Core was HTML5. So there's these new HTML5 input elements like email, URL, telephone, dates, that kind of stuff. That if you were on a mobile device and you clicked into an email field, it would know on an iPhone to provide you with an app symbol by default right there rather than having to key to it. Or if it's a URL field, it'll know to put .com in there and email fields as well. So it's just a nice handy way because you wouldn't get that with normal input fields. And it's a very handy thing for your end users and your people that are visiting your site. Say for like contact forms and that kind of stuff. So if you'd like to use HTML5 input elements in your Drupal 7 site now, there are kind of two modules to use for that. The first one is the elements module that kind of provides them to be used by other modules. It doesn't actually swap anything out in Core. That's what the second module HTML5 tools does. So that goes in and changes the email field on user signup pages with an email element and that kind of thing. It provides, say if you used a number field in Drupal 7, it lets you actually use an HTML5 number element where the user can click up and down and increment or decrement the number instead of typing in the number they need to. So it's just a handy one to have on hand just to have. Another great awesome improvement in Drupal 8 is views in Core. Hooray! Yeah. So everyone installs the module. Everyone should be using views. So if you're not using views, you can use the views module. And it's readily available in Drupal 7. So it's pretty much, I think what got into Drupal 8 is pretty much exactly the same. So yeah, you could be using this now. And kind of along with that views theme, some other things got in Drupal 8 as well. So all of our content listings, user listings, all those good screens that were listings of things are now powered by views in Drupal 8 since we have views in Core. But these were not powered by views in Drupal 7. But there is a module that you can install called admin views to override these with a view version of them. And that way you can actually edit and tweak them if you needed to add fields and customize them, which is really handy. So this is a good one, just another good one to just throw in every site by default because I always feel like I'm ending up having to add additional fields to content listings or add another filter. That's really handy too to be able to add another filter to your content listing page. Yeah. And kind of along with that, in Drupal 8 we added a kind of light version of views book operations. It lets you on a listing page, it lets you do an operation like delete or unpublish to multiple numbers of nodes if you've checked them or checked all of them on the page. So I would totally encourage people to be using this right now on your listings in Drupal 7. And I believe the admin views module like adds support for this if you have it available or either has a dependency on it. So it's a good one to have around and to start integrating with now. Another interesting views module if we want to go back to kind of the responsive stuff is views in Drupal 7 ships with a grid style for your views, a way to display them. It unfortunately uses tables to display this grid. So if you need to display them in more of a responsive fashion, where if you were to shrink down the screen instead of side by side you get just one column of four, there's actually a module right now called views responsive grid that does that for you. So I would not use the default grid built in views in Drupal 7, I'd use this one. And this is what got into Drupal Core in Drupal 8. Another interesting module with responsive end views, if we're continuing along the same theme again, is responsive tables. So we had this problem with trying to make these administration screens mobile friendly in Drupal 8. And how we kind of decided there's several different kind of options for making listings of things responsive. And what we decided to do at Drupal 8 is to kind of identify which columns are high priority, and those columns, let's see if I can explain this well. So there's either no priority, high priority, or low priority. And you designate your columns either low priority, high priority, or none. If the columns are none, it means nothing will happen to them. They will always be visible. If they're high priority, it means if you were to shrink down to maybe a tablet viewport, the things that are low priority would drop and be not visible, but things are high priority would stay. If you were to shrink down to a mobile viewport, things that are both low priority and high priority would shrink, would get removed. And only the things that you haven't set priority for would be visible. So it's just another way of providing the most important information. And you set that directly in your view. You specify which columns are which priority, and you don't have to do any CSS or JavaScript, it's just handled for you. And there's a module that I backported called responsive tables that you can use and provides the same exact functionality in Drupal 7. Along the same responsive theme, there's the breakpoints concept. So in Drupal 8, we added a breakpoint module so that we could specify where those margins are in your viewports. So where does the tablet viewport happen? Where does the mobile viewport happen? And it's kind of used as an API for other things, which I will talk about. So it's not really used for the table thing, unfortunately. It's more used for images. But the module that lets you define breakpoints is called the breakpoint module. Very aptly named. And you can use this right now in Drupal 7. And it's built into core. And the reason you'd want to use this is for responsive pictures. So there's the picture module in Drupal 7 that lets you define if this, that lets you say, okay, at this breakpoint in my tablet viewpoint, I want to display as this image style. It may be one display as the large image style. But at the mobile viewpoint, display this image using the thumbnail image style and let you change which image style is used to display the same picture, depending on the breakpoint. So these two modules work together really well. And this is pretty much updated along with core as well. So it's kept very up to date, even with all the changes in how to handle responsive pictures that are happening all the time. They're doing a very good job of keeping up with it. So you can use that right now as well. And in Drupal 8, I believe it's called responsive image. So a little bit of a nameshift. It's picture in Drupal 7, but responsive image in Drupal 8. So this is one of my favorite things as a developer. It's tours. So Drupal 8, we added this functionality using a JavaScript library to kind of add these nice little demonstrations or tours throughout an administration page. So the first time that you hit the views, maybe like you're creating a new view, there's this little help option that pops up in the nav bar. It said, hey, would you like a tour of this page? And you click that and it says here's where you type in the title of the view. Here's where you select the fields that you want to add to the view. And it kind of points you to specific parts of the page and has previous next, you can navigate back and forth just to kind of give a little bit more helpful showing of where you should be doing things. And it's really helpful for stuff like how do I enable another language in my site? We have a multi-lingual tour in Drupal 8. And that's super, super helpful. And so I think this is a great thing as a developer to provide for if I have a complex UI that I added in a module or even for end user, like your site visitors to add a tour to a specific page that you have. I think this is a great, great pattern to start using. And there are tours in Drupal 8, but in Drupal 7, it's the joyride module. There's a whole, I think it's just mostly a library in Drupal 7, so I think you'll have to kind of write a little bit more custom code. Then you do for Drupal 8, they're kind of defined in code. So yeah, this is available to use and I would highly encourage people to check that out. So module page filtering is an interesting one. There's kind of the typical module that people use is called the module filter module. Has anyone used that one before? Yeah, that's a lot of hands there. So I don't actually like use that one. So Drupal 8 added this very, very basic filtering to modules, your module listing, that just basically you type in what you're searching for. And that's really all there was. That's it. It's just really, really helpful and small. Now I recognize that the module filter module does more things like that. It shows you like, sorts them by enabled or disabled and that kind of stuff. And I'm sure that'll be ported to Drupal 8 as a separate contrib module. But if you'd like to just kind of have this functionality, and I think it's a little bit more lightweight, there's the instant filter module. And it's actually really handy too because this pattern can be used on other pages. So for instance, this is used on the permissions page. Has anyone had trouble finding and searching for things on the permissions checkbox of hell? Yeah, yeah, there's a few of us there. So this might be handy because it's not only just the one purpose of the module page. And as a developer, I could take advantage of this and use it in my own module if I had a large listing page as well. So yeah, there you go. That's a fun one to use. This is a very small, tweaky module called simplified menu administration. If you've ever gone to edit the menus on your Drupal site, it's kind of confusing. There's edit menu and list links. And if you're like, I want to go add a menu link, you go edit menu. But unfortunately, you can only change the name and description of your menu. You can't change the menu links there. And then I think it's a thing that gets caught up by a lot of editors and content creators too. So this module kind of resolves that and just merges those two, the list links and edit menu into one same page. And only offers it as one item in the menu. So if you go to edit menu, you can do that all from the same page. So this is one I just throw on every site when I'm from the start. So I mentioned overlay. And I don't actually have overlay jokes, although I should prepare them. So overlay was removed from Drupal 8 core. Yay! Because everyone disables it by default anyway. But we had this interesting problem that we still needed to give someone a visual indicator of like, when am I in the back end of my site? When do I know when I need to go back? And that kind of thing. And so we had an interesting solution in Drupal 8 that with our navigation bar, if you were to be on a front-facing page and then somehow click to an administrative page somehow, you would then all of a sudden have this very top left thing appear called back to site. And it would take you exactly back to the page you were on before. So if you were to keep going clicking around between administration pages, this would still stay the same link back to the first note, the first page you were on. So I think it's kind of a really handy way of solving that. And I wanted to backboard this to Drupal 7, and so I did. And so it's the escape admin module. And it works with the nav bar. It works with the tool bar that's built in core. And I believe there's a patch to make it work with admin menu as well. So it should work with all three at some point. Yeah. Another interesting one is caption filter. Wim Lears, I don't know if you've seen a presentation or saw him around this week, but he deserves a lot of thanks. He did a really great job in Drupal 8 core with helping improve the way that we caption things in WYSIWYG. Rather than using a special syntax or a special token, he actually made it so we can add captions right there in the HTML attributes. So this example here, I'm using a data attribute called data-caption to provide what the caption should be for this image directly there. And then this gets converted to an actual figure and figure caption HTML elements in my WYSIWYG. And so there's a project called caption filter. The version one of the module does use kind of a special weird syntax for doing captions. And I'm working with the module maintainer to make a second version that's a back port of what we have in Drupal 8 core. So if you're interested, you might want to be following this module and start using this because it'll make, you know, migrations easier. You'll have to change your content when you move to Drupal 8. And the next two modules are going to be about blocks because everyone loves blocks. But everyone hates in Drupal 7 how you can't output a block in more than one place. It's just, it sucks. So the first module here is called bean. And bean, it's trying to solve the fact that custom blocks in Drupal 7 are basically only just a text field. And sometimes we have a more advanced use case. Maybe you want to add a link field to your block rather than having it put in the WYSIWYG. I think it's better to have structured data rather than just shove everything in the WYSIWYG. So bean lets you make custom blocks with fields, which I think is really great. And it's actually very, very similar to what Drupal 8 has. You can create custom blocks in Drupal 8 and any different types of custom blocks. And you can have fields on those. And it's really, really great. So if you'd like that functionality, I'd recommend bean. And I talked about the fact that you can't reuse the same block like in a different region on the same theme, but there is a module to solve that. It's called the multi-block module. So if you have that use case and you're not using something maybe more like panels or context, you just want to keep it simple. You could definitely use this module to try that out. All right. So next quick section, that was a lot of front-end stuff, hopefully everyone's still with me here. We're going to cover some new field types that were added to Drupal Core that you can use right now in Drupal 7. So we have entity reference fields. Typically in Drupal 6, there was like the node and user reference fields. And we're really, really trying to get everyone away from using those. Those are completely deprecated. And entity reference is now like the de facto module to use. And this has actually been added to Drupal 8 Core, which is why it's in this presentation. So definitely be using this. It's really handy because it can refer to all different things. Lots of modules integrate with entity reference and do special things with entity reference fields. For example, I've written a module that, like, if you have an entity reference field on your node, you can configure it to delete all the things in your entity reference field when your node is deleted and cascade that delete down, which is kind of a cool thing. But that's only available for entity reference. If you have a need for phone numbers, like in contact forms, that kind of stuff, typically people use the phone module in Drupal 7. But actually there's a different module I recommend using that's much more similar to the Drupal 8 version. And it's called telephone. Not confusing at all between the differences of phone and telephone. And it's very, very simple. It's just basically an HTML5 telephone input. There's not a whole lot of validation that happens. If you need that validation and want that validation, I would probably recommend the phone module. But if you don't, and I don't think it's a good idea to have that validation, because phone numbers are hard, I would check out the telephone module. It's just easy and very, very simple. Yeah. We added an email field to Drupal 8 Core. And it's very, very simple. It's just an HTML5 email field. So there's just the in-browser validation that happens to make sure it's a valid email address. There's nothing much else that happens. There is a project on Drupal called email that's available for Drupal 7. I think most people are using that already. But just have an understanding that the version that's in Drupal 8 is much simpler than that. And if you have that HTML5 tools module I mentioned earlier, it makes it so your email fields in Drupal 7 can use the HTML5 input element. Dates are a fun one. So Drupal Core added some HTML5 date elements. And it's kind of interesting. This question actually came up in my last time I gave this presentation. Like, because the date module in Drupal 7 provides you three different options of date fields. It provides you an ISO format date or a UNIX timestamp date field. So it's which one do I use? And I'm always confused by this. And I now can give a more definitive answer on what type you should use. It's the date ISO format field type that you should be using. Because that's the version that's in Drupal 8 Core. And the other two are essentially deprecated at this point. So hopefully that gives a little bit of clarification for any site builders or people adding fields to content. So now we're going to touch some backend stuff. A little bit of code, a little bit of modules. Because it's a lot harder to backport Drupal 8 code than it is to do front-facing stuff. It's pretty easy to backport. We can emulate that pretty well. But there's a lot of... If it were easy to backport Symphony to Drupal 7, I would do it. But I don't have that much pain that I would like to have. So Drupal 8 added unique identifiers, UUIDs to all entity types. So to all your nodes, users, content, files, all that good stuff. But Drupal 7 does not have support for that. So if you'd like to enable support for UUIDs, if you have issues with deploying content between servers, that kind of thing, you probably have this module already enabled. I wouldn't say there's a need to have this enabled right now. But if you want UUIDs, this module would support them for you. So render caching is a really, really fun one that I've been getting into the last month on my project. We've been writing a theme in our project where we're outputting like, oh, given this node, display this field short title using this formatter. And we've been outputting all these different fields kind of individually. And I've had this kind of nagging feeling at the back of my head watching this code go in that like, these are uncached because stuff that happens in the template only really happens, gets affected in page caching. So these are uncached calls happening to render fields for any logged in users. And there's a great module out there that was started by Wim Lears and has continued by another developer called the render cache module. And it's really, really cool because it allows, when you view a node, it allows that output to be cached in your cache table or if you're using memcache or redis, that kind of thing. So the next time a logged in user views that node, it's hitting the cache rather than building that entire node and rendering it again, which severely improves performance. And then it has a dependency called entity modified. So I would highly encourage people to actually throw this one on every module, every project from the start, especially if you have lots of logged in traffic. It could really help improve things. For the developers, I wanted to talk on some libraries and APIs and plug-in stuff. So it's going to go into a little bit of code, but I'll keep it pretty light. For those of you that need to use external libraries or like PHP libraries in like your custom code, that kind of stuff, I would highly recommend get started with Composer. It's the standard way to like depend on external libraries, say that I depend on the Dave Reid cool stuff library version two. And I should download that in a standard way. And it's called, it can load that code and make it available to my code to run. And that's called the PSR0 or PSR4 standard. So how that's used, and this is an example in a project I used recently. I declared a Composer.json file in my site's all directory that I had, this is a book site, so I wanted to use this ISBN library to verify if an ISBN was correct, if it was an ISBN 10 or ISBN 14 for book identifiers. And so I put that I required this library in my Composer.json file. And then in the module that I needed to use, in my site's all directory, I'd run Composer install. It would download this library for me, and I would commit that to our project. And then in my module, I would say require the site's all vendor slash autoload, which is the file generated by Composer. And then I could use that library directly, which is really nice. And if you'd like to have a better way to load all the stuff from your Composer file, there's some modules that will do that for you rather than just calling Composer update and that kind of thing. So plugins, there's this whole new plugin system in Drupal 8 that's really, I think it's really great. Joe Schindler is actually in the room right up front here. He did a whole great documentation on how to use the plugin system. But there's not really a good standard way to do plugins in Drupal 7. So I'm going to kind of show you how I kind of emulate this in Drupal 8, and we'll go very high level. So kind of one way that we've typically done plugins is with the hook system in Drupal. So I have a hook my module, hook info, and I would say the label of what I'm doing, there's a function I would call if I wanted to do this thing. And if there's a settings form to configure it, I would point to that function, that kind of thing. It's very, very functional procedural kind of style, but it's easy to do. I can understand that. So that's one way that we've done it before, but I don't really prefer this. Another way is C-tools plugins. Has anyone worked with C-tools plugins before? A couple, okay. I find this terribly confusing actually, and I don't know, maybe it's just me, but like you have to declare like where your plugins live. You have to give it like an info file, and then there's a class or some procedural code that runs the C-tools plugin. And I find this really confusing. I'm sorry, Earl Miles, who wrote the C-tools plugins, I find it confusing. So what I do for plugins, if I'm making an API in Drupal 7, is I like to use classes, because that's what the plugins in Drupal 8 do. So I define an interface which has a method called do something, and then I have a base class that all the plugins should derive from that kind of takes care of some basic functionality that's shared. So like they get defaults for configuration to return an empty array, that kind of stuff. But it leaves an abstract method called do something. It says everything that extends this class should implement this method, but I'm not going to do it for them. So that's what my base class does. And then if I were to override an implementation of this plugin, I would have my example module, I would just have a quick hook info, because it's a standard way of discovery in Drupal 7, that just basically says a label, and I point to the class that implements this plugin. And then I have my plugin file that has this do something method. And that's really all I need to do. And then oh shoot, I did have code. I'll post it afterwards to show how I would invoke this plugin then too. But that just covers how I would do a plugin. If you're a module developer, there's other options available in Drupal 7, and it's much easier to shift this code and port this code to Drupal 8 than any of the other ways. So let's just briefly cover some of the other stuff here. View modes are a great, great thing that was introduced in Drupal 7 and is now really, really supported in Drupal 8. So rather than configuring a view display with different fields and that kind of stuff, you can actually go on your content in the content type screen, configure how the teaser is displayed for your node, or the full page is displayed for your node. And you're not limited to those view modes. You can create more view modes if you need them. Like I can make a card style view mode for a card display of things. Or an RSS view mode for outputting nodes with RSS. So if you'd like to add more view modes to your site, you can technically do it in code. But if you'd like to do it through a UI, I'd recommend this module, entity view mode. And it's really, really handy. I would really encourage people to use view modes everywhere when displaying content. Try and fit it into a view mode somehow. Because it really means that this can be cached easily. It'll be much more compatible with Drupal 8, all that kind of good stuff. Configuration management is this big thing that got into Drupal 8. It's going to be like, it's going to be features, but it's going to be everything solved in the way that we want it, in features that works right in Drupal 8. And I wish I could tell you there's a magic solution in Drupal 7 that gets us to work right. But I'd probably just say keep using features. I'm sorry. It's a let down, I know. There is this kind of configuration module that is kind of a little bit more experimental, but people are working on that might be possible for you. I'd say give it a try. But if you know features, we've all been using features for several years, I would say keep using that. Migrate module. It is your friend. Every developer on your team should be using Migrate at least once. Get them some kind of migrate task. Have them just migrate from a Drupal to Drupal site. I don't care. It's going to be super useful knowledge for them to have, especially coming into Drupal 8 because Migrate is going to be built into core. And with Drupal 8, there is no more update.php between Drupal 7 and Drupal 8. It's going to be a migration path that you will have to write some custom code if you have custom stuff. Otherwise, we can configure most of how to migrate it. So getting experience with using this system now is really, really important, especially since clients will start asking about when can we migrate to Drupal 8. Well, you have to know this first for your team. And if you have experience using this, it will be a little bit easier. Restful web services. So if you need to expose APIs on your site, exposing, not necessarily ingesting, there's a couple of good options here. Typically, people have recommended the services module. And I think it's still okay. There are some security concerns as of last year, basically. And I don't think that it integrates very well, like, for all your entity types. So there's a couple of modules here. There's the restful web services or restws. Or there's a GitHub module called restful that both do a really fantastic job of exposing for all your entity types in a much more configurable way. So I would encourage these to be checked out if you have an API on your site. Translation is a big one. If you need to have a multilingual site, kind of the standard encouraged way is using these two modules here. Entity translation and the title module. Some people use the content translation, one built into core, which like duplicates nodes in different languages, and we don't want to do that anymore. So definitely entity translation and the title module will give you a lot of support. And that's actually pretty much built into Drupal 8 core. So that's really great. Gabor is the one who did a fantastic job leading that initiative to make that better in Drupal 8. And there's lots of even more things I could cover, but I won't. External things like testing with PHP unit. All the symphony stacks that Drupal 8 has started to replace. Hopefully most people shouldn't need to know the symphony concepts, but it can't hurt. I know that several people on the Lullabot staff just like to explore making a quick symphony site without Drupal and just getting some experience working with that, because it can't hurt to have that experience. So encourage people to try and experiment with that. There's some JavaScript libraries, like underscore and backbone, which are being used in Drupal 8. So those are going to be available, so I'd try taking advantage of them now. Those are actually dependencies for the navbar module, too. So you'll have them on your site if you use navbar. Guzzle is an interesting PHP library. It's a replacement for the fetching information via HTTP. So it's just a thing to get data from another server. And Drupal has an internal method for that, but I would encourage people to start playing around with guzzle for that, because it's built into Drupal 8 core now. And just experimenting with other stuff like JavaScript local storage. We're using that for storing the back to the site link in that escape admin module. And Drupal 8 is using JavaScript local storage a lot more for everything, too. So start taking advantage of that in your Drupal 7 sites now with custom JavaScript you're writing. Experiment with Angular and headless Drupal. It's going to be things that are really starting to come into popularity with Drupal 8. So don't get behind on those. And I really should mention, it's an interesting development since the last time I gave this talk, too, is there's actually a distribution available to try all these things out in Drupal 7. I probably wouldn't recommend it for an actual client site. It's more just like, hey, that's cool. I'll see what it can do. So it's called the pre-D8 install profile that has most of the modules I've mentioned here in this talk. I don't actually maintain this one, which is a surprise. But if you'd like to try all these things out together, give this a try. And of course I've told about all these great things that are new and coming and you should be using, but we should really cover the things you should stop using, too. There's actually a page on Drupal.org that lists all the things that have been removed from core. So things like the blog module, you can probably just replicate that by making a new content type, rather than having a module for it. Just stop using that one now. The dashboard module is actually gone. The garland theme, if anyone's using that one, it's gone as well. The open ID module, that's a good one, too. If you're using open ID, I believe that's probably going to be moving to contrib for Drupal 8, but there are some security concerns about it as well, since we've had to fix those fairly recently, and we're not sure how secure it will be in its lifetime. Overlay, as I mentioned and kind of joked, is gone. There is no plan to keep it in contrib, although I guess someone could do that if they wanted to. The PHP filter. Has anyone used the PHP filter? Oh, people want to even admit raising your hands. That's great. Yeah, it's gone out of Drupal 8 now. It's a contrib module with a dependency on the bad judgment module. So you'll probably want to investigate how to remove that if you can. Either move it to custom code or replace it somehow, so you'll probably want to get in a path to figure that out. The profile module is now gone. It's actually hidden in Drupal 7, so I think a lot of people are using profile 2 as the module for replacing that. And the trigger module has gone now in Drupal 8, and our hope is that the rules module seems to be doing well with their porting effort, so that should probably be the module to use then. And that's all I had. That was a lot of information, so hopefully there's still room in there for the rest of today. If we have any questions, there's a microphone right up here, and I'd like to welcome anyone that has questions. And if not, you can enjoy the rest of your afternoon. Yes, right here. Yes, the question is, do view modes also apply to views? It does not if you're using a field display on a view, but if you're using, like, a display a node or display an entity, yeah, just I would say make your view display the whole node and do that and configure everything with view modes, because it's way more repeatable, oh, I just need to output another node randomly somewhere else. I can do that since it has a view mode. Views configuration with field is not repeatable. It's only repeatable in views, so yeah. Any other questions at all? Yes. Panels in display suite, what do we do with those? Panels, I'm pretty sure, is going to be ported to Drupal 8 as a contrib module. There's not really anything available in core that provides that. Display suite I think is kind of interesting because I think it'll be deprecated going into Drupal 8. A lot of the stuff like the entity view mode module supports some of the functionality that display suite does. You actually can manage the display of your form a little bit better in Drupal 8 core, so that kind of deprecates some of the functionality by display suite. It may live on just as some of the other parts, and I think there's layouts somewhere in core. We're not sure if it's going to end up in contrib, so yeah, it'll probably be split up somehow. All right, yes. Yes, it's called display modes in Drupal 8, and there are both display modes for forms and display modes for actual viewing of content. That's kind of what I was saying. You can actually configure a short registration form for your users using a short display mode and configure how that form is displayed, hide certain fields, change the widget for certain fields, but if they are on their user editing page, it could be different. Sorry, I say again. For Drupal 7, I wouldn't say there's anything that lets display suite kind of does it, but it only lets you do it for one form. It doesn't add support for multiple different types, so yeah. All right, if you have any other questions, come up to see me later, but thank you very much, and have a good rest of your afternoon.