 All right, I think we'll go ahead and get started here. So this is the 1045 session, Future Proofing Your Drupal 7 site. Good morning, everyone. How was the keynote this morning? Good? All right. I wouldn't know I was preparing for today. I'm sorry. So yeah, welcome. I hope you're in the right place and ready to take on a lot of information coming here. It's gonna go through pretty fast. I'm not gonna apologize about that because I have a nice little handy link on my slide. It's davry.github.io, and then today's date in a year month day format. Cause I prefer that rather than the American system. So if you wanna follow along or see all the links, there's lots of links in here. That's a handy way to do that. So a little bit about, oh I didn't plug in my remote. Here we go. Okay, let's try it. There we go. A little bit about me. Again, my name is Dave Reed. I am currently a senior developer at Lullabot. So it's an all distributed company and I live in Omaha, Nebraska. So nice Midwest. So just came a little bit south here to Austin. That was nice. I'm known everywhere just with my real name because I don't like pseudonyms and I can have that privilege. So Twitter and IRC, all the same name. I'm commonly known as the module guy. You may have heard that reputation before. Think we looked last night, my current module ownership count is about 126 modules, which probably corresponds to still about 2% of all contrib. Maybe a little bit less. Maybe like that's rounded up. Because it sounds more impressive. So I kind of know a couple things about modules. And I've recently been on this kick to like, like all these new things coming into Drupal 8, like I can't really use them on production sites for clients and stuff and projects I'm actually working on. And I always get frustrated because it's all these new features and things that I want to be using. And so it's kind of what I've been on a kick recently and kind of inspired the session. So I'll kind of get into that a little bit later. I do maintain a couple areas of core, mostly like the token system now. And I have two cats and one like year and a half old son. So I figured this is Austin. This is a good way to show him off because he's, we're raising him right. Literally gnawing on a rib bone. And then my cats. The orange one is named Rodney. He's kind of the unofficial Drupal mascot. I don't know if you knew that. So yeah, that's a little bit about me. And so we kind of, we have two high level objectives for this goal, for this session. You know, I want to make sure that your architects and site builders can make some informed choices now because Drupal 8 is coming, but it's probably not coming as fast as some people would hope it comes. So we're probably stuck with Drupal 7 for a while. As Dries said in his keynote yesterday, that if you're going to build a site, probably use Drupal 7 now, and probably for the next year. So there's some informed choices we can make to kind of ease the pain of switching to Drupal 8 when you're going to switch. Making sure that you're making good choices, user interface elements, that kind of stuff that will be compatible with Drupal 8 in the way that it does things. So hopefully, it's less training for your site builders, that kind of thing, or your content editors, content creators. And like I said, this session is basically like backport all the things. That's really what I've been doing recently. So it's a lot of modules that were written for Drupal 8 or core functionality that have been backported to Drupal 7. So that's what we're going to go through. So first up is user interface areas. So those are all those shiny things, things that people love to see. So we'll go into that. And I can't really go into this too much without also giving a huge amount of credit to the Acquia team and appropriate that we're speaking in the Acquia room to the Spark distribution team who did a lot of work into prototyping these things out, getting them done, kind of working on them and pushing them into Drupal core. So they deserve a lot of credit for a lot of these things. So the first thing, let me see if I can zoom in. There we go. So it's a mobile-friendly navigation toolbar or navbar for short. There's a wide amount of community toolbars. There's admin menu. There's the toolbar that ships Drupal core. But there's actually a new toolbar in Drupal 8 and it's what this navbar module is based on. And it's mobile-friendly, so it has a long strip at the top if you're using desktop. But if you're using a mobile device or tablet, it kind of shrinks down and uses a left-side menu and that kind of thing. So this is ready to use right now in Drupal 7. So that's the navbar module. And it's kind of nice because it provides ways to integrate with it as well. And I think some of the Drupal 7 modules are starting to integrate more of it as well. So yeah. There is inline editing in Drupal 8 core and it is available right now for Drupal 7. You may hear Jeff Eaton talk later today about body fields and he made not approve of inline editing. So this is kind of more of a controversial one. It works great for showing off and demoing or certain workflow cases. So I would be a little bit more cautious in using this one, but it is completely available to use in Drupal 7. You via the quick edit module. So that's a good one to use if you want to use that workflow. But I cautious. So the difference between edit and quick edit is actually it was renamed from edit to quick edit. Cause I believe they renamed it in core to kind of distinguish like if you want to quick edit something rather than edit something. So they back ported that rename as well. So it's quick edit now. One of my favorite, favorite things in Drupal 8 core is we have officially decided on a officially supported edit editor, it's CK editor. Yes, there was clapping for that. I know you're all happy about that. As a module developer trying to support many different WYSIWYGs via the WYSIWYG module turns out to be not as fun of a job. So having core make a choice and say, everyone should support this out of the box is really, really helpful. So if you're picking a WYSIWYG editor for your site now I would definitely go with CK editor. There's a couple different modules that can be used. I would probably just recommend using the CK editor module. So project slash CK editor rather than using like the WYSIWYG module or there's another kind of project by Nate Haug or quick sketch like CK editor for WYSIWYG that was kind of used to develop for the Drupal 8 stuff but I would just use the CK editor module. It's got the most development behind it for Drupal 7 and some aqueous support behind it as well. Yes, question. These are all modules you can download for Drupal 7, yes. Yep, so all these should basically work exactly the same way in Drupal 8 as much as possible, so yep. Can I continuing with the nav bar and responsive theme? There's literally a responsive theme now. The Bartik theme in Drupal 8 core is responsive and we have back ported that into a theme for Drupal 7. So if you do use the out-of-the-box theme and there might be some of us that are guilty of that on my own blog, because I just had to pick one. It is responsive out-of-the-box, so it's kind of nice and it works well with the nav bar. And there's lots of other good choices for responsive themes in Drupal 7 as well. Omega, all those good themes then, all those are still good choices too. But if you want to use the core theme, responsive Bartik is the way to go. Ah, another great one is HTML5. This is kind of one of my pet projects I had for Drupal 8, the good I got started in, was making sure that we supported HTML5 input elements all throughout Drupal core was a big initiative. So if you type in an email field on your mobile device, your iPhone or Android device knows to make sure to provide an at sign in your keyboard by default, or if you're typing a URL, it knows to provide URL characters in the keyboard by default, and it's just kind of contextual information. But it's just really nice to use because it helps out the end users. It provides some built-in validation. So we've kind of backported those HTML5 elements. There are form API elements that developers can use via the elements module in Drupal 7. And I maintain that one as well. So, and then to actually use those elements, like replace core stuff with those elements, or make them available for field widgets, that kind of stuff, that's why the HTML5 tools module does. So one provides the base level support via form API, one actually swaps out core stuff in Drupal 7 core. So that's the elements and HTML5 tools. Views is in core, yay! So, is there anyone that's not using views module? It's okay, it's okay, you can raise your hand if you are. Okay, well that's good, you're all using views, so I don't need to tell you to use views. So you should be using views, views, views, views, views. So yeah, like views is used throughout Drupal 8 core, it's used for the front page, it's used for all the blocks, everything is basically views powered, which is really great. So don't be afraid to do that in Drupal 7 as well. But use views responsibly, of course. Not only our front page, and all the kind of front end facing stuff, views in Drupal 8, the back end stuff is also views in Drupal 8. You know, your content listing screen, your user listing, those are all views, which is nice because you can extend them and add fields if you wanted to list them to the tables, that kind of stuff. And there's a module to do that in Drupal 7 that kind of just swaps those pages out with a view. And it's the administration views module. So I would highly recommend that one. That's a really handy one to have. I know modules like file entity in Drupal 7, we also integrate with this to provide a file listing that's a view out of the box. So yeah, it's a nice handy one to have. And kind of along that administration kind of theme, there's also views, bulk operations, is the module in Drupal 7. We kind of have a light version of that in Drupal 8. They're just kind of a simple action. There's not anything like set entity values or those complex kind of actions that were available in Drupal 7. But there's stuff like block users. There's stuff as available that you can use in these views. So if you're using the administration views module, I think it provides some support for views, bulk operations, or VBO out of the box. But I would definitely encourage you to this. Like I know modules like a Mollum are adding support for bulk operations as well, which is kind of nice since if you make a comment view, you can block stuff through Mollum or report stuff through Mollum right there in the interface, which is kind of nice. There's a grid layout in views, which kind of layer stuff side by side. And it used tables in Drupal 7. So when views was ported to Drupal 8 and they took a look at this functionality, they actually rewrote it to use a more responsive div-based layout. So that if you're using a grid, things shrink down nicely if you'd like to. And this is actually available now to use in Drupal 7. It's views responsive grid. It's different from the one that ships with views in Drupal 7. So you kind of have to make that distinguishing identification. But I would highly recommend using this one if you have a grid-based layout in your view. So the question is if you update to Drupal 8, do you need to change your view display plug-in? I think you might, but you'll have to change your entire view anyway probably. So yeah. There'll only be one grid then in Drupal 8, so. Responsive tables is like this little small functionality in Drupal 8 that I backported and I kind of was obsessed about for a little bit. It's this interesting functionality that if you have a table view, you're able to mark certain columns as less important or more important. And what that means is that when you shrink your viewport down, the columns that are marked as less important will just go missing and hide since they're less important and not as needed for that view. And then as you're shrinking it down even more, like going to the mobile viewport, the columns that are marked more important are the ones that'll go next. So anything that you haven't marked as more less important basically means really important and will always stay. So it's a nice kind of way to do this table view and make sure it still will work in a responsive fashion. And you do it throughout the views UI actually. And there's actually an API to do it, using theme table too. But it's kind of nice you just mark check boxes or mark each column as important or less important. Yeah, it just works out of the box. That's kind of a nice one there. And that does get exported through your view as well. So as long as you have the module enabled. We also added the breakpoint module to Drupal 8 core. So there's at certain points, your layout shifts, at 124 pixels, things will happen differently. At 500 pixels wide, things will happen differently. And you can define those breakpoints through the UI in Drupal 8. And there's a module for this in Drupal 7 called breakpoints, very aptly named. And it's more of an API module. So, and we'll get into what module uses it next. But the intent is that this is kind of used as an API for like layout builders in core, that kind of stuff. But mostly it's used for responsive pictures. So based on certain breakpoints, what image style should be displayed? And that image will be swapped out or displayed properly. So the picture module for Drupal 7 is one that implements that functionality. I believe there may be a little bit of like, I think they finally figured out what kind of responsive way they're making this thing happen in Drupal 8 core now for picture element, now that there's like an actual standard way to do this in HTML. So I think they just swapped out the way to do it in core. The picture element, I think there's an issue to backport the core functionality again that was changed. But I think it still works out of the box. It just, it may be a little bit different once that's committed. So if you want some responsive pictures, which most people probably do, you can use this one. Okay, this is one of my favorite things that was added because I could probably use this on every project that I've worked on. Tours are this really great thing where if you're visiting a page and you see in the toolbar, like, hey, do you want some help about this page? And you click that and it kind of shows you, hey, here's the first thing you probably want to do and it kind of points it out where it is and then you hit the next button and it goes, and here's where you probably want to go next. And you should do this next. And it kind of just goes in through an in-page interactive tour just with like bubbles of text or there can be images or there can be anything really inside these bubbles. And we added the tour model to Drupal 8 core in order to provide help. So it's on things like the views administration screen. So you get a basic workflow on how to edit a view, which is really, really handy out of the box. And I believe there's a multilingual tour as well. How do I enable multilingual for my entity type? Which is, again, a really handy thing for site builders. And I could find that I could use this for any kind of complex UI that we build for a client or even a front-end customer-facing thing, too. Like you want to give them a tour of how to fill out this profile page or sign up for this kind of service. You could use this. So there's this module called Joyride, which is actually the plugin that we used in Drupal core, the jQuery Joyride plugin. So you can use this module right now in Drupal 7. I would highly recommend it. I think it's a great kind of front-end UI helpful interaction for not only end users but your clients. The question is, are those tours exportable? I don't believe so in Drupal 7, but they are in Drupal 8, so. So yeah, your module in Drupal 8 can ship with its own tour out of the box in configuration, which is nice. A simple one, but really, really handy. Module page filtering. I want to type in the name of the module so I can find it easier and I don't have to scroll past all 200 modules. It's something we all want to do. And there's actually two modules that do this really well in Drupal 7. There's the module filter module, which I think probably most people actually use, which more changes how the module page works and how the user interface works there. But I actually kind of recommend this module instead. It's the instant filter module and it's much more simple. It basically just gives you a text box to type something like you type in views and it'll filter down the list to show only things that correspond to views. And that's really all it does. And this corresponds pretty much one to one with what is in Drupal 8 Core as well. So this functionality has been added as well. And the nice thing about this one is it also can be used on other pages. Say like maybe there's a page in Drupal that has lots and lots and lots of check boxes and lots of rows. Maybe a listing of permissions. I don't know if that's been a problem for anyone before, but you can use this on that page too, which is really nice. Oh, module filter does it too, down that module. Okay. Well, I prefer the other one. So give both a try. A little, little tweak that was added to Drupal 8 Core was if you have menus and menu links, it's kind of weird. There's two different links. There's edit menu and list links. And it's always kind of weird because your brain kind of thinks if I want to edit the menu, I also want to edit or add links. And it's really confusing. So they actually fixed this in Drupal 8 Core that edit menu, both you can edit the menu name and description and also add links or whatever you want to do. So this is actually a back port of that little tweak functionality in the menu links. So it's simplified menu administration. And I find this is just a nice easy one to throw on right from the start that just helps simplify that UI for menus. So I'd recommend this one like out of the box on all sites. A fun little change that was made in Drupal 8 Core with the toolbar. If you're on like a front page or any non back end page, your toolbar has like all the admin links and stuff, but there's no actual home button. And the moment you go to administration page from wherever you were, you suddenly get a back to site link in your nav bar. And it'll take you back to where exactly you were before. And it uses your local storage in your browser to store where you were before and persists that until you're done. And so I've actually back ported this functionality to Drupal 7 with the escape admin module, which is compatible with both the nav bar module and also Core's toolbar module in Drupal 7. So it's just kind of a nice way to give people an actual way back to where they were. So if you want to try that out, I would recommend it. Another fun module is the caption filter. So Drupal 8 added this really cool ability that if you added a certain attribute on any kind of HTML in filtered text or your WYSIWYG text, if you added data caption and then put in the caption in that attribute value, it would automatically make a caption out of whatever you have that attribute on. So it could be an image, it could be a video, it could be a div, I mean literally it could be anything that has a caption. And so we're looking to back port this to the caption filter module, which is really, really handy. It's just nice because having that data just right there in the HTML is really, really great. All right, yes. So he's pointing out CK Editor, the newest version has a plugin for captions. I'm not sure if it's compatible with that though. I'd have to check on that, so we'll get back to that. All right, blocks. There's lots of improvement to blocks in Drupal 8 Core. So you can actually make, in Drupal 7, you just had one type of block and it was just filtered text and they were great until you wanted to do more advanced things. So Drupal 8 added this ability to make custom block types and you can actually add fields to them too. So there's a default block type in Drupal 8 that has a text field or you could do a block that has an entity reference or a block that has files listed in it, whatever you want. You can make custom block types. And the module that corresponds best to this functionality in Drupal 7 is the bean module in Drupal 7. So I would highly recommend that one kind of be used out of the box by default too. That works really well. And along with changes in blocks in Drupal 8, you can now finally actually reuse a block in more than one place, the same exact block. You can use it in a different region in the same theme. You can use it in two different themes, like it's what everyone has wanted to do at some point. And so if you'd like to have this functionality in Drupal 7, there's the multi-block module. All right, so our next kind of section is just a little bit quicker. It's the new field types that were added to Drupal 8 Core. So I mean, I think everyone has a pretty good handle on what field types to use in Drupal 7, but there may be some new ones here for you. And that screenshot's a list of all the new field types. In Drupal 8, which is much bigger than Drupal 7. So first on the box, biggest one to cover, entity reference module. I hope you're using this when you want to reference another entity or link to something, that kind of thing. And you're not using the older references module or node or user references, or what they was called. So definitely the standard is using entity reference for everything now. It's fantastic. Phone numbers. This is a little interesting one. Drupal 8 added a telephone field to Core. That's just, it's pretty darn simple. It's just an H205 phone input element. And there's typically been the phone module for Drupal 7, but it has a lot of functionality kind of out of the box and that you'd have to overcome if you don't want that. If you just want people to type in a simple phone number and you don't really need to do much with it, I would highly recommend the telephone module, which does basically the exact thing that Core does. It's just a simple element with H205. Yes. This one, it will use an H205 element if the elements module is enabled. So elements module is one I would throw on every site by default. That way you get H205 support if a module needs it. Yes. Yeah, there's no fancy validation with this one. So it's totally possible if you wanted to add validation, you could. If you need that validation, I probably would recommend the phone module for now. But if you just want to get people a place to type a phone number and you don't really want to do much with it, you just want to have it as input, I would recommend the telephone module. Email fields were added to Drupal 8 Core and there's pretty much only one module to do that in Drupal 7, which is the email module, very aptly named. In Drupal 8, it's more of a lightweight field. It's just like telephone, it's like an HTML5 email input field with. And the only validation that happens is does it validate that it's a valid email address? And the browser also can do some client-side validation of that as well. And so I think you would need, if you use the email module in Drupal 7, I believe you'd need the HTML5 tools to have that HTML5 version of it, so I'd recommend that. Links are another fun one. This is one that I kept getting frustrated with in Drupal 7. So there's a link field in Drupal 8 Core that is, again, it's very simple. It's just a HTML5 URL field, which enforces that the URL must be an absolute URL. So it must start with like HTTP colon slash slash something, which I think we might have fixed that in Drupal 8 to allow internal stuff as well. But I actually backported the simple version of this. So if you just want a field for external links or if you just don't care that they need to point to internal stuff or you just can paste in the full URL, whether it's on the site or something else, there's the URL module, which is very simple, very lightweight. There's also the link module in Drupal 7, which can refer to internal stuff on your site or external stuff, but there's also a lot of configuration and a lot of validation that goes on and a lot of processing there that I actually had troubles with. It's trying to load entities for some reason and it's like, why is this loading entities just to output a link field? So I wrote this one just as a lightweight version, and this is way more compatible with what's in Drupal 8 Core. There's also a vast array of date time fields in Drupal 8, which is really great, because people like to have dates, which is, I don't blame them. And really the one module for Drupal 7 to use is the date module. That best corresponds to that functionality. I kind of have a desire to backport the more simplified versions that got into Drupal 8 Core. Well, you know, it's also a matter of time for me, so. So yeah, date modules is great to use for now. All right, so we kind of have a section for developers, too, it'll be very high level. We're not gonna go too much into code. And it's also kind of apical for site builders, too. So I just kind of want to briefly cover this, just to kind of give some tips for how to be a little bit more prepared. I mean, there's lots of other sessions for how to be a better D8 developer out there, too. So this is more like, what can I do in Drupal 7 with my custom modules to be a little bit more forward thinking? So the first thing I want to cover is any external dependencies. If you have libraries that you need to use, that kind of stuff. Composer is the project that's kind of the standard for that. It provides a small, you use a small JSON file to list the projects that you need, and it will download them and then make an auto-generated vendor directory, all that kind of fun stuff, which I'll show on the next slide here. And my personal beef with the Composer project is that's a conductor, not a composer. I filed a pull request on their website to fix that, but they closed it. So yeah, and I should clarify that these libraries that are loaded with Composer are also ones that are called PSR-0 or PSR-4 libraries. So they're libraries that use a standard set by PHP that you can auto-load them. I can kind of show that a little bit in a little bit, but I don't want to get too much into that, but these libraries have to be using this to be able to be used with Composer, so. So kind of a simple example of Composer usage. This is actually taken from a project I last worked on. We had a book site that wanted to, we needed a library to work with ISBN numbers for validation to check if there are proper ISBN that kind of stuff. And there's this great library on GitHub by the author, F-A-L-E, called the ISBN library. And so we put in a sitesallcomposer.json file, and we just put this simple five line JSON file that says we need the 1.xdev version of this library. And then in my sitesall directory, I make sure I have Composer available first, and I run Composer install. And what it does is it downloads that library for me and places it into a sitesallvender directory, and just manages it, downloads, gets all the stuff correctly for me. And the nice thing is it generates an auto-load.php file that I can then reference when I need to use a library like this. So in my install profile, or wherever I need to use it, I just had this next statement, which is like require one strip or root sitesallvender slash auto-load.php. And then I could use this library, like I have demonstrated here, right out of the box. So it was really nice to be able to have that available, and I didn't have to like, I didn't have to use the library's API for this. You know, I just, I didn't have to install a new module for this. I just could refer to my auto-load.php file, and it was ready for me to available, which is really nice to have. There are some modules in Drupal 7. If you don't want to manually include the auto-load.php file, there's a Composer vendor project, which essentially just does the same thing. So if you don't have like control over the install profile or something that's loaded every time on your site, you could use that. But I had control over the install profile, so I could just put that in the module file. And then if you have more of an advanced Composer, like multiple different modules actually using Composer, and you need to kind of bring them all together into one place, I highly recommend the Composer Manager module. It'll like gather all the composer.json files across modules on your site everywhere, merge them into one file, and then download all the dependencies for you, which is actually a really nice way of handling that. And I'm going to guess this gets ported to Drupal 8 as well. It's kind of remains to be seen how modules manage their own dependencies in Drupal 8, so I'm guessing this is how it's gonna happen. So kind of a fun thing to cover for me as a developer, but again, I'll keep it very high level, is like APIs and plugins. So like I have a module that invokes hook that lets other modules say, yes, I wanna do that, and all that kind of good stuff. That's a very basic explanation, and probably not doing it justice. But there's many different ways to do like APIs in Drupal 7, or like this concept of kind of a plugin. You know, there's hooks, like you have a hook info and your module implements the hook info and says, it's my implementation and you run this function when you wanna run me for this plugin kind of thing. Or like I have a settings form and you call this function. And it's very basic and you have something that runs through all the hook infos, that kind of stuff, and runs the functions when it needs to. So that's one way of kind of having an API. There's also C tools plugins, which I never really got into, but a lot of people use these as well. So you like specify a directory for your C tools plugin and register it, and then you have to have an include file to like tell about your class in your C tools plugin, and then you actually have a class file, so you have like three different things just to register this plugin implementation in C tools. And I think we can do better than that. So when I'm writing plugins or like an API in new modules in Drupal 7, or like for a client module, that kind of thing, let me kind of show you what I do. So the really nice thing that Drupal 8 enforces is this kind of standard plugin architecture. So every plugin type, so let's say, I can't think of a good example, a way to get cats, we'll go with that. So we're gonna get a plugin type for how do you get cats? So you'd have this like get cat plugin interface that kind of defines the methods and standards for what all the plugin implementations should be doing. So like we want to have some helper methods and like the main thing is we want a process method. Like we want to process and get the cats. So we have an interface which defines the common functionality that all ones should do. And then we usually write a plugin base. So like kind of just some helper of, all kind of plugins should extend this one class, just kind of out of nicety. So it'd be like the get cat helper plugin base. But you'll notice that it leaves that last function, the process method as abstract, which means anything that extends this class must define this method, which is kind of the nice thing that we do with the base helper. So then if you have your get cat, like let's say it's the drive to the vet or drive to the pound, get cat plugin type. You could define it with an info hook just saying the label is get cat from the vet or get cat from the pound and point to the class name that your plugin corresponds to. In your info file, you of course have to, in Drupal 7 you have to register where all your classes are. Which is kind of a pain, but it just, it works out of the box. So I register where my plugin lives. And then in my plugin file, I have, I'd have get cat from the pound plugin, extends my get cat plugin base. And I implement that process method. And it's just that one method that I need to do since we have the plugin base. And it's, it works out of the box then. So that's kind of a very simple example of how I'd write an API in Drupal 7 now. Cause this will correspond very, very nicely to having an API or a plugin type in Drupal 8. So there we go. So there are some other things that I can just kind of briefly mention here. Ah, this is a fun one. So view modes are a new thing that's kind of hidden in Drupal 7. In Drupal 8, we kind of made this whole UI about display modes. So you can configure or add new display modes. So like default, full and teaser, like the ways that you manage display on a content type, all those sub tabs, those are actually view modes. And you can actually make new ones if you want to in Drupal 8. And a really cool thing in Drupal 8 only is you can manage the way the form is displayed. So you can like reorder form elements and add stuff there. So that's kind of cool. You make like a light form version with a form display mode. But in Drupal 7, you can still manage the display of stuff. Not the forms though. Or you can with other modules, but I'm mostly talking about the display or viewing portion of a content type. So say I have a content that I want to display in kind of like a grid fashion using that views responsive grid. I could use the entity view mode module to add a new view type called like grid item. And then I can configure the display of my content type using the grid item like sub tab on manage display and configure how I wanted to output on a grid item. And the really great thing is that that becomes very reusable. So it's not only I can use that in views, I could as a developer I could call node view, node one with view mode grid item if I wanted to. And it's meant to be a reusable display model for your content. So the entity view mode is the way to add new ones in Drupal 7 and I'd highly recommend that one. So configuration management. I'm gonna get your hopes all up that you'd be able to use configuration management from Drupal 7 that you can do in Drupal 8, but you can't. You can't. There is this kind of configuration module in Drupal 7 that kind of does something like configuration management in Drupal 8. But I would say like it's such an ingrained, baked in system of configuration in Drupal 8 that it's so low level that it's really, really hard to replicate that functionality in Drupal 7. So just I would really still recommend use of features where we're responsibly. You may wanna try this configuration module out. It may be worth it for your site, but there's really not a whole lot you can do for improved configuration management in Drupal 7. Sorry. Another fun one is migrate module is your new best friend. It's your developer's best friend. It's gonna be a really handy tool, especially coming into Drupal 8 because migrate's actually going to be included in Drupal 8 core. So when you're ready to migrate your Drupal 6 to Drupal 8 site, skipping Drupal 7 entirely and ignoring any of the advice I've given right before now, you're gonna be able to use the migrate framework. So it's definitely a great tool for developers to have out of the box. And so there's the migrate framework and the base module and then there's the migrate Drupal to Drupal or D2D, which is kind of what is going into core as well. So I've run several projects with this combination and it works really, really great. So I would highly recommend, if you're looking to do any kind of migrations or porting, that kind of stuff, check this out. It's a great, great tool. West, West full web services. Restful web services. If you have external APIs, like you wanna have a whole API around your site and people that get JSON feeds, that kind of stuff. Typically people have used the services module before but that's actually been having some security issues with that module. So we actually recommend the RestWS or Restful web services module now. So if you need an API in your site or wanna expose that kind of stuff, I would recommend checking out this module. The West full web services module. Translation, that's kind of a big one. Drupal 7 core does ship with a content translation module but what it does is it essentially creates duplicates of your nodes. There's an English version of the node one and then node two is the French version of node one and it gets just kind of hairy having all these duplicates of stuff around in managing that content. So there's a very good standard now set by Drupal 8 core that is readily available in Drupal 7. It's called the entity translation module. So I would definitely be using that. It's really helpful just not for nodes but for any kind of entity types. So comments, users, files, any kind of custom entity types that you have. It's really handy. And kind of one of the problems that people encounter when using this in Drupal 7 is that like how do I translate the node title? Very good question. Because it's not actually a field and C translation usually works on fields and node title is not a field. So there's actually a module called title module that does exactly that. It basically swaps out the internal node title with a field, a text field. And it's not only for nodes but also for other entity types as well like taxonomy terms. The term name can actually be a field now that can be translated which is very, very handy for when you're working with entity translation. So definitely if you're looking for a multilingual site, there are also maybe sessions around this week around multilingual. I wished Gabor the multilingual initiative lead was here but he's not. But these two models really are your go-to start. So the question is do you need to modify any views searching by title? Yes, you probably will because you'll need to search by a field type instead or a field value instead. So yeah. I kind of previously mentioned before in the composer section PSR zero and PSR four. It's this new standard for how to include files. In my plugin example, I showed that you had to register your class name in an info file. Like you had to list it just there. You don't have to do that in any more in Drupal eight. You can just refer to like slash Drupal slash my module and the name of the plugin or class file. And that standard is called PSR zero and PSR four. I don't really encourage the use of that in Drupal seven. I know there's been a couple of blog posts out there to actually recommend using it right now, but I feel like nothing really expects that in Drupal seven right now. So I kind of recommend avoiding it. But if you do want to use it, there's a module called X auto load, which will enable easily all of your modules to have PSR or PSR four support. But again, I'm sorry, I don't recommend it, but it's on the slide. And just a couple of brief mentions too. There's just a lot of great things going into Drupal eight that I would encourage people to start looking at from a developer's perspective. If you can write PHP unit tests for your site, that would be really great. It may not be possible as much in Drupal seven. If you want to start looking at building a symphony app to kind of learn how that goes on, I would recommend that. There's some interesting JavaScript libraries that are in Drupal eight as well, Backbone and underscore. So you may want to be using those. I believe those are used by the navbar module. So check those out. Guzzle is a really interesting one because Drupal had an internal API method for like requesting a URL and getting me back the data. That's now been replaced with an actual external library called guzzle. And this is a good one where, if you wanted to use composer and that composer.json file, this would be a great one for that. You could use guzzle in your project right now. And another just, start using JavaScript local storage or browser local storage, HTML5 local storage in your projects now because Drupal eight is encouraging the use of that a lot more too. And I can't cover all the new stuff without covering the stuff you should stop using because they're gonna be gone in Drupal eight. So there's actually a nice little page for that all the core developers have been working on. Node 2116417 which actually lists all the modules that have been removed from core. So just to kind of give you a brief list of those, it's blog module, the dashboard module. The garland theme, I hope no one's using the garland theme anymore, but that one's, it'll probably live on in contrab. That's okay. The open ID module has been removed from core. It's not very well supported. Overlay was killed. Yay! That's kind of where the nav bar and the escape go back to site functionality was kind of came from a replacement for overlay to get you that context to go back to your site. The PHP filter model is gone. So you can't by default embed PHP in places which is bad, bad, bad, bad, bad. And the pull module, I think we moved it to contrab. The profile module, you should be using fields on users and not the profile module anymore. And the trigger module's probably gonna be replaced by rules. So that's stuff that got removed. And that's really all I had. If you have any questions, feel free to come up to this mic for a little bit with time we have left. Otherwise, thank you. All right, yes, first question. Two quick questions. I'm gonna ask them both at once if that's all right with you. When you talk about breakpoints for responsive pictures, how will that work with or will it work with Zen's handling of responsive images? And the other question is for blocks. When you make custom block types, would you be able to assign separate permissions for different block types? So the first question with responsive images and Zen, I believe you said, I'm not aware of that. So I'd have to look into that. So sorry. The second one, custom block types and permissions around them. I would have to check. I believe the Bean module might support like additional permissions for those things, but it does, okay, thanks Amber. So yes, it does provide permissions for those. Yep, next question. From a future forward perspective with the date module, which storage would you recommend? So that's a good one. Which storage to use with the date module? It provides three different options. There's UNIX timestamp, there's ISO format and like date time, I believe. And I want to say that it's date time that should be used. I will double check and I'll tweet a link if I'm wrong. Okay, all right, next question. Two questions. First one is, given your position at Lullabot, I'm sure you can answer this question. So we're working on developing an API right now. We're just getting started. So there's a steep learning curve for services. We've gotten all the materials to learn about services and now you're saying we should use REST WS instead. Where can I learn about REST WS? I mean, Lullabot. Gotcha, I know there's some resources out there. I can't point to anyone off the top of my head right now. I would definitely start with the project page, the documentation there. If I find a good link, I will tweet it out from my account today. So. And the next thing is right at the beginning, you had a link to, oh, it's up there, or you had a link to your something.io page with the slides. Yeah, it's davery.github.io slash year. Yeah, we went, we couldn't find it. We couldn't find it. Okay, I'll fix that. Oh, whoa, whoa. Okay, I'll fix that. Oh, I typed it wrong on there. Oops. All right, we'll get that fixed. Sorry, thank you for pointing that out. Hello, is Path Auto safe? Is Path Auto safe? I mean, is it okay to, I haven't used Path Auto in my Drupal 7 site just because I'm worried about the transition to EAT? Do you think it is a wise idea to implement it now? See, no, I'm personally insulted if you haven't used Path Auto because I maintain that one. Oh, really? It's totally fine. Okay. Yeah, we're gonna port Path Auto to Drupal 8. It'll continue on to live on. That's wonderful. Yeah, feel free to use it. You just made a lot of people very happy. I want you to know. Thank you so much. Yeah, this may be too large and loaded a question for this session, but what does entity translated content migration look like between Drupal 7 and Drupal 8? So how do you migrate translated content? Yeah. You know, it's really not that hard. The migrate module actually provides an excellent framework to allow you to load in language versions of field values. So as long as you define your source and where it comes from and that kind of stuff, if you're using the content translation version in Drupal 6, it's really easy to migrate into field multilingual values. Great, thank you. I just wanted to ask, did you say that you could migrate from 6 to 8 with the migrate, or did I just want to hear that? No, so with Drupal 8, when the migrate is officially merged into core, you will be able to migrate from Drupal 6 to Drupal 8 because they're gonna provide all the source data you need to know in core. Can you say that again, just so I heard it? You're going to be able to migrate from Drupal 6, not Drupal 5, Drupal 6 into Drupal 8 core. Thanks. So I'm wondering about, with all the changes to entities and view display modes, stuff like that, that if using display suite would cause an issue of designs for upgrade path for that? I'd really encourage the use of just keeping it simple with the view modes and kind of theming your view modes and just kind of keeping it all in that functionality. I'm pretty sure display suite will live on in Drupal 8 as a contrived module, but if you want to kind of look forward to just the baseline Drupal 8 functionality that it provides in the box, I would keep with view modes. So, cool, thank you. All right, I think that's it. Thank you everyone for coming.