 Housekeeping tips. So Ruth, if you'll go to the next screen for me. If you're listening from your computer, we ask that you select mic and speaker audio option. And please wear a headset. It will help everyone to hear things better. Please remain muted during the call. And we ask that you put questions in the Q&A window. We'll be following along with the questions. And Joe will answer them as they come in. So we will get to your questions. We aren't going to be using the audio chat. Also, you'll be receiving a post-webinar survey. So please fill that out for us. It really helps us figure out what kinds of webinars you like, and it will be very good for us. So thank you for that. Next slide, Ruth. Just a little bit about the Drupal Association. We support Drupal.org improvements. We also support Drupal.org hosting, not hot-sing, as the slide shows, but hosting. And then, of course, hopefully most of you have attended our Drupal cons. We have one coming up in June, which I'll talk about in a moment. But we do them all over the world. And they're a great way to network and get education, as far as learning more about Drupal and networking. We also offer community grants. Some of you may or may not know about these. But if you are doing something cool with Drupal in your community, please look into the community grants. Because we do have money available to help support projects. And finally, our global training days, which is a concerted, coordinated effort worldwide, where we will offer an introduction to Drupal on the same day around the world. And so if you are a trainer and would like to participate in that, we can get you more information. Next slide. Coming up, we have Drupalcon Austin, as I mentioned. June 2nd through the 6th. And that's going to be, we're expecting 4,000 people for that. So it's going to be a really amazing conference. And we hope that you can make it. The next Global Training Days is on November 15th. So that's coming right up as well. And I'll be talking about our next webinar at the end of the program. But we do have another one on successful meetups coming up. So we'll be talking about that in a little bit. OK, next slide. And finally, our supporting partner program. If you are not currently a supporting partner, we encourage you to look into that. It helps us fund all of the wonderful things that we are trying to do to help accelerate the project and move Drupal forward. So we hope you will come and play with us in that way. So without further ado, I'm going to turn this over to our presenter. Next slide, Ruth. Joe Schindler. Joe is the senior developer and lead trainer at Lullabot. And he will tell you a little bit more about himself. But he's going to be speaking on getting up to speed with Drupal 8. So Joe, I'm going to turn it over to you. Sounds great. All right. So I'm going to just go ahead and get started with this presentation then. So we're here to talk about getting up to speed on Drupal 8. And as Stephanie said, let's see. There we go. My name is Joe Schindler or EOJTheBrave on IRCDrupal.org, Twitter, pretty much anything internet related, you can find me as EOJTheBrave. I work at Lullabot. And one of my primary things that I do there is work on the Drupalize.me project, where I'm a Drupal trainer. So I spend a lot of time teaching people about Drupal. As such, I've been spending some time recently starting to get up to speed and more time with Drupal 8. I've been involved with it a bit throughout the entire release cycle here and there, not as much as with previous versions of Drupal, but still kind of trying to keep an eye on what's going on and keep my fingers in it a little bit. As a trainer, it's important for me to know about what's going on and being able to understand and talk about those things. So I've been doing a lot of research lately. Drupal 8's right around the corner. I'm going to have to figure out more and more of this stuff so that I can do presentations like this about it. And in the process of doing so, I started discovering a lot of things that I found really exciting about Drupal 8. Some of which I knew existed or were kind of in the pipeline and some of which were totally new to me. Like I'd click on a link and it was like, oh, wow, this is amazing. I had no idea this existed. So in this presentation, I'd like to talk about some of those different things. I find that webinars can always be a little bit weird because you guys don't get to see me and I don't get to see you. So if you want to picture me at the front of the room giving the presentation, you might picture something kind of like this. So what are we going to talk about during this presentation? If you'd like to follow along in the slides, all of the slides for this presentation are available at the URL listed here, including links to the resources that we're going to be talking about and so forth. Drupal 8 is huge and there's a ton of new stuff and it would be impossible for me to cover all of it in a hour-long webinar. So I'm just going to touch on a bunch of the highlights and provide a bunch of links and additional information. So hopefully you can continue to research the things that you find interesting on your own. I'm going to start out with just talking about some of the big picture changes in Drupal. Things that are not really changes to a specific piece of code or a particular piece of functionality, but more philosophy changes and big picture changes. Things that drive what the future versions of Drupal are going to be like. After that, I'm going to talk about changes for sort of the three main categories of people that interact or build sites with Drupal. Those of us who are content authors and site builders, like we use Drupal's user interface to create content types, to author the content that people are viewing on our website and so forth. We'll talk about changes for themers, people who interact with Drupal at the theme level, the changes to how Drupal looks and feels. And finally, some of the big changes for developers or people that are writing their own modules or maybe working on Drupal Core. And then of course at the end, you'll probably be really excited about all these cool new features. So you'll want to know, when do I actually get to make use of this? We'll talk a little bit about that as well. I need to start with a disclaimer though, because we're talking about Drupal 8, which is a product that hasn't been released yet. We don't yet have a 8.0 release of Drupal, which means that things are continuing to evolve. We're still moving towards feature completion. At this point, I think it's safe to say that the majority of the features that are going to be there are already there, but they may change a little bit before we actually get a release of Drupal 8 as bugs are discovered and those bugs are fixed as we discover that maybe it's easier to use this feature by making a couple of tweaks here and there. So just be aware that while I'm showing a bunch of screenshots and code examples, they might not be exactly what we end up with in the end, but they'll be pretty close. So what are some of these big picture changes? I have a handful of these that are actually, there's a few of them listed here, and then there's a few of them that are kind of interspersed throughout the rest of the presentation. I tried to note these with the orange star on the title. The idea with these big picture changes is sometimes we change things about the way that we create the software that influences what we end up creating. So I'll list a few of those here. One of them, and this has actually been true of a number of probably every version of Drupal ever, but Drupal 8 has continued to see this trend of updating and creating improvements to our user interface and our user experience. And like Drupal 7 before it, Drupal 8 makes a lot of leaps towards making the system easier for end users to use. Making it easier for you to discover what's going on and find the things that you need to do. Making it easier to understand when I click this button, what's going to happen. A lot of this is informed by looking at how people have used previous versions of Drupal and watching them interact with the software and learning from the things that they found confusing and trying to improve those as we go forward. There's also actually been some usability testing and studies done both on Drupal 7 and on Drupal 8 that have helped to inform a lot of the decisions about these improvements. So hopefully we're making it more and more accessible and more and more usable with every major version. Another big trend with Drupal 8 development has been the option of HTML5 and looking towards mobile in the future. This is one of those things where all of the experts, not just in the Drupal community, but in the web community in general right now are saying that, oh yeah, it's great that we've got the internet and that a bunch of people have computers and they look at the internet through their browser. But oh man, is there a lot of people coming once we start taking the internet to all of these various mobile devices in the millions of people that are going to be connected now that haven't been before. So in Drupal 5, sorry, in Drupal 8, a lot of work has been going into making Drupal future friendly, applying HTML5 and mobile best practices, improving the core themes and markups so that their HTML5 compliance, adding additional things like phone or date, form elements. These are really helpful for things like a phone where I can navigate to a page that has a form on it. And if the form element is actually a phone number, my phone could be smart enough to pop up the numeric keyboard instead of popping up the alphabet keyboard. Simple things like that that are going to make Drupal a lot easier for people on mobile devices to use. And then a lot of these next generation like enhancements and in future thinking, in order to make Drupal as friendly for the future as possible, it means that we have to start getting rid of some of the cruft from the past. We can no longer support every single browser ever made. To that end, Drupal 8 drops support for Internet Explorer 6 and 7. Though we've also done things like adding the modernizer library to core in order to help facilitate that transition between browsers that don't yet support all of the cool new HTML5 technology, but are ones that people are still using a lot so we want to be able to support them. In general, I would say it's safe to say that Drupal 8 is going to be the most future-friendly and mobile-friendly version of Drupal ever. And I think this is really exciting. It's also really important because in order for Drupal to remain relevant, we have to be prepared for that influx of people who are going to be looking at and using sites owned from mobile devices. Part of being mobile-friendly, and I like to share this just because the screenshots are great, is that Drupal 8 is fully responsive out of the box. All of the themes that come with core are squishy now. You can open it up on your phone and it'll resize to the appropriate viewport size. But it's not just making the content smaller and making things fit on the screen. There's also been a lot of effort put into making sure that things like toolbars continue to work, even when you're on a touch device or a smaller screen. We've even gone so far as to make sure that the administrative screens in Drupal all work on mobile devices, which is really, really cool. I think for the first time ever, you can realistically create a blog post in Drupal from your phone and it'll be a fairly smooth trend or a fairly smooth process and this is exciting. It's also beyond just what's shown on the screen and making things appear the right size and making sure the toolbar works. There's been a lot of work put into things like adapting picture elements so that images in Drupal can be responsive. We can now create image styles that you can click together and create an image style that's aware of the breakpoints that you've configured and can resize images appropriately to fit within those breakpoints. This kind of stuff is really cool. Finally, the last picture item that didn't really fit in with any of the other categories for me was accessibility. And when we talk about accessibility, I think we're talking about a bunch of different aspects of Drupal or making a website accessible. Previous versions of Drupal have always put importance on being accessible, making sure that people with vision impairments or physical disabilities are able to use Drupal as best as we could. I think that that's really come to the forefront in Drupal 8 and a lot of experts in our community have put a lot of time and effort into making sure that this is not only improved but is amazing. I was in Minneapolis about a year ago at the Twin Cities Drupal camp and the University of Minnesota sponsored a accessibility study on Drupal 8 in which we brought in a bunch of Drupal core developers from around the world who wrote up a list of tasks that they would like to see somebody try to accomplish on a Drupal site that had impaired vision. And then they put the Drupal in front of them and asked them to perform these tasks and watched what happens, recorded their thoughts, recorded their actions on the screen and then interviewed them about the process afterwards. And it was really enlightening I think because while we thought we were doing a really good job, we pretty quickly discovered that there were a lot of things we could be doing better. And what was amazing was within that last year, people totally jumped on this and have made so many improvements to the accessibility of Drupal that it's just, I think it's gonna be amazing. So that covers some of my favorite of those like big picture ideas. The next thing I wanted to talk about a little bit was changes for people who interact with Drupal via the user interface. So typically this is either someone who is administering the content of a site, creating new articles, creating blocks maybe, editing existing articles or people who are configuring a site, building views, deciding where blocks are going to be placed on the page, deciding what the content types are going to be and so forth. And on that front, there's a lot of changes that have been made. This is one of those screens that a lot of us only see once or twice during the like entire life cycle of a particular version of Drupal because how many times you end up really installing it. But I like to show this because the installer for Drupal has been completely redesigned. It still does all of the same things but it's got a fresh and up look. It makes use of the new Drupal wordmark and it's just kind of a much cleaner experience. And I bring this up because I think it's indicative of the fact that there's been a lot of thought put into not just the main screens in Drupal, the ones that we see every day, but everything. All of the corners that we maybe only see once or twice in the life cycle of our site, those pages have gotten a lot of thought as well. So the installer and all of that is, it still functions pretty much exactly the same but it looks nicer when you do it. And of course, in addition to trying to clean up all of the dusty little corners, there's been a lot of effort put into the pages that people interact with on a daily basis. Most of us, this is probably the most common page that we experience on a Drupal site, the page where you get to add or edit a piece of content. In Drupal 8, this is, it's not like drastically different than Drupal 7, it's more like iterative improvements on what we had. One of the things that you can see right away looking at this is that there's been a shift of sort of the important parts of the form to the main content region. All of the fields that we've added like title and body and image and so forth. The things that make up the piece of content are right there in the middle, right where I'd expect to find them. And then a lot of that secondary information or metadata has been moved over to a column on the right hand side. This used to be mostly in vertical tabs at the bottom of the page, but it was often hard to differentiate between like, is this metadata and kind of secondary information or is this like the really important thing that I need to fill out in order for this page to exist? And I think that those kind of changes just continue to help improve people's experience creating content with Drupal. In addition to that, like looking at the screenshot, you can see a couple of other neat things on the authoring information section. This is making use of that new HTML5 date form element. So we actually get a calendar for entering in a date for authored by. Seems kind of simple, right? Like, of course you enter dates with the calendar, but in every previous version of Drupal, you would actually have to type out this entire date string manually if you wanted to change the authored by date of a particular piece of content. There's also the, on the top right of the screenshot, it says published up there and then the save and keep published button in the bottom left. There's been a lot of effort put into trying to better explain workflow with a piece of content and what's happening and what the various different states like published or unpublished mean to a content author. I'm particularly excited about the removal of the published checkbox. There's no longer a checkbox that you click and say, hey, this is published. Now you can toggle the state by clicking on the arrow next to the submit action button, which if you were to drop that down would have another option that would say save and unpublish or if this was unpublished, it would say save and publish. And it makes things hopefully more intuitive for users. Yeah, and you probably noticed this too. I wasn't actually skipping that part. I wanted to call it out especially. There is now a whizzy wig or what you see is what you get editor in Drupal Core out of the box. This is again kind of like, oh wow, that's actually great. Like I can select some text and click a button and it turns bold. I'll do that forever. And in reality, you could in Drupal 7, but it involved installing a whole bunch of additional modules in order to get that experience. So Drupal 8 has a whizzy wig editor powered by the CK editor library built in the core. And one of the things that's really cool is because it's part of core, the level of integration with Drupal is absolutely phenomenal. When you're configuring an input filter or a text format for Drupal in Drupal 8, you create a toolbar for people to use when editing a piece of text. And if you drag and drop the bold button into the toolbar, the filter automatically updates to say, it's okay for this piece of text to include strong tags. Things like that are just really great. There's also a special plugin in that we've created for CK editor that allows image handling. So inserting image into the body here, but also with a caption. And you can edit that caption and you can grab the image and the caption and drag it around and those things will always stay together. It's pretty neat. In addition to a whizzy wig editor on the form for creating a piece of content, we also have this concept of in place editing. Also with a whizzy wig editor. What this means is in Drupal 8, I can navigate to a page on my site like say the about page. I don't need to click the edit tab anymore. I can just highlight the thing on the page that I'd like to make edits to. And as an administrator, this little whizzy wig toolbar will pop up and allow me to make edits right in line. There's not even a save button. All I have to do is start typing and make some changes and those changes are automatically saved in the background for me. This I think will make it really easy to make some of those minor tweaks to different pages throughout your site. It's a pretty exciting new feature. Also powered by the CK editor. There's sort of like way too many different changes for me to be able to talk about all of them here. So I'm just kind of highlighting some of my favorites. If you've ever used the screen where you install a module in Drupal before, after you've been at your site for a couple of weeks, there's usually a hundred so modules on this page and you need to find the one that you just installed or you just added to the list so you can enable it. You hit command F in your browser, it pops up to search bar and you start searching and it's pretty much impossible to find the thing that you want to install. Now there's a handy little search bar that you just start typing and it'll filter the list down and you can quickly find and install the modules you're after. Blocks have gotten a lot better in Drupal 8. The concept, a sort of reusable chunk of content that you can place in the sidebars or in different regions on a page, but they're now much easier to understand as a concept. They're also easier to administer. The page for adding blocks to regions no longer has this weird region at the bottom named disabled where there's a bunch of disabled blocks which you then have to move into an actual region. There are now just all listed at the side and you pick from a listful you would like to add. Blocks are fieldable and you can create custom block types with fields added to them. So for example, I can now create a block with an image field and place it into the sidebar and then I can upload image to that block and have it displayed on all of the pages throughout my site. Maybe use it as a quick internal advertisement system or something along those lines. This is really cool for me. This is a feature that years ago I was always trying to figure out how do I get an image into a block like I'll make a block and then I'll embed a node inside of it and that node will have an image field on it and if somebody uploads an image to the right node at the right time, it'll show up in this block in the right place. So it's really exciting to me that I can just do all of that with the blocks now. Another neat thing is if you've ever tried to hide the title of a block you always had to type in this non string and it was this magic string that if you typed it in, the title wouldn't show up. Now you just check a checkbox that says hide the title. No more trying to memorize what these magic strings are. Hey, Joe. We just had a question that relates to this asking can you nest blocks in D8? Sure, so the question is can you nest blocks in D8? I honestly don't know the answer to that. Based on the fact that blocks are now fieldable entities and you can create like an entity reference field that references another entity, I think that in theory that would be possible but I've not actually tried it myself. But if you try it and you find out I would love to know the answer. This one, I feel like unless you've been living under a rock for the last two years this is probably not news to anyone anymore but it's still really exciting. Drupal 8 now contains the views module built in to core. Views is by far the most popular module ever created for Drupal and it allowed us to build lists of things in pretty much every version of Drupal. Now we get it in core which means not only is Drupal a great tool for modeling content but now Drupal core is also a great tool for listing that content. Like with the WYSIWYG editor we also get some benefits of it being in core where there's a much tighter integration between views and the rest of Drupal. A good example of this is Drupal's default front page. You can now edit it because it's just a view. There's no more like, oh, you're only limited to saying 10 things or 20 things appear on the page. You can change any aspect of it just like you would with a regular view. A lot of the content administration screens are also views now. So when you went to the administer content page which would list all the contents on your site with the option to filter it down based on content type and a few other options. That's a view now. So as a site builder, for some reason, say filtering by content type doesn't make sense to the users of my site, I can just get rid of that filter and add the filters that do make sense for people that are using my site. This really increases the flexibility of Drupal's administration screens. So that's a really exciting new feature. For, in addition to that, there's just been a ton of new fields added entity reference, date, link, phone, email. I'm probably missing a few. So in addition to just being able to add text and images, kind of what we were able to do before, we now get all of these. I'm particularly excited about having entity reference be a part of core. So now I can create two different content types that reference one another and create those relationships. These are things that all existed in Drupal 7 as separate contrib modules but have been rolled up and become part of the main Drupal core. And just various other nips and talks to the administration experience, improving it and taking things from Drupal 7 contrib space and adding them to Drupal core. One of the really neat new things is a tour module, which will allow module developers to create tours for their modules. So the first time you install and enable it, you can see a bunch of little boxes pop up on screen that highlight elements of the module and say, yeah, if you click here, this is what it does. And then next over here, this is what this button does, hopefully helping improve the documentation and inline help for not only Drupal core but all of Drupal contrib modules as well. This kind of highlights one of those big picture things. Again, this is true of pretty much every version of Drupal to date, but is worth pointing out. One of the things that major versions of Drupal often do is take the best functionality that was developed in contrib and start to move that into Drupal core. There's a lot of different reasons for doing that, including being able to more tightly integrate with the rest of Drupal, making sure that those things are ready and useful on the day that version of Drupal is released and just bringing more attention to the fact that those tools exist for Drupal. I think that the fact that things like views and some of these more complex field types are in Drupal core will really start to get people that are new to Drupal and haven't had a lot of experience with contrib to realize that Drupal itself is a really, really powerful tool for collecting and modeling data and making lists of that data. So that's sort of a quick summary of some of the things that I found exciting about the user experience or interface changes. Changes for themeers. If your job or where you spend most of your time working with Drupal is in the theme layer, writing HTML, tweaking CSS, changing the look and feel of your site, I think it's safe to say that for you, pretty much everything about Drupal 8 is changing. And that's because as part of Drupal 8, there's now a new template engine. So for the last three versions of Drupal, since Drupal 5, we've had PHP template, which allowed us to create themes for Drupal and print out various variables and dynamically inside of a template. We've seen iterative improvements. Drupal 7 introduced the render API. Maybe an improvement. We've seen changes. Drupal 7 introduced render API and made it possible to accomplish more things through PHP template that we couldn't before. But it also has continued to increase the complexity, making it more and more challenging for people to figure out like, what's going on with this theme and how do all of these things work? So as an attempt to address that problem, we've introduced Twig as the default template engine for Drupal 8. If you're not familiar with it, Twig was created by some sale labs, the same people that created the symphony framework, which we'll talk about more in a few minutes. But it's a simple templating language that's probably more in line with what a lot of other non-Drupal content management systems and frameworks and things like Tumblr and various platforms are using. The hope here is that it simplifies themes, making it easier to discover what's going on and how to create a theme, especially for people that aren't already intimately familiar with Drupal, because hopefully they've seen things in their other experiences working with template engines that are more similar to Twig. We also get a lot of other benefits of using Twig. For example, themes are now way more secure in Drupal 8. I think it's maybe not super common knowledge, but in Drupal 7 and previous versions with PHP template, the theme layer and especially custom themes are like the number one security failure for Drupal-based websites. And I think a large part of that is due to the fact that templates are always handed these variables, which contains some content that you're expected to print out on the page, but it can be really hard for someone that isn't intimately familiar with Drupal to understand whether or not the variable that you're being handed has been escaped and is appropriate to be able to be printed out as HTML or if it contains some JavaScript, then now you're suddenly introducing some cross-site request forgery or other security issue. One of the great things about Twig is that as a themeer, I don't even have to think about that anymore. I just have a variable and I could print it out and if I print it, Twig will take care of that escaping for me in the background, doesn't matter what it is. So that kind of thing is really cool. And then throughout the process of adding Twig as the default template engine, there was I think the side benefit where for the first time in a long time, the entire theme engine and templating layer of Drupal has been rethought kind of all the way back to base level. What should this look like? Not how do we take what we've already got and tack a bunch of other things onto it? And the end effect there is that the system has gotten a lot simpler to understand. There aren't, there's still a lot of complexity to it, but it's not the same and it's certainly not as convoluted with all these crazy callbacks that happen but you're not sure when they're supposed to happen and which one's supposed to happen and in which order. So the entire theme system gets quite a bit easier to understand. Hey, Joe, is there something like panels in D8 is one of the questions? Yeah, so the question is, is there something like panels in D8 for being able to presumably create layouts and that kind of thing? At the moment, there is not. There is not a new layout creator. Some aspects of the display suite module and your ability to configure like the view mode for a piece of content or layout what the form for editing a piece of content looks like have been included, but there isn't yet a panels like tool in Drupal 8. There has been a lot of work in that direction, but my understanding is that it's not there yet and it's kind of on the chopping block, but there's a lot of information about that for sure on Drupal.org. I would recommend checking out the layout initiative. Great, and then just along the theme lines to the question is, was PHP templating then removed or can we still write our templates the old in quotes way? Yeah, as of right now, PHP template is still in Drupal 8. It hasn't been completely removed yet and my guess is that it will continue to be there. Though we'll probably see a scenario where while it's there, pretty much everything gets written in twig or all of the like modern and new themes are written in twig and PHP template eventually just kind of dies a silent death. We saw this with the previous templating engine prior to PHP template where for a while you can do the like XSLT based templates or PHP template, but nobody used the old system because you didn't get all of the benefits out of the new system. That was, this is an example of what a twig template might look like. This is taken from the node template file in the Bartik theme and core. Not too challenging, new syntax. The big thing here for me was there's just, it's not littered with PHP and me having to figure out how to, do I print this variable, do I render this variable? I just put curly braces around the variable and twig will take care of printing it, rendering it if necessary. It's smart enough to figure out all that for me. If this is something that is interesting to you, there are tons of resources about it. There's the official twig documentation. There is a handful of presentations from Drupalcon Prague and other recent conferences that discuss the twig initiative and the inclusion of twig and core in much more detail, talking about the particulars of the syntax and how different elements work and ways that you will be able to convert your existing PHP template theme to twig and what's involved with that and so forth and I encourage you to explore some of these resources. I kind of mentioned this, talking about twig and the simplification of the theme engine in general, just by virtue of the fact that kind of every corner of it was looked at in order to get the twig stuff working. And this has been a big thing in Drupal 8 development as well is just attempting to improve the developer experience. Making it easier for people that are either new to Drupal or just new to Drupal 8 to figure out what's going on, to be able to track the code and understand how the different pieces fit together, to make use of patterns that you've probably heard about or learned about it in other contexts before and in general just trying to reduce the complexity of Drupal. At Drupalcon Prague, this was a really big topic of discussion and I got to participate in a bunch of conversations that were geared towards like Drupal 8 and what we've got now, let's take a look at it and before we have a Drupal 8.0 release, let's make sure that we spend a lot of time making sure that this is as simple or as good as we can get it so that we don't end up with a bunch of just weird for lack of a better word, Drupalisms that are unique to our piece of software that people now need to learn in order to make use of Drupal and trying to improve the developer experience overall. This is one of those things that I think will continue to improve like right up until the last minute, like right up until we get Drupal 8.0 release, we'll still be making changes to help improve that experience. And of course we need to talk about changes for developers. This is again one of those, there are so many different changes with Drupal 8 that it's a little bit of a fire hose and I forgive you if you don't keep up with all of it, but hopefully there's a bunch of resources that you'll be able to follow or take a look at afterwards to learn more about what's going on. For Drupal 8, one of the first things you'll notice is that the requirement for the PHP version has now been bumped from 5.2 to 5.3. I think it's 5.3.10 right now. I don't remember for sure, but you can always look that up on Drupal.org. And the reason for that is that in Drupal 8, we wanted to be able to make use of some of the more modern features of the PHP language that are only part of PHP 5.3 and above, enabling us to implement better object oriented programming patterns throughout Drupal. And actually this is one of those big changes that you'll see a lot of too. A lot of Drupal 8.0 code is now object oriented. It's Drupal 7.0 started to see some of this, but Drupal 8.0 is iterated on that and added more and more object oriented programming patterns. I think some of this stems from the fact that we wanted to include components from Symphony in Drupal 8.0, but a lot of it also just has to do with trying to modernize the architecture of the Drupal platform so that going forward, we can continue to iterate on it and make it awesome. Symphony components are used throughout different places in Drupal 8.0. This is actually really cool. Well, trying to figure out how to modernize the system and make it more powerful and more robust and following sort of standard modern PHP best practices. One of the things that ended up happening was realizing that we didn't really need to reinvent the wheel with a lot of stuff, that the Symphony framework was already doing a lot of things that we needed to be able to do. So rather than rewrite the system on our own, why don't we include some of the components that that community has already created, help that community improve their components, but get to take advantage of them in our software and not have to write all of that from scratch. And so you'll see a lot of this in Drupal 8.0. Different things for routing and sort of some of the lower level things that Drupal has to do, kind of the Drupal kernel, if you will. A lot of that has been replaced by components from Symphony. Not all of the Symphony framework is included, just bits and pieces that made sense to be included in Drupal. One of the things that I hear a lot from people that are sort of first getting started with Drupal 8.0 is always like, Symphony's been included. Does that mean I have to learn Symphony too? Well, maybe eventually, and you'll certainly learn parts of it while writing code for Drupal, but I don't think you need to feel like, oh man, now I have to go off and understand all of Symphony before I can understand how Drupal works. You just need to understand a few pieces here and there. And a lot of it too, because it is such low level things, you just, you create a route that maps a URL to the code that you would like to be executed within your module. And what happens in the background, in a lot of cases, doesn't really make that much difference. I mean, how many times have you really opened the menu.inc file to figure out how the entire routing system for Drupal 7 works? There's also some other changes here. I list YAML for metadata. One of the key places that you'll see this in Drupal is .info files. In a lot of cases, I think maybe all cases actually now have been replaced with YAML files. So rather than using our own sort of hack on the .ini syntax in which we had to improve it so that it could work with arrays as well, now we just make use of a language that was written for specifically doing this kind of thing, creating metadata files. And so you'll see a lot of .info files for themes and modules and other things are converted to YAML now. Hey, Joe. A question we have is, why did they choose YAML over JSON? JSON? Yeah, so the question is, why YAML and not JSON? I don't know all the particulars of that, but I know that there was a lot of discussion back and forth about YAML versus JSON for this kind of thing. And I think ultimately the JSON language or syntax didn't support features that we needed in YAML. And then the symphony routing system which we're making use of for that thing of like mapping a URL to a callback function and so forth. The symphony system uses YAML. So it probably made the most sense for us to make sure that we are using the same thing that they're using if we're going to be using their routing components as well. Dependency injection. I put this in here because this is another one of those terms that you'll hear a lot when people talk about Drupal 8. Oh yeah, dependency injection. It's this new pattern you've got to learn. Dependency injection is, it's a object-oriented programming pattern that allows you to make it so that certain variables within your code aren't hard-coded, that you can have a piece of code that is responsible for querying the database and getting some information. And another piece of code that is, say, responsible for building a list on the page and part of what it needs to do is query the database. It gets a database object, but it doesn't have to care where that object came from, how that object works. It just has to know that this object contains a query method that I can call and when I do so, I'll get data back in this format. Dependency injection allows us to swap out that database object for any other database object or really anything that implements the same interface that signs the same contract of saying, I have these X methods that will return data in these Y formats. This helps to make Drupal more pluggable and it means that it modernizes the architecture of Drupal and makes it possible for us to do things in terms of sort of iterative improvements going forward with potentially even minor versions of Drupal that we weren't able to do before. So like swapping out a dependency for a new one, as long as the API of that dependency stays the same, we can make all kinds of improvements to the underlying code. The link here goes to a really great presentation that does a much better job of explaining this than I'm doing. It also takes an entire hour to explain it, so don't feel bad if you're not getting this within the 15 seconds that we've spent on it. We've also got some other new features in Drupal 8, including annotations being used for discovery. Annotations are one system that is being used in order to alleviate some of the info hooks that are prevalent in Drupal 7. The hooks that generally just return a big array that describes something that your code does. That information is often provided as annotations now. And we finally have true namespaces too as a result of using things like the modern features of PHP. It's now, we don't have this weird scenario where you have to sort of just come up with the appropriate name for your functions in your module based on the module name and some number of underscores and whether it's Thursday or Friday and just name your functions whatever you need them to and use PHP namespaces to ensure that you don't collide with others. Lots of stuff there. I think one of the things that this ends up highlighting is this idea of not invented here. And one of the things that we see a lot of in Drupal 8 is a movement towards collaborating with other projects that are also open source. Some of them PHP, some of them not. That's to operate in a little bubble and write all of our own systems all of the time. Sometimes it makes more sense for us to work with other people who are experts in their system and incorporate those tools into Drupal to make not only Drupal better but to allow us to help them make their tools better as well. CK Editor is a really great example of this. It's a WYSIWYG Editor JavaScript library that's been around for years. It's been through hundreds and hundreds of iterations and improvements in order to get it to the level that it's at today. There's no way that in two years the Drupal Core team could have rewritten or written a library as complete and is tried and tested as CK Editor is. So why not take advantage of the fact that this exists already and that that community is open and willing to allowing us to include it in our software and also willing to work with us to improve their software to make it more useful. And all of us get to sort of reap the benefits. And this has been happening a lot with Drupal 8 that sort of just don't make sense for us to try to maintain our own Drupal specific version of and working with other people who already have versions. And the list here is just a handful of those not invented here libraries that are now sort of being incorporated into Drupal Core so that we can get the best systems. And then kind of adding onto that too is just like pointing out some of the new APIs and tools that you'll get as a module developer for Drupal 8. We briefly touched on symphony-based routes but this replaces the hook menu in Drupal 7 in previous versions which essentially maps a URL to some code that gets executed. Qtn, we now use the symphony routing system to do this which is capable of that like mapping a URL to a callback function but also a whole lot more. There's a great presentation here also from Drupal.con.prog that goes in more in depth about the additional things you can do based on context of a route in order to determine what code to call and so forth. There's the configuration management initiative or CMI for short. Basically, storing your variable data in files instead of in a table in the database, providing a unified API for doing so so that we can end up with a also unified API for exporting this stuff. Meaning that it's really easy to get that variable that you saved in code and deploy it to a different copy of your site elsewhere or to share it with other people. Solving that same problem that Features did for Drupal 7 but because it's part of Drupal Core, it's able to do so at a much lower level and in a much tighter way. We've now got plugins which replace certain hook systems or hook implementations in Drupal. A good example of that is blocks are now plugins. If you've worked with C tools before you've potentially encountered plugins but the idea that your code is encapsulated in a class that Drupal will automatically discover based on naming conventions and annotations and know when to load that class and how to execute the code inside of it. So your code is now more self-contained, which is nice. We've got better tools for both consuming web services and creating web services. Things like the Guzzle library being included in Core make Drupal better at being able to reach out to other APIs and pull in data from those APIs or at least provides us with more tools as a developer to write modules for doing that. And then there's also a REST module in Core. This is part of that whole like mobile, the internet is no longer just something that appears in your web browser. As part of Drupal 8, there's a complete REST API in Core and anything that is an entity like a node or a user blocks and that kind of stuff automatically takes advantage of this REST module and can be serialized and output as JSON. So with the click of just a few buttons and a little configuration, you can serve up the content of your site as JSON data to an app for a phone or to an app for a TV or whatever the case may be. And this is really great. And I think it's another improvement towards ensuring that Drupal will continue to be relevant in this world where the browser is no longer the only way that we access data on the internet. All of this is really built around this principle of basically getting Drupal up to speed with changes that have been taking place in the PHP and web development world over the last like five years or so. Modernizing the underlying architecture that is Drupal, that powers all of our Drupal powered websites so that we can continue to iterate on it and improve it in ways that we haven't been able to before. I don't actually have a link to it here but there is a really great presentation also from Drupal.com Prague about the potential benefits that we'll see from re-architecting Drupal in a object oriented and more modern way, allowing for hopefully more iterative improvements of the software and no longer having to wait for these really, really long two or three year release cycles between versions of Drupal. It's not a guarantee that that's what's going to happen but I think a lot of the idea behind this is making that potentially possible. Again, I can't cover all of these things in the short amount of time. So here's some of my favorite places to go and kind of try to keep a pulse on what's going on with changes, mostly for developers in this case. Drupal.org slash list hyphen changes is probably the best in that it is change logs for all of Drupal core and it's basically anytime a new feature is added or an API is changed, the change log lists essentially. This is what it was in Drupal seven. This is what it now is in Drupal eight. Here's where you can find more documentation about it or if it's a new feature at least. This is what the new feature is. This is why and when you might want to make use of it this is where you can go to find out how to make use of it. So scanning through those can be fun for some definitions of the term fun but I encourage you to take a look at those things. That's great Joe. You know, we just have, we have a few quick questions if we could. So along the theme, themes line, what about jQuery and updating new versions as they become available for our themes? So the question is about, well the question relates to the fact that in say Drupal seven you're tied into one particular version of jQuery the one that ships with Drupal presumably and has that been improved? I don't know for sure what the end result of that was but I know that there was a lot of discussion about the fact that we needed to be able to as we are including more and more external libraries be able to update those at least in like point releases and so forth. So as long as they're not breaking APIs to be able to update the external libraries that we're including and presumably that would also mean jQuery as well. And I know that for Drupal seven it's possible like you can install a module and it'll swap out for a more modern version of the jQuery library than the one that's included with core. I don't actually know if that functionality was included in core itself or not though. Great, okay. And then what Lauren, Lauren Ipsum are you using in the WYSIWYG screen? They say cool. Alan says cool. Oh man, I don't even remember offhand but I will figure that out once we're done. I'm not gonna flip all the way back to that slide to figure it out. Okay, okay. And then just a general question is D8 faster or slower than D7? Yeah, sure. So the question is is Drupal eight faster or slower? Right now Drupal eight is slower than Drupal seven. Out of the box what you get is definitely slower. Is that going to be true when Drupal eight.zero releases? I think it's still hard to say. Right now we're dealing with a bit of a scenario where for the last like two years it's been this free-for-all where everyone gets to say this is a really cool new feature and I really think it should be included in Drupal eight and I'm really excited about it. I'm gonna write all the code for that feature. I'm gonna get it included in Drupal eight. Sweet, it's in Drupal eight. I'm gonna go work on something else now. We're now getting to the phase where it's a bit more of a cleanup and figuring out now that we have all of, let's spend some time optimizing them and making them run quicker, making them more efficient and so forth. So right now, yeah, Drupal eight is a lot slower than Drupal seven for certain tasks. I think that Drupal eight will get a lot faster than it is currently before it gets released. I don't know for sure but my suspicion is is that it won't, it'll always be a little bit slower than Drupal seven but part of that is just the huge number of new features that Drupal eight provides that Drupal seven doesn't. One of my coworkers, Kyle and I were talking about this recently and his analogy or what he said was basically like what you really need to benchmark is Drupal seven plus views, plus features, plus WYSIWYG module, plus picture module, plus breakpoints, plus these other two dozen modules that were included in Drupal core is that faster than Drupal eight. And I think that that kind of, it's maybe not the, it definitely helps you think about kind of what we're dealing with. I would say right now it's slower, it'll get better before we have a release. Ultimately, it will probably still be a little bit slower than Drupal seven but it'll be more pluggable and in theory, you'll be able to swap things out for things that are faster. Great, great. And Ken answered the question about the, Lauren Ibsen, I just put the link in the chat window for everyone. So, yeah, hipsteripsum.me. Oh yeah, that sounds like something I would use. Yeah, so another question. Has the permissions roles changed in D8 and how about the permissions interface? Yeah, not a ton, it hasn't changed a ton. The concept is still the same. You still have roles and you have permissions. There was some talk about the potential for like permissions that inherit other permissions but I don't think that that ended up getting included. Last I looked things on that front were pretty much the same. And yeah, that's probably one of those screens that could definitely use some work and some usability improvements but the functionality I think is still there and still powerful. Great, Joe. And I think this last question here fits right into your next slide which would you care to guess a date for 8.0s, please? No, not really. I thought about this a lot this morning and I was like, someone's gonna ask this question and I'm gonna either have to give a date or I'm gonna have to be really wishy-washy and I'm gonna choose to be a little bit wishy-washy. My best guess is sometime between six months and a year before we see a Drupal 8.0 release. If that's the kind of thing that either scares you or you're like, oh man, why is it taking so long? This last blog post linked on this slide written by XJM does a really good job of explaining kind of why it takes us so long to get a release out. Once we've gone from feature-freeze to an actual release and all of the things that need to happen in order for that to work and that it's slow, it's a lot of work and it takes a while to get there. Which leads nicely into this discussion. You're saying, wow, this sounds really great, Joe. When do I get to use it? When's it gonna be ready? And the answer is, as always with Drupal, well, it'll be ready when it's ready. When it's ready is when the number of critical issues is zero. I don't know what it is at the moment, but that's the kind of thing that you can keep an eye on. As the number of critical issues continues to go down, we'll get closer and closer to release. This blog post that Jess wrote sort of explains that for a long time, while we've been in these testing phases, the number of critical issues has actually been going up just because we're discovering a lot of things that we didn't know before. We now have to address them before we can release Drupal 8. But just recently, it sort of plateaued. And we've been now on a regular basis, fixing as many critical issues as we've been creating. Presumably, it starts to go down after this and eventually gets to zero and we've got a release of Drupal 8.0. Of course, that doesn't necessarily mean everybody should immediately jump over to Drupal 8, stop using Drupal 7, build everything ever in Drupal 8. There's a little bit of that kind of early adopter period, especially with probably 8.0 and 8.1. There'll still be a little bit of ironing things out. There'll probably be a handful of bugs that don't get discovered until after we have an official release. And sort of, I tend to say with this, like it depends on you and it depends on how much you wanna be involved in helping fix and discover some of those bugs. If you're the kind of person that is willing to spend a little bit of time going up, this didn't quite work the way that I thought it would. I'll poke around a little bit until I get it working and then report back to Drupal.org and say why it's not working. Drupal 8.0 is probably great and having those people help out and install that and make use of it is great because we'll start discovering those bugs earlier. If you just need to build a site in a week and have it done and working, Drupal 8.0 is probably not going to be the best choice because there's still gonna be a lot of things in contrib that aren't updated for Drupal 8.0 yet that you may or may not need. It's a really hard one to figure out, but once 8.0 is released, I would encourage you to just not immediately jump ship from Drupal 7.0 and build everything in Drupal 8.0 but on a per project basis, you can sort of assess whether or not Drupal 8.0 is going to be the right fit. Are the tools in 8.0 and those that have been updated in contrib address your needs and what you need. During the Drupal 7.0, when Drupal 7.0 came out, this was talked about a lot too. Like, oh, when do I get to use Drupal 7.0? And I often told people just let the community be your guide. Keep an eye on what other people in the community are doing. And when the vast majority of people start using Drupal 8.0, there's probably a good time to start using Drupal 8.0 too so that you're always kind of using the tools that everyone else is using. Drupal.org has these great usage statistics graphs which show in this case, the various different versions of Drupal Core. And you can see there's the blue line going down is Drupal 6.0 and the brown line going up is Drupal 7.0. And the orange line at the bottom is Drupal 8.0. Actually looked at the stats this morning and Drupal 8.0 usage has actually been going down over the last couple of months. It went from like 75 sites. It's to like, not sure what that means. But what I would like to see before I start building everything in Drupal 8.0 is the Drupal 7.0 line and the Drupal 8.0 line at least starting to go towards one another. That indicates to me that more people are actively adopting and building sites with Drupal 8.0 than Drupal 7.0. Like, sure, Drupal 7.0 is gonna be around for a long time still and people are still gonna make use of it. But once that line starts to go down and the orange line for Drupal 8.0 starts to go up, at that point I would start to say yes, you should probably be using Drupal 8.0 for your projects. And I often use that as sort of a way to just kind of judge and get some idea of where things are at in the community. It typically makes the most sense in an open source community to be using the versions of things that everyone else is also using because then there is a larger pool of people that will be able to help and answer your questions. And if that answer doesn't make you happy and you want Drupal 8.0 right now, you could help get us there faster by getting involved with helping to find and squash bugs and write documentation and all kinds of other things. Check out the Getting Involved documentation on Drupal.org and we always like having additional people helping fix critical issues and get us closer to a release of Drupal 8. So that's what I got. Thank you so much for listening in. Hopefully you learned at least one or two new things and got to see some things that got you excited about what's coming with Drupal 8.0. I think we've got time for a few questions still. So we'll go ahead and do that. Otherwise, if you have questions that don't get answered during the webinar, feel free to tweet at atEOJtheBrave and I'll do my best to answer them. Great, Joe. So just one more. It's not really a question. It's more of a note. Just to note that I'm pretty sure D8 drops support for IE8 as well. Is that accurate? Is that true? I don't know if that's accurate or not actually. It may very well be. Like I said, this stuff changes pretty rapidly and it's still moving in that direction of figuring out what are the requirements going to be. So it wouldn't surprise me that if it did drop support for Drupal 8.0, but I cannot confirm that. Right, I got you. Okay, great. And then just a funny comment. Is there a guest the date pool from Mark Cassius? So that's, yeah, I'm sure. I am sure somebody has one. Yeah, I don't actually, but there's a funny website. It's like DrupalReleaseDate.org or .com that tries to build a graph based on the number of critical issues and so forth and guess based on metrics when Drupal 8.0 is actually going to be released. The funny thing is right now, it actually can't even generate a date. It's like, I have no idea how to process the information that you're giving me. So I can't, as a computer, I don't know how to guess a release date. Yeah, that's great. Joe, thank you so much. This was a really, really powerful webinar. Really appreciate it. You're welcome. Yeah, it was great. And thank you all for listening. Our next upcoming webinar is a successful Drupal Meetup Tips on November 6th. So please join us for that if you are thinking of doing meetups in your area or you're already conducting them and want tips for how to improve them. We'd love for you to join us. And next slide. We have DrupalCon Austin and Global Training Days, as I've mentioned, and coming up. Hope you can make it. And please think about supporting the DA. Next slide, please. We have all kinds of ways to help to support. We offer scholarships, grants. We support the servers that run the programs and we would love for you to become a member. So thank you all so much and hope you have a great week. Bye-bye.