 Welcome everybody. My name is Angie Byron. Thank you for the intro and thank you for the round of applause. That was awesome. If you don't know me, my title within Aquio, which is my company's director of community development, my job is basically to make Drupal awesome. And so I work with Dries, who is the project lead of Drupal. No pressure. And my job is to unblock contributors to make sure that Drupal 8 is getting the love it needs, trying to keep it on track, flying out to places like this and meeting with people who make Drupal happen. So, you know, anything that I can do to help, you know, anything that you're having trouble with in Australia as far as like contributing, if you want to run sprints here, that kind of thing I'd love to speak with you. I'm also a core committer, so I'm one of, I don't know, like six people who can make changes to Drupal. So it's all my fault. Sorry. All right. So what are we doing here today? I'm going to talk a bit about Drupal 8, going through what I call the top eight changes. There's many, many, many changes. We'll walk also through some of the bigger API changes in Drupal 8 for developers. So this will be sort of increasing order of geekiness. So if you're a complete nerd, you know, you might want to check email now. If you're not a nerd, you might want to check email a little later on. So let's talk about the first big change. This is improved authoring experience. And this is something I'm really, really passionate about. The first thing you'll notice when you download Drupal 8 and install it is we've redesigned the content creation form. The first thing you'll find is OMG, there's a WYSIWYG editor. Wow. So you no longer have to type in HTML like it's 1995. So that's pretty cool. And it comes complete with image support and all these kinds of things. Another nice thing is we support drag and drop images. You can just kind of pop things in there and do whatever you need to do, which is really, really handy. We've also reformatted the screen so that you put all of the stuff that you need to fill out on the left-hand side. And some of the sort of ancillary content on the right-hand side, which helps people not get overwhelmed by what's there. So content creation basically works the same as it always did. That's no big surprise. The next thing I can show you is what if you want to change your content? So in Drupal 7, you'll have to go to this backend form that looks nothing like what you see. In Drupal 8, we have this feature called in-place editing. So you can actually just click right on the field that you want to change. It supports all field types. So I'm showing here a text field for the title, a rich text field. But even in something like taxonomy where you can't actually edit it in place, what it'll do is it'll flip and show you the backend form right in the screen. And this is really important for content authors because they get very confused when they try to edit a piece of content and they're taking this form that doesn't look anything like they were just looking at. Has anybody ever tried to preview content in Drupal 7 or below? Yeah, what happens? You see your content twice in your admin theme, which is super helpful. So that's another thing that we've fixed in Drupal 8. So if you go in and do a full edit, so say you want to edit something that is not visible on the screen like the path alias or something like that, you can still go back and do the normal edit form the way you always have. And now when you click preview, what you'll see is you actually see your content as it will appear on your front-end site and you can easily switch between view modes. So if you want to see what that content will look like in a search result or you want to see what that content will look like on the front page, that kind of thing, you can easily flip between those. So lots and lots of work done in the authoring experience of Drupal 8. There's a ton of work here and we're really, really excited to unleash this on the world. The next big thing that we did a lot of work on is the mobile experience of Drupal. Anyway, you try to use Drupal 7, stock Drupal 7 on a cell phone. And how long were you crying? I'm just kidding. It's a little bit ornery because there's tons of great responsive themes and other modules that help with this problem. But by default when you download Drupal 7 and you look at it in a phone, it like crunches the sidebar up into a thing that tastes like a third of your screen size. So one of the things that we've done in Drupal 8 is design a brand new toolbar. It's got icons. Wow, icons. And it'll automatically flip orientation based on the width of the screen. So I can do this for hours. It's so much fun. The other thing you'll notice is it's stretching the image as well. There's responsive images in Drupal so that you don't get a scroll bar that goes back and forth. And this is one of my favorite features. We also have responsive tables in Drupal Core. So as you make the screen skinnier, it'll start dropping out columns so that the table still feels comfortable in the screen. And you can configure this. You basically assign columns a low, medium, or high priority and it'll go from there. Then if we actually look at this on an actual cell phone, or like a simulator cell phone, you can see that's what it looks like on a very small screen. So the toolbar collapses just to icons. You see that everything scrunches down to fit the width of the viewport. And then if I go to an admin table, I'll see only the barest minimum columns that I actually need to see in order to understand what's going on. The other thing that's cool is even features like in-place editing work on a cell phone. So if you click here, you can do quick edit and you get the same interface that you get online. So we spend a lot, a lot of time trying to make sure that mobile is treated as a first class citizen in the Drupal world. Tons and tons of site builder improvements in Drupal 8 as well. I'll go through a couple of the really big ones. Views is in core. Anybody out there is like, what the heck is views? Yes, I know. You have no idea. So if you don't know, it's fine. What views is it's basically a list-o-matic builder. So anytime you can think of a list of content, a sidebar block, a table, a view on the front page, anything like that, those things all get translated into views. A calendar, a slideshow, all of those things. So anytime you have a list of content that actually needs to be, you know, get a list of content and you want to display it in some format, you can actually just click that together in Drupal using the views module. So this being built into core is a really big deal because it means that, you know, you can actually build a pretty sophisticated website just using core for the first time in a very long time. The other thing I really like about it is you see this, like, green glop of crap at the bottom of the screen? Actually, you can click together views and then add a REST export. So you can actually format everything as JSON or whatever thing. And if you don't know what that is, that's fine. We'll talk about it later. But it's very nice, though, because you don't have to hand code any of this. You just click it together and it's done. We also have a better block system in Drupal 8. You're no longer limited to only having one block in one region in one theme. You can put as many instances of a block as you need to. And it also supports adding context into blocks. You can also even make custom blocks just like you can make custom content types. So if you wanted to make, like, say an ad block and you can add fields like the, you know, ad image and the ad code or whatever you need to add, you can build those out just like you would content types and then they're displayed on the sidebars and such. We also added a ton of new field types to Drupal Core. And this is really important when you're building out your data model as, you know, your content modeling, so you can do things like have entity references. Like, if you're a music site and you want an artist that relates to an album that relates to a track, all that stuff is built into Core now. You don't need to download contributed modules for that. There's also dates. There's also link, phone, email, some of those types of things. And they've even made comments into fields. You can actually add comments to comments. All right. Multilingual is another huge improvement. I'm going to play a little video here. So one of the big changes in Drupal 8, there's a few of them. One is that you can actually, from the installation screen, choose a language and it'll automatically download the translation for whatever you choose. You can go through the entire installation process in your native language. Drupal 8's really tried to make multilingual first and we try to show that from the very first installation screen. So you can see here it's showing my Drupal site in Arabic. There's some stuff that isn't translated yet because the strings changed in Drupal 8. And then you can see I can even get errors in Arabic. That's really nice. But it knows to flip the orientation right to left, all this kind of thing. The translations can be automatically updated. The same as you automatically update modules and themes in Drupal 7. There's also just a ton of work to make sure that everything is translatable. So content, blocks, menus, text formats, comments, all this kind of stuff. There's content translation, interface translation, as well as configuration translation, which previously you'd need quite a buttload of modules in order to do. Has anybody built a multilingual site in Drupal 7? Yeah. How many modules did you need for that? Forty. Forty? So, yeah, a lot. So in Drupal 8, you don't need any contributed modules to do multilingual sites. It's all baked in out of the box. There's like three or four modules to enable, but that's just to get you the granularity that you want for whatever your multilingual needs are. Configuration management, this was another really huge change in Drupal 8 that a lot of people are really excited about. So what we're trying to do is make one core system to solve this mess. And the mess being you have a development site and you have a production site. And you want to move your code from development to production. Code is fine. What ends up breaking down is when you want to move any database changes. So it's like the reason people use Drupal is because you can just click stuff and make things happen. That's amazing. But the problem is when you want to move that from one site to the other, it's now in your database. And you don't want to just chuck over your database because you'll lose content on your production site. So people use variable set and variable get. They use update functions. They use C tools, exportables. They use features. All kinds of sort of a collaboration of things in Drupal 7 and below to try and solve this problem. So in Drupal 8, we have a configuration system built in and I'll show you how that works from the UI. For those who hate using UIs for things, it's okay. There's Drush integration as well. So I'm on my dev site and I'm going to go to my configuration, sign information. I'm just going to add a site slogan here, which is I like bananas because who doesn't like bananas? Actually, I met someone yesterday who doesn't like bananas. True story. Anyway, so I'm going to change my site slogan. You see it's there now. Everything looks good. So when I'm ready to deploy my changes, and this works fine for views, content types, lots of other fancier things just in the interest of time. I'm doing something simple here. So I go to my configuration screen. I go to a full important export. And I just do an export of my whole site configuration. What will give me is whoosh, a little... It actually makes that sound. It doesn't. Anyway. It gives me a file that if I expand it, it has a whole bunch of YAML files in it. YAML is sort of a metadata language. So if I look in any of these, it will say, name, colon, value, name, colon, value, and such like that. So basically, all of your configuration changes, instead of me saying that the database can now be transported back and forth in just regular code files that can be managed like anything else. If I go to my production site... Oops. If I go to my production site, there we go. You can tell it's a production site because it's got fabulous production website on it. I can go and I can see I don't have a site slogan there currently. If I go down to my configuration synchronization page, now I go back to full import export, but this time do an import instead of an export. I can actually import that tar file that the other site made. Suspense. Okay. What it'll show me is it'll say, hey, I detected that something in this configuration will allow me to show a diff of those changes. So I can see that I used to not have a site slogan, and now I do have a site slogan. And that's good because if you see something there you don't expect, it's a good thing to abort the mission and not proceed. But everything looks good. So I click the import all function or button. It does a little batch API thing. And then once I come back from that, we're working on performance, by the way. Anyway, ta-da! And I go back to my site. And now I see, there, the site slogan exists. Yeah. Pretty cool, right? Yeah, and this is great because I've even thrown all kinds of things at it. Like, let me create a content type with a bunch of fields and let me create, you know, a view that shows those pieces of content and it handles all that stuff great. One thing it does not do is it does not import and export content, though. Like users, nodes, et cetera. But Lee has a thing. Lee Rollins, you should talk to him after this because he's got a thing to help with that. All right. The sixth change in our... We're starting to get nerdy now in case you couldn't tell. This is twig and HTML5. So in Drupal 7, you used to use something called PHP template. And PHP template was basically just .php files that interspersed PHP and HTML. There were a couple of things bad with that. One was that if you were a front-end designer, you had to learn this ancient language from the, you know, the early 2000s in order to actually make anything happen, right? Because you cannot just use CSS and HTML. You actually have to learn PHP. You have to understand the difference between arrow thingy and brackety thingy. And it's kind of a huge, big mess. So it's also a bunch of... Just asking for security problems because you're saying, oh, I want to print the username here or the bio or something. But what you don't know is some jerk is going to type JavaScript in their bio and then you're going to open yourself up to XSS vulnerabilities and the whole thing. So in Drupal 8, we've switched to the twig framework. And twig is a component made by the same people who make symphony. And we'll talk about that shortly. But what it is, is it's very similar to, I think, Mustache is one of them. Other templating languages that are very common in the front-end world. What you do is you just use HTML and then you use these little special placeholders like brackety percent sign. And so in order to make the changes that you want. And so what this does is it cleanly separates your presentation logic from your business logic. So all the work to do, the work to get a variable on the page happens still in pre-process functions and things like that. And then in the actual template file itself, you only have these sort of metadata characters that don't introduce any security vulnerabilities. Also, all of the variables that are passed through here are automatically escaped. So it's safe to print any variable through twig because we use twig's auto-escaping functionality so to automatically strip out any success vulnerabilities or this kind of a thing. So much better for security, much better for design, first-time designers, that sort of thing. And also we've changed everything that Drupal Core Outposts to semantic HTML5. One of the things I really like about HTML5, in addition to sort of more semantics like you can use like article and section and these kinds of new tags, there's actually HTML5 forms, which are really neat. So we have form API elements for these. So when you say this is a date field, what it'll do is in a user agent that supports sort of special date browsing logic instead of showing you an alphabet keyboard which will be useless for a date, it actually just shows you the, whoa, it shows you the little do-hickies. Do-hickies, that's a technical term. The do-hickies so you can select which date that you mean. And same thing for phone number and same thing for email, show the little at sign on there. So it's a way to expedite data entry for people on sort of crippled devices. Also, this is a very sad thing, right? We're no longer supporting IE6, 7, and 8. So if you're a front-end developer and you're sick and tired of dealing with IE6, 7, and 8, contribute to CORE. Okay. You know, that doesn't mean that your contrib or custom theme can't support it, but CORE no longer worries about these, which has allowed us to rip out a whole bunch of nasty legacy code, which is really nice. Web services. So here's where we talk about what that funny JSON stuff can do. So here I have a Drupal 8 site that's just got some develop-generated content on it. If you never use the develop-generate module, it's awesome when it works in Drupal 8, which it breaks sometimes. So this is a postman. You can use anything else that you want. What I'm doing here is I'm sending a REST request. It's a GET request, and I give it an accept header saying I'm expecting how JSON. And what it'll do is it'll output all this JSON glop, and if I look at it in pretext, you can see all the properties of nodes are there. You know, I have, like, the node type. I have, like, you know, the link to the thing. I have the image, all these kinds of things. And you might be asking, what good is that? That's silly. Well, the good thing is that I can write a mobile application, and this particular one is written in just, like, jQuery mobile, but whatever you want, Angular, et cetera, and Objective-C. And what it does is it will actually ping Drupal out to any view that you've enabled it for, and it will read that content in so you can actually see it in a mobile application, in a mall kiosk, in a Google Glass app, whatever you have to throw at it. So this is something that's really important for making sure that Drupal stays future-proof, because we have no idea what the next crazy device is that people expect to be able to view web pages on. So that's pretty awesome. And then the last thing I wanted to talk about is the move in Drupal 8 to modern object-oriented code. And this is where things are going to get geeky. So if you don't like PHP, I encourage you to check your email, as before mentioned. So what this really represents is this whole movement we've had in Drupal 8, which is what we call getting off the island. And what we mean by that is in the past, you know, largely due to sort of post-traumatic stress disorder from having a vulnerability shared by, like, I don't know, 56 other open-source projects in an XML RPC library in, like, 2006, we decided, screw other people's code, we're going to do it all ourselves, and we're going to do it better than anyone else. And so that's fine if you have very smart people who never burn out and never have kids, and never, et cetera, and can stay there and maintain that code over time. But frequently you do not. And then the problem is that when you work on your code, you're sort of keeping it to yourself. You're not sharing with other people. You're not benefiting from collective knowledge. So what we've done in Drupal 8 is we've adopted a lot of these modern PHP best practices. We've moved the code base to PHP 5.4. That allows us to use some interesting language features, such as traits. We also use classes, interfaces, name spaces, and stuff. And we've used modern design patterns, like dependency injection everywhere. So if you're someone like me, who learned PHP in, like, 2001, you don't know what any of this crap means. And that's fine. But if you used Ruby, or Python, or .NET, or any other language in the world, you know what all of these things mean, because they've been using them for 20 years, and PHP has just been a little slow on the uptake. So this is a really cool thing because it's going to allow Drupal 8 to be a lot more accessible to most programmers. We do have some more to do, though, to bring the old-school PHP people who learned PHP via Drupal. God forbid, there are some of them out there. They're going to have to unlearn a few things and learn the, quote, unquote, proper ways of doing things. But the advantage is, by making that leap, all of a sudden, you're capable of taking the leap to any other framework that you can imagine because Drupal 8 is brought very much more in line with standards across projects. In the C world alone, we see almost everything moving to this kind of thing. So there's a group of frameworks that got together and started making these PSR standards for things like coding standards and how to load classes and how to log errors and all kinds of different things. And by leveraging those standards, Drupal becomes more accessible to other people and we can start to share code with each other, which is really, really awesome. So Drupal 8 has Symphony 2 components under the hood. Symphony is a framework of loosely coupled components. We're using only a couple of them. We're using the HTTP Foundation Library, which if you don't go around viewing bootstrap.inc and hanging around in there, probably doesn't mean anything to you. But if you do, it's different how it bootstraps. And then it also uses the routing component, which is going to change the way you write hook menu, and we'll talk about that in a second. So we have a lot of Symphony 2 under the hood. You don't need to know Symphony or Drupal 8. That's a common misconception. You do need to understand object-oriented programming to use Drupal 8. But there's a lot of great tutorials and examples out there that span all kinds of languages, not just Drupal. I will say, though, if you want to learn Symphony, it's actually pretty cool. There's a really long URL at the bottom of this. I'll post the slides after. And it's a great tutorial by Fabi and the guy who wrote Symphony where it takes you from here's a really insecure piece of PHP that everyone can understand how to write up to how to leverage Symphony components in order to make that secure and flexible and extensible and that kind of thing. So I would encourage you to check it out. So we're using Symphony 2. We're also using dozens of other libraries. We're using PHP Unit, which is very standard across PHP projects. Something called Doctrine to do annotations. Backbone and underscore JS for the front end. Composer, which is sort of the newfangledy way that PHP pulls in external libraries with one another. Guzzle, on, on, on, on. To see who's figured out this problem we're trying to solve the best. If it's us, we keep our code. If it's someone else, we pull in their code. And what you'll end up with is a framework that actually can do almost anything you need to throw at it with sort of the best of breed capability, which is really awesome. So I want to show you a little bit of a peek under the hood and show you some before and after code examples so you can kind of get an idea of what Drupal 8 looks like. Has anybody here started porting Drupal 8 modules already? A few people? That's awesome. So the first thing you'll find in Drupal 8 is there's YAML everywhere. So in Drupal 7 what you would do when you're defining a module is you create an info file and you give it some properties like name and description and so on. The problem with info is it's our own invented thing. It's sort of like INI, but not quite because the way we do arrays is different. So you have to learn this special one-off thing that you only know for Drupal and that it doesn't help you in any other way. They use it in a lot of different frameworks Ruby, Python, etc. And it's basically exactly the same thing. The syntax is slightly different but the advantage is that IDEs know how to parse it, you know, all kinds of things come out of that. So that's cool. We're using YAML. That's pretty non-controversial. You'll also notice that Drupal 8 has classes everywhere. Classes and interfaces and all this kind of stuff. So what used to be all crammed into one file that did 437 different things? That's an exact measurement. I'm just kidding. Now you have a bunch of different class files that are each individually doing one thing. So I'll show you an example. In Hello World in Drupal 7, what you would do is you define a hook menu and you give it a page callback and it can access callback. And then the page callback would basically return whatever the page content was supposed to be. And we call this a Drupalism. This is array PIs. I call them because they're arrays of arrays of arrays of arrays. And you have no idea what's in there. You don't know what's in there. It's expecting, unless you read the documentation. And the documentation for hook menu is like 37 pages printed out. It's crazy because there are so many things. And the only way you know is if someone took the time to document it, they didn't, you basically have to read the source loop and try and figure it out. So Hello World in Drupal 8 looks a little bit different. So you have a path that you define of slash hello, very similar to what you would define in Drupal 7. It's differently named than the keys you define in hook menu, but they serve exactly the same purpose. You tell it who has permission to see this page, and if they get past that check, what should they actually see? And then the link to content that goes over here, that's actually coming back to an example controller.php or some kind of a class file somewhere. And you define a class that defines a method and you print, here's what the page returned. So it's different. In that you're using methods now instead of functions. But from a mental model point of view, it's exactly the same thing. And the advantage of things like a controller-based class is that we can encapsulate all of the logic that's required to make a controller in one place that's documented, that has IDE auto-completion and all that. And you only change the bit of stuff that affects your code. So that's actually really nice. Another Drupalism I'm really excited about. So this is the thing where you look up the block API on api.drupal.org. And it tells you there's 37 functions that make up the block API. And you need to implement four of them, but you don't know which four until you've read all of the documentation or copied and pasted from something else. So this is how you define a block. You define a hook block info and you find a hook block view. And those keys need to match the block API, etc. But basically the API is defined on naming conventions, and if you don't know what to search for, you have no idea what the API is. In Drupal 8, we use interfaces for this. We also use something called annotations, which is interesting. It's sort of like defining your metadata in PHP comments above the class, which kind of makes me go, but the nice thing about it is that the documentation and your class live right next to each other. As opposed to in Drupal 7, what block you're defining is way up here somewhere, and then the actual view function is somewhere else. It keeps everything very close together so it's easier to sort of parse. And then you sort of return a build function just like you would define a hook block view. But the nice thing is the API is already defined, so if you look up this block base, you can see that it's already defined. There's a block form function, block submit, block validate, and build, and you can look and easily see what are the things that you need to implement for your own project. There's a lot, a lot, a lot of API changes in Drupal 8. That was just a very small portion of them. There's a great API reference, so api.drupal.org, you guys would probably know that from Drupal 7. In Drupal 8, we've actually taken some great introductory material, lots of things that are pointers out to other resources, so I encourage you to check that out. If you want to know about every change in Drupal 8, you can go to the API changes record. Every time we change something in Drupal 8, we make one of these little change records that explains what was this before, what is it now, what was the issue that changed that, so you can go back and read the backstory. The top eight improvements in my opinionated viewpoint are improved authoring experience, mobile first, site builder, et cetera, you can read that. There's literally hundreds of other improvements and I've written an e-book on the Acquia site that you can download if you want to learn more about some of the nitty gritty details underneath there. For now, what I want to do is give a shout out to the more than 2,700 people who have contributed to that group of 2,700 in the audience, so I kind of wanted to take a moment just to kind of give a shout out and pat on the back to a few folks. This is not an exhaustive list, but when I looked last night over the list of attendees, I was like, oh dang, that person's here, so there we go. The first person is Lee Rollins. He's based in Bundaberg and probably poorly butchering that, I'm not sure, but all right, cool. So Lee is actually top 20 contributor to Drupal 8. Yeah, more than 350 commits. Shout and Commits is kind of a crappy metric, but nevertheless, Lee is awesome and he's out there doing awesome things all the time. I also really want to call out this thing that he started doing, which is really cool. He started just on Twitter at starting a hashtag patch a day and critical a day. So just, you know, every day he doesn't try to solve an issue, he tries to make progress on some issue and kind of puts it out there and closing an issue on Drupal.org especially could take months, potentially, but doing one little thing to push it forward is something anybody can do. So I really like that helping other people do it. So thanks, Lee. Also in the audience is Ben Doherty or Benji. He's from Perth according to my research. He's doing great things too. He's leading the Migrate and Core initiative. So he's actually working on making sure he's doing a Drupal 7 set. You want to move it to Drupal 8, that there's code paths available for you to do that. He's leading testing efforts on the Drupal 6-8 migration path and everything else. So thanks, Ben. There's also Gibran. Gibran? How do you pronounce your name? Gibran. There we go. Sorry. It's hard. I read more than I talk. He's coming all the way from Pakistan. Also a major contributor to Drupal 8. What I like about Gibran's code is that it's going into someone else's code and reading through it, checking for coding standards, checking to make sure this documentation makes sense, checking to make sure it actually solves a problem it's supposed to solve. And patch reviews are super critical because the one way to really burn out somebody is if they work really hard on something and nobody cares. So if you go out there and you tell them something, even if you think you're being critical, there's nothing more horrible than knowing you've been running the same patch in production for 16 months when you could have just marked the issue RTBC and be in core already. So find issues that need to be reviewed, go help people. It's a great way to learn Drupal. There's also Hussein Abbas. I hope I'm pronouncing that right. Yeah. Hussein hails all the way from Bangalore, India. He's doing a lot of great work evangelizing Drupal 8 and he's also leading sprints with the local Drupal 8 modules and learning more about Drupal 8. I think that's totally fantastic. Brian Gilbert is also in the audience. Yeah. So in addition to being a local organizer here in the Melbourne community, he also mentors others on how to contribute to core. So even though his commit count is not up into the stratosphere, I think if you take it in an aggregate, he probably is responsible for so many commits to core. It's great. So he'll actually sit with you, teach you how to get and the issue cues and stuff. And his company is also sponsoring the contribution sprint on Saturday. So you should all come to that. That'd be really fun. I said Friday. That's because I'm confused about times. That's Saturday. Let me fix that. It's Friday in the US. So if you happen to be in the US or Canada. Okay, there we go. There! See that never happened. Wonderful. Dan Morrison, based in Wellington. Donna told me about this. This is a great story. So I don't know if Dan has any patches in core at all, or if he does, it's maybe a couple. But what Dan did is, along with Haike, these developed this sort of task card and little badges approach. So when you're at a contribution sprint, you have these little task cards to tell you this is how to review a patch. This is how to build a test site. This is how to do things like that. And you get these little badges after you complete a task. It's like, yes, I did something. That's awesome. And this was actually started at Drupal South. I don't know which year. Maybe two years ago. And then we're, they're now part of Drupal Khans. And I believe they'll be at this sprint on Saturday as well. And I think that's really awesome, just finding ways that it's not technical at all to go out and encourage people to get their feet wet in contributing. So that's, that's awesome. And then the last person I wanted to feature was Nick Xu. And Nick, sort of, he got on my radar. He spearheaded the introduction of tour module, which is this great module in Drupal 8 that, you know, shows you contextual help based on the thing that you're doing. We'll sort of lead you through complex interfaces such as views and multilingual and things. And then what he's been doing lately is he's a major contributor to the Drupal CI framework. Drupal CI is his next generation test bot. So every time we upload a patch in the Drupal issue queue, it gets sent off to a test bot that attempts to install Drupal, attempts to run our, like, I don't know, 93,000 automated tests and reports back if anything broke. So he's working on making that system better, stronger, faster, more capable, everything else. So thanks, Nick. All right. And finally, we have answers to all of your burning questions. So these are questions that often come up, so we'll go ahead and cover a few of those. The first one, what about upgrades, right? So if you're currently on Drupal 7, what is the process for upgrading to Drupal 8 and what happens with that? So we don't any longer support an upgrade path from 7 to 8 or major versions. We now do a migration path. So the upgrade path in the past, so let's like Drupal.org is an example. When Drupal.org moved from 6 to 7 a couple of years ago, basically the entire site had to be down for about 19 hours while a script went and made runtime changes to its production database, translating data back and forth, which is a pretty horrifying concept when you think about it. Even if you don't think about it, it's a horrifying concept. So what we do in Drupal 8 now is we offer a migration path. So what you'll do is you build your Drupal 8 site all nice and fluffy and new and with no legacy crap in it whatsoever, and then you run a migrate script, which will go ahead and suck the content from your old Drupal 7 site into your Drupal 8 site. We also supported Drupal 6 to 8 migration path as well, because once Drupal 8 ships, Drupal 6 is going to be end of life after three months. The Drupal 6 to 8 migration is already in, the Drupal 7 to 8 are making changes to the Drupal 8 site. I'm not sure that's at right now, but as I mentioned, Ben is here, so we can go and bug him later. If you have custom code on your site, which most have at least a custom theme, some others have custom modules, you're going to have to port that code yourself. So if you want to minimize the amount of work to move from 7 to 8, you're better off to stick with well-used contributed modules where you can. So if you're using views, that's already in core. You're done. If you're going to do that because everyone needs panels, that sort of thing. So where you can use well-vetted contributed modules, everyone does. If you are in the situation, you need to kickstart your custom porting. We have a project called Drupal Module Upgrader that was sponsored by Acquia and Previous Next, and I'll show you how that works. So what Drupal Module Upgrader, oh, dear, that's not going to work at all, is it? Well, okay. Imagine, if you will, that you can do that. What it's doing is it's a dress script and it has two modes. One is DMU Analyze. And what a DMU Analyze will do, you should be able to see this, boop, is it will pop open a list of all the changes that it can find that you need to make to your code, and it will link those off to the API Change Records. And so it'll show you, it used to be this, now you need to do this. And your first time out porting a module, I would encourage you to only use this in order to make, and you'll understand it a lot better. The second mode it has, I'm going to skip this video because that's going to be useless, the second mode that it has, whoops, the second mode that it has is one that will actually attempt to automatically upgrade your code from Drupal 7 to Drupal 8. And it actually kind of freaking works. It's crazy. It can convert configuration system stuff, menu system stuff, and so on and so on. Actually, I can probably show you the part here later where I actually turn the thing on and find out what happens. Ah, whatever. Anyway, trust me, it works. It's awesome. You should try it. But yeah, so that's going to save you a ton of time of just monkey work and stuff like that. It doesn't do everything, and it has some bugs, and it sometimes needs to be chasing what's happening in Drupal 8, but check out Drupal module upgrade if you have a lot of custom code you need to deal with. Now, if you're stuck on Drupal 7 for a long time, it's great. Drupal 7 is a great CMS. It's wonderful. It's stable. It's been around for years, and almost every feature that I talked about earlier has a Drupal 7 equivalent in contrib that you can use. Everything's lovely. So you can use things like the WYSIWYG is just CK editor. The responsive toolbar is this project called navbar, and so on and so on and so on. These aren't all exactly equivalent with the Drupal 8 release, but you can do it in the ballpark of what you need to get started. Then what happens after Drupal 8? Well, after Drupal 8, we have parties! Yeah! Last time when Drupal 7 came out, we actually had worldwide parties, I want to say, in 127 different countries, people had release parties, and it was a lot of fun. After that, Drupal 6 support gets dropped three months after Drupal 8's release, so if you have a Drupal 6 site, you should at least be looking at Drupal 8 strongly because it's going to be in the next year. We'll see. Also, a new thing that we're doing in Drupal 8, which I'm really excited about, is we're doing feature releases of Drupal 8 every six months. So you know how we put out Drupal 7 in 2011, and it hasn't changed at all since then, other than bug fixes and security updates for the most part? In Drupal 8, we're actually going to be using what's called semantic versioning, and putting out an 8.1.0 and an 8.2.0. Every six months we're going to do media in core in Drupal 8.0, that's okay. We'll probably put it in an 8.2 or 8.3 or something like that when it gets ready. And so that means as a site builder, you get new functionality and capabilities every six months, and they all are done in a backwards compatible way so you don't end up having to recode your site every so often. So that's really, really, really exciting. Drupal 9 doesn't get branched until much later. So after we've had a Drupal 8, we're going to specify a Drupal 9 backwards compatibility breaking release. Then we'll go ahead and branch Drupal 9 and then work on getting that out. But we're probably talking that being 18 to 24 months after Drupal 8 comes out. It's basically after we've exhausted all the awesome crap we can do with the current codebase, we have to work on the next version of the framework. And then Drupal 8 will enter an LTS mode, long-term support mode where we only have to do the same thing after Drupal 9 ships. So pretty cool. When should I start using Drupal 8? That's another question. If you're a modular theme developer and, you know, you don't mind redoing work a couple of times in the interest of learning something, I would actually recommend starting to port your modules and themes now because the APIs are sort of stable enough that you shouldn't have to redo too much of the codebase we still will. But we are trying to avoid that because there's not only people porting modules, there's actually people actually building real Drupal 8 sites at this point as well. If you consider yourself an early adopter, you're comfortable bringing your own bug fixes to the table and doing debugging and working in the core issue queue. You could actually start right now building out basic sites, test sites, that sort of thing. If you consider yourself a late adopter, you're going to want to wait until six plus months after Drupal 8 ships. That's when all the contrib modules are ready that you need, that sort of thing. That would be more of the time you're looking at. If you want a much, much better answer to this question, you should totally go to Jam session which is at 11.45 in room C because he's got a whole 45 minutes where he talks about how you as a business owner or you as a developer can make a smart decision here. Then the last thing that comes up is when it's ready to release. We should start a betting pool. I think someone already did. The answer to that is when it's ready. What does when it's ready mean? We're currently in beta. As of late last night, there are about 54 critical issues left that block release. A critical issue is something that either has security implications, can cause data corruption or otherwise completely hose your site. We need to get those things knocked out so that we can make sure that the partnership, Drupal 8 and everyone uses it. Sorry. It's now 52. Yes! All right. Of these, about 12, possibly 11 or 10 now are D8 upgrade path blocking issues. Right now if you build a site on Drupal 8, every new beta release you essentially are going to have to rip your site down database, but the bottom line is it's kind of like hanky to build Drupal 8 sites right now. So once we get those 12 out of the way, we'll be putting out an upgrade path version of Drupal 8, and from then on, every beta release, you'll run update.php just like you do with Drupal 7, and you'll get the newest changes there as best as we can help that. In that critical issue, there's a bunch of stuff. Performance is by far the biggest chunk, maybe not by far, but it's definitely the biggest. We need to get Drupal 8 down to performing as good or better than Drupal 7, because we can't ship Drupal 8 being slow and clunky, because obviously no one can use it. You need 837 servers to run it if you don't want it to be in that situation. Are you comparing this to D8? Yep. D8 performance plus D7, to D7 and contrib, because D7 stock doesn't have views, doesn't have some of these other functionality. Jim Lears and Fabian X have actually devised a really interesting system to help with this a lot. We have new performance features in Drupal 8, including cache tags, which is a way to identify that this particular cache has a node 1 in it and has a user 3 and so on, so that when you're doing something like posting a comment to node 22, it can be smart about cache invalidation and only invalidate the stuff that doesn't matter anymore. What he's trying to do is take this to the next level and actually do completely contextual caching everywhere. They're actually not that far off, so it's pretty exciting. If they pull that off, that means that we can do really granular per block caching for even authenticated users, not just anonymous users, so in theory, we should be able to get Drupal 8 performance to even better levels than Drupal 7 pretty quickly. If you are a performance head and you want to help with this, we would love your help. You can tag performance and there's tons of issues in there. Security is another area that's left. The gist is, we want to make sure that any publicly identified security issues that are out there, either in contrib modules that moved into core or within Drupal core itself, are all nailed down before we ship that upgrade path beta because the upgrade path they did is our attempt at saying, okay, we think it's ready for early adopters to kind of play around with it. We don't want you running around with public security vulnerabilities, so this covers a range of things. There's some rest stuff in there. There's some entity validation stuff in there, but so various skills are needed, but if you fancy yourself a security person, you want to help, some of this stuff is even just clerical. It's like go through all of the public essays and make sure they either don't affect Drupal 8 or they do and we have an issue for it. And then views is the other big chunk of work left. And a lot of this is sort of the nitty gritty of how views interacts with some of these new subsistence, like the configuration system, with the new entity and field API, things like this. So if you're good at views or you're good at some of those other entity field stuff, that's another area that you could help in a lot. And then there's a bunch of other things. The entity field API itself has a few issues left. A lot of them overlap security. The configuration system has a couple of issues left, mainly around edge cases, around what happens. If you have configuration that depends on a thing, that depends on a thing. Want to make sure we get all that worked out so that people don't end up with data integrity issues on the production sites. We have a few in the fix it or else category. What that means is if we don't fix all the postgres failures, all this SQL lite failures, we're going to end up ripping support for those out of core, which would be really unfortunate because they're really great tests of our database system. Housekeeping, a lot of things that are just like, we want to make sure we're on the latest stable release of all the dependent libraries before we ship. So a lot of those are really good for novices, and go in and just change one line in a gamble file somewhere and then, poof, make a patch. So talk a little bit about how you can help. If you're new to contributing, there's a bunch of things you can do. Lee Rowland has a session right after this one on how to contribute to core without losing your mind. Is that right? Yes. So it's great. It's filled with all kinds of tips and tricks for people who haven't previously contributed to core on how to get a leg up on that, so I'd encourage you to do that. And please come to the Sprint on Saturday as well. If you're not here at the event, we also have what is called core mentoring hours. And twice a week on IRC, people get together and they say, hey, I'm new here. I have some questions, and they'll answer any question you have. But what the heck is get, whatever. No question is too stupid. They're all good questions, and they'll not only answer your questions, help you get up to speed, but they'll also give you issues that are sort of prefabricated and be like, this would be good for a new person to work on. If you don't like talking to people, there's also the novice issue tag. You can just go in and find something that someone has tagged. It's like, this is like a typo fix, or this is some other kind of thing that would be good for new contributors. And we also have a whole bunch of new contributor tasks documented at that URL, and I want to emphasize it's not just coding. There's tons of stuff in there that you can help with. That is, you know, basic English skills required. Some of it is usability testing, lots of different stuff. If you're a more experienced contributor, I would love to have you working on critical issues, if you can. Go to Lee's session as well in the Sprint on Saturday if you've not contributed to core before. You don't have to be an experienced core contributor, but you should know your way around Drupal.org, issue queues, patches, stuff like that. We also have a corollary to mentoring hours, which is core critical hours, which happens every Friday in various time zones. And so if you come on IRC on Friday, Lee goes through prefabs, a few issues I do as well, and we sort of find this critical out of all of the 52 criticals left, looks like it's kind of approachable by people, so let's work on this. Also, I recommend porting modules and themes from Drupal 7 and Drupal 8, try building out Drupal 8 test sites, and tell us what breaks, because honestly, if there is more than 52 critical issues out there, I'd rather find them now than when we're trying to ship a release candidate later. So please test it, tell us what breaks. If you're the kind of person who has more money than time, there's a couple of ways to contribute financially. One is the Drupal Association has the Drupal 8 Accelerate Grant System, and this is where we're literally giving money away to people who have cool ideas on how to make Drupal 8 come out faster, or are key people who are working on some of these critical issues. And so if you're someone who has an idea, like people have submitted focus critical core sprints before, test spot improvements, stuff like that, that's awesome. We would love to hear your ideas and literally give money to you to help Drupal 8 be accelerated. You can also give money to Gradipay, has a Drupal core Git team, and that has a few contributors in it who sort of do, it's the fun their time sort of independently, if you're more into that idea. So I encourage everyone to come one, come all to the contribution sprint on Saturday. Should be tons of stuff for everybody to do. There's documentation sprint happening, there's a core critical sprint happening, and probably migrate stuff, probably Drupal CI stuff, all kinds of stuff. So please come, it'd be awesome to work with you in a more, you know, environment, not where I'm yelling at you from our podium. So I would love to meet you more and work with you. So yes, and thank you very much. So I know I'm standing between you and tea, and I don't think that's a good idea to start between an Australian their tea, but I'm not sure. Do I have a couple? I think we've got time for a couple of questions. We also have a couple of prizes to give away. And then we also, a lot of stuff, want to do a group photograph downstairs. So we've got a, sorry, there's a microphone around somewhere, but I don't actually know where it is for the, other than this one. I think we're going to do repeat the question. Sure, that works. So, all right, do you want me to moderate it? Do you just want to pick some people out? I can't see anything. Okay, so hands up. This is the first hand I see. Go Peter. Hang on. Compatible with Symphony 2.5, Symphony 3 and the PSR7 headers thing. Wait, sorry? Plans for? I'm Canadian and I'm very jet lagged. Symphony compatibility, different versions. Symphony 2.5 and 3 of bringing out the PSR7 HTTP headers thing. Will that be on dribble 8? Straight off. I think something about 70, 2.5 and 3 support HTTP header and PSR7 and PSR7. So, let me answer what I know and then you can tell me if that answers your question or not. Drupal 8.0 is going to ship with Symphony 2.5. And so, that is what we're shipping with. As far as the HTTP header and PSR7 stuff, I mean, if we're using components that leverage those things, then yes, we would be doing that in Drupal Core. I'm hoping someone in the front row here could give you a better answer than that. Symphony 3, we don't currently have plans to use because there's no LTS version of Symphony 3 yet. But once there is, we would talk about possibly putting that into one of those feature releases that I talked about. So, it could be an 8.2 thing if there's a way to make it backwards compatible. One of the things that we're doing, in fact, one of the core critical issues right now is updating our validator logic to use the syntax that's compatible in Symphony 2.5 and above. Because that way, we remain feature compatible, we won't end up breaking people's code in order to move to Symphony 3. So, where possible, we're trying to be very feature-oriented so that we don't end up introducing API changes to leverage more stuff from Symphony 3. But at the moment, we're not planning to ship Drupal 8 on Symphony 3 unless it takes another ridiculous amount of time to ship Drupal 8 and those things end up meeting in the middle. I don't know if that answered your question, though. Yes? All right. One more question and come down to the microphone. Brian, done. I don't think you mentioned it in the slides, but are we going to be expecting API breaks still when we go to nine or and also when the semantic versions are getting released? Is that going to break things or is it going to always be upgrade paths and expect contrips to work? No, that's a good question. So the question is basically like, you know, when can we expect more breaking of things? So from now until when Drupal 8 ships, we should only be breaking APIs where needed to fix critical bugs. So there will be some things coming on the pipe for caching. We're going to introduce new caching stuff in order to address those performance problems. What we really are trying to make a concerted effort to minimize breakages where we can. And when we break, something is for a very good reason. Once Drupal 8.0 ships, 8.0.0, then we are going to try, come hell or high hop water to avoid backwards compatibility API breaks. Now, we can add new features. We can add like a new theme that's optional. You can turn it on if you want. We can add new features that are an optional modules and things like that. We can actually replace whole API systems if we can do it in a performant way, as long as we leave a backwards compatibility layer in. But the idea is once Drupal 8.0 ships, we don't break backwards compatibility. The exception would be once again, if it's a critical issue, for example, if we needed to break APIs in order to solve a security problem, we would do that, but it would be very widely communicated and everyone would grumble, but they would eventually get moved on with that. We have had to do that in the past. I think Drupal 6.2, or something, had to modify a major component of the menu system, so it broke everyone's modules. The hope is we would find any outlying issues like that early, so it would be one of those things where if you waited even till 8.1.0 to build your Drupal 8.0, you'd probably be past the worst of that, I would hope. Drupal 9.0 is going to be exactly the same as a major version change in any other version of Drupal. So Drupal 9.0, you could see things like, you know, instead of using hooks, we used completely, whoa, completely object-oriented event system. You could see us replacing the form API with, you know, whatever crazy thing is down the pipe three years from now, that sort of thing. You could see us completely ripping out the render pipeline and just seeing Drupal 8.0 manifest itself as like a JSON generator and then a completely custom Angular front end that provides the front and the back end. I don't know what Drupal 9.0 is going to do, but I do know that in Drupal 9.0 we'll be free to do what we've always done in Drupal, which is chase the bleeding end of the web, make sure that we're on the most current system possible, and then, you know, people have the choice to continue using Drupal 8.0 until Drupal 10.0 comes out or to make the switch. Does that make sense? Awesome, thank you. Thank you. Everybody, please give Angie.