 So, I assume everyone was at Dries's keynote yesterday, right? The other big man himself. So, Dries was talking about this idea of a push web future in which, you know, more robust websites and systems don't wait for us to come to them, they come to us. Personalization, use for analytics. Building systems that know about us. And that sounds compelling. That sounds like a very interesting world to live in. It also sounds kind of scary. Honestly, I was a bit scared listening to him talk because who was he talking about actually doing that? Facebook, Google, Apple, Amazon. American multinational conglomerates with gazillions of dollars, gazillions of terabytes of data. I don't know if gazillions translates to Spanish very well, but a lot. And how are we going to compete with this? If this push web vision is, in fact, the future, how are we going to compete with them? This push web future cannot be just for large organizations. It cannot be just for the big players with billions of dollars to throw around. But a lot of these things we're talking about, these massive data analytics, the idea of systems that can learn about people and push out data, they require a huge investment. These companies can afford that investment. I can't personally. So how am I going to compete with them? How is a small shop here going to compete with them in building this future web? And if you're just talking about, you should be upfront about what you're doing. Which of these companies has actually been upfront about everything they do with our data? Not a one. Not one. I don't trust any of them to actually be upfront about what they're doing with my data. Because they haven't shown their trust worthy. We need to be able to own our own data. We need to own our own future of the web, even as the web evolves and becomes more complex. So where does that leave the small player? Where does that leave the small shop, the independent? Well, it leaves them with open source. And really, I'm going to go a step further. It leaves us with free software. Subtle but important distinction. The idea that access to these technologies, access to this world is a right. It's not something just for large companies. It's something that belongs to all of us and should belong to all of us. This is our response. This is our pushback on this modern web that is naturally owned by large corporations, by large institutions. Community, working together, is our pushback. Using tools that are designed from the ground up to be shared and to encourage sharing. That is our pushback. That is our weapon against that kind of centralization. In particular, Drupal. Tools like Drupal are how we build that. How we push back and take control of this future web. The right to innovate is not to be restricted to a tiny minority. There's a quote from Free Software Magazine from 2005 in an article on the expansion of open source in Latin America. Open source is how small players thrive. Incidentally, there are Drupal site. Fitting, I think. So who is using Drupal? Well, Megan talked about a lot of institutions, but to show really the breadth of Drupal and just how far Drupal reaches and how it's accessible to so many people, the example I like to go back to is the White House, the head of the US government uses Drupal, as did the Occupy movement. Both using, you cannot find two dissimilar organizations. It's debatable if you can even call Occupy an organization and that's the point. Both of them had access to the exact same tools, the exact same technology. We use Drupal. We, everyone, use Drupal. That's what makes it important. That's what makes Drupal powerful. That's what makes open source powerful. But as Ruiz was talking about, it needs to be approachable. Technology that no one can use is not really useful. Unusable tools are useless. Technology may be great, but easy has to be there. Now, who's heard about Drupal 8, upcoming Drupal 8? Most of the room, okay. For those of you that haven't heard about it yet, you will. Drupal 8, you know, as we've heard, there are a lot of big changes coming in. A lot of huge, big new features. The system requirements are somewhat higher. We talk about collaboration with other systems, dealing with enterprise institutions. It's really big news. Big, big, big, big, big. So does that mean it's only for big sites? Only for big shops? Only for, you know, big consulting firms? You know, like, where's the censure? The only one that's going to be able to work with this? Is it only for large institutions? I've heard this before. I've heard this concern that Drupal's becoming only for the big player. Drupal is only for high-end professionals, and no one else will be able to use it. I disagree. I disagree completely. And I hope you'll agree with me. Because the point of open source is to give everyone big and small access to that same level playing field. Every tool that Drupal makes available to a Fortune 100 company in the U.S. is also available to a one-man shop in Peru, or a one-man shop in India, or a one-man shop in Nigeria. The exact same tools are available to all of them. That's the point. Those same tools are available to everyone. Drupal 8 is a new generation of PHP platform. This is part of the PHP renaissance. We've heard that phrase before, a few people. The entire PHP development community over the past several years has been completely reinventing itself. And Drupal has been a major part of that reinvention. There's no driver in that. Drupal 7 was based on a 15-year-old software architecture. Drupal 8, modern PHP standards approachable by most developers in the world. Drupal 7 was built on the idea that everything is a web page, and you're just serving pages, and that's the entire web. And that made a lot of sense in 2001. It does not make sense in 2015. In Drupal 8, we deal with HTTP. We're actually dealing with the web as it's built, which means we can do a lot more. We have a lot more power, a lot more flexibility to leverage the entirety of what the web stack gives us. Drupal 7, everything was built ourselves. With the exception of maybe jQuery, all the rest of the code in Drupal was built by Drupalers. And that's fine. But there's a lot of really good code out there that we can use. And in Drupal 8, we have done that. There's a lot of Drupal 8 that is not written by Drupal. And that's a good thing. It saved us a ton of time in development. Drupal 7 was a good start for a CMS. But let's be honest, Drupal 7 Core on its own is not useful for building a real site. Drupal 8 is. You'll be able to build actual real production quality sites with Drupal 8 on day one. Actually, on day negative 20 because of release candidates. Start using it then. So what is this benefit? Where are the benefits of this? You consider yourself a site builder, among other things. All right, so most of the room. You can build real sites with just Drupal Core. Drupal 7, there was this great new thing called Field API. Basically, it moved all of CCK into Core and data modeling tools. You know, structured content, kind of a thing. That was one of the big features of Drupal 7. Drupal 8, we just built on that. Entity reference, date, link, email, telephone, couple of other new fields in Core. So you can build a rich data model with just Core. You don't need to wait for these modules to catch up. They're there from the beginning. And of course, you know, what are you going to do with a rich data model? What are you going to throw views at it? Because what else do you do with a rich data model but use views? Views is in Core now. What does this mean? Well, it's still the same views you know and love, but you don't need to wait. There was about a five-six month lag after Drupal 7 came out before anyone started building with it because views wasn't quite there yet. Views is there today. Drupal 8, you can start building real sites immediately. It's not just that it's been packet. Just tossing the module into Core, it wasn't enough. It went through and rebuilt Drupal itself using views. So most of the admin screens you'll see, most of the pre-build functionality in Drupal now, it's not custom one-off code, it's views. You want to customize the admin content page for your site? It's a view. You know how to edit a view. You don't need to override anything. You edit Drupal itself because it's just configuration. And it's awesome. Also note, you've got these edit links here, all these things. This is all core functionality. Use bulk operations at any point. Fair number of people. All of these admin forms are built strictly with core tools, which means you can build anything like this with just core. Drupal 8 gives you content modeling. First grade, top of the line content modeling capabilities. Good content editing, content assembly, content delivery, all of that out of the box from day one for everybody. How much time and money are you going to save on your projects, for your clients, for your companies by not having to deal with all of this other stuff that you have to think about? It's there from the beginning. This is enterprise grade functionality that's needed for high-end sites that is available to your personal blog if you want it. And everyone in between. Configuration management. It's another major new step in Drupal 8 because in past versions of Drupal, mixing content and configuration, the world of pain. Not your head and giggle if you agree. A lot of people have been there, yes. Why is this a problem? Well, we didn't really have a config system. Features is the best we had in Drupal 7. It's not a really good context or a configuration deployment tool because it's not. It was never built for what we're trying to do with it. Drupal 7 didn't really have a configuration system. Drupal 7's configuration system was, here's a database. Enjoy. No, no, no, no. How many hours of your life have you wasted that you will never get back fighting this problem? Hundreds. Too many. I'll just go with too many. How much of your client's money have you wasted fighting with features because we had no better tool? Now, there were ways to work around this to do real solid deployments from a dev site to a staging site to a production site which is what you should be doing for any site of any size, anything larger than your blog, but it was often complicated and took a lot of work to set up. I don't believe that only big enterprise users should have the right to have working configuration. So we've got this new configuration system now. As in, we have one. It's a real system built from the ground up to support the things people do with Drupal. Import and export is built in. So you don't need to worry about whether this thing tie into exportables or not. We need to write a bridge forward. That can work with this. No, all of that is built in from day one. If you use that config system, it just works. Modules can now include default configuration much more easily than in the past. And the database is now a lot leaner. Just content. Your content and your configuration are separate, which means doing real deployment is actually possible. So have a look at what this looks like. This is a little bit of an old video, so some of the UI has changed a bit, but the concept is still the same. You push export, and oh look, here's all of your site's configuration as a whole bunch of files. Human readable, machine readable files. Are you playing? Or are you not playing? You can fix this, and it works a lot better than my slide deck. Moving along. Translation. Who's built a multilingual site? Most of the room. Is this a complete list of the modules all to make it kind of sort of work? No. Someone wrote their own. Here we go. Yeah. Drupal 7 translation is a lot better than most of what's out there, which is kind of sad. And it still didn't do everything we needed. Psy. In Drupal 8, it's been built into the system at a fundamental level all the way down to the base. And it is all in core. You do not need to contribute for it. Everyone can build multilingual sites with Drupal 8 from day one. There we go. So we can import our translations through the UI, but they will also update automatically. There's now a central language server that can push out updates for modules. You want to switch your language around? Great. You can handle right to left and left to right between different languages. And if it can handle Japanese and Hebrew, it can handle Spanish. They're way more complicated. So translation. You can translate things. Including not just content, but you can also use language control what shows up. So in this case, we're going to make this block appear only on the Japanese site. And this takes actually four. This is an older video as well. We added configuration translation. All of that configuration system is translatable. I don't think that was even possible in Drupal 7. Content editors. Our clients, they get a rich editing experience. Who actually likes the out-of-the-box Drupal 7 content edit forms? Who thinks they're pretty? One person. And Chris. We have Wissy Wig in core. But not just any Wissy Wig. Not just your basic WordPress style. We go beyond that. It's automatically configured out-of-the-box from day one with sensible defaults. But you can customize it. The content editing forms have been streamlined as well. So it's not just we slapped the Wissy Wig on it. We actually rethought that entire page. Wish me luck here. So let's go in and create some new content. Create a nice basic page. Title is the same as it always has been. But now we've got this rich text area down here. That's where you can fill in. Configuration is off on the side by default. Instead of having a scroll all the way down to the bottom. So fill in your URL alias. Hide it. We don't even have to scroll to these things. The Wissy Wig, we can still resize it as before. That's just built in. By default, you can bold an italics, make links, make bullet points. You can add things to that. There are ways you can extend that functionality. And I made the super-American mistake, didn't I? I can fix that! Saved! It even works for nodes shown in the view. That's a view on the side there. I'm just going to pop out the content area. What goes to Drupal 8? No. No Nikanda Drupal 8. Hit reload. Everything is saved. Nice and simple. This is a stock install of Drupal 8 that I recorded on Monday. Installed it, so I started pushing buttons. I did no configuration to make that work. That is all there, out of the blocks, for everybody. There's a lot of big, expensive, proprietary CMSs that can't pull that off either. This is available to everybody free. Who turned off overlay? I think that got more applause than correcting the spelling of Columbia. Instead, we have a button. The real purpose of overlay was to say, all right, I want to go to the edit section, but I want to lose where I am on the site. I want to be able to go back to where I am on the site. So now we have in the admin section a button called back to site. We replaced 1,000 lines of ugly JavaScript button. Yeah. Sometimes simple really is better. Accessibility. Very important in the modern web. Drupal to be available to everybody. We're using all of the standard WebAria capabilities. This is the internet standards, the web standards for doing accessibility. We've got those in. Keyboard control is all over the place. And one other thing. Have you ever gotten the sense that Drupal was trying to tell you something? Audio? It's supposed to be getting audio here. Can you hear it from the laptop? Button. Quick edit field body. Button. Editing entity node one. Field body. Do you want to hear it again from the beginning? Drupal 8 and I am now self-aware. Extend content button. Link. Extend structure button. Link. Block layout. List 10 items level two. Close overlay button. Visited link. Quick edit list three items. Quick edit field image button. Quick edit field body button. Editing entity node one. Field body. There we go. What I really like because at DrupalCon San Francisco five years ago we had a speaker come up, Everett Zufeldt, who was himself blind. And he works with Drupal. He worked with Drupal because it was the most accessible system he could find. That is great. He also pointed out though several places where we could be better. And so we took that challenge and improved accessibility even more. Easily the most accessible CMS on the market. Things to note there. That video we were tying into the in-place editor. So you could use that. All of that API is available to developers. All of this is built in an automatic. Out of the box it just works. And in some places this is a legal requirement. Some types of sites you have to build accessible websites. But that's not why we build accessible websites. We do it because it's the right thing to do. Not just to help out disabled users, but to help out all users. Drupal reading your website to you. From your phone. How cool is that? Pretty cool. We also have a new help system built in. It's called Tor. This is something you can maintain yourself in a text file. You don't need to write any JavaScript. You just, in your module or on your site, write a config file with your help text. And it figures this out. Right now I think views is the only thing in core that's using it. I want to see everyone's modules using this system. Individual modules or sites. Documentation for your site. You can provide to your customer. Built in to the site. And maintain it through version control. That's pretty awesome. Honestly, I think this feature gets nowhere near as much press as it needs to. Here's a theme. Right front end code. Decent amount of the room. I've got some good news for you. We get to say goodbye to some old friends. IE6 is dead. IE7 is dead. IE8 is dead. If you have a legacy site where you really need IE8 support, there's a module for that. Because it's Drupal. I don't want to use it. Modern browsers only. What this means is that we can use the full modern web tool chain. HTML5, CSS3, all the fancy new capabilities that replace large swaths of hacks with one line of CSS. It also means everything is responsive out of the box. From day one. All form fields. All page elements. Obviously, your own theme can do something stupid if you want. But Drupal is doing everything it possibly can to make every site in the world responsive. You don't need to replace, you know, use JavaScript for that. You don't need to replace CSS3 capabilities with screwy JavaScript. It just works. Let's have a look at that. We saw this new toolbar before. The old toolbar from Drupal 7 totally didn't work on phones. Anyone ever try it? We got shortcut links. And let's see what happens when we shrink the screen. Oh, there goes the menu. The page is reformatting. Toolbar shortens up. All right, this is just out of the box behavior. And now the toolbar comes down the side. And it's a nice collapsible system. Everything you need is there. You can still get to all of your content, all of your capabilities. Yes, you can plug in new stuff to this menu. Notice, as we have more room, it's going to fill in the whole side, and then it fills in across the top once there's enough room. If you want to stick it on the side all the time, though, you can. Built in out of the box. And that also works on mobile. We've got HTML5 form elements built in. So in this case, we've got a telephone field. And a device that knows what to do with that can pop up the correct keyboard for it. So go ahead and save that. You don't need to deal with switching around and then because it's a telephone field, we know to put the markup around it so that you can make a phone call directly from... Did anyone notice we just edited a node from our phone? How much JavaScript do you think it takes to do this? How much JavaScript do you think we serve by default for Drupal? Anyone have got a guess? Zero? Someone's read the slides. Why? Because modern web browsers don't need this much JavaScript to do cool stuff. It's there if you want JavaScript. The support is still there. Plenty of JavaScript tools available, but you don't need them. And that's great for mobile. That's great for performance. It means for an anonymous user, there is no JavaScript to process from the page loads. Which means on a phone, it's going to be fast. Twig. Someone said yay. This is... I'm not a front-end developer, but I love how Twig came to be. In Drupal 5, core developers said, so we think theme developers who want this as a theming system. And theme developers came back and said, no, no, no, you don't like that. And so in Drupal 6, we said, all right, how about this as a theming system? And front-end developers went, no, no, no, please stop, no. And so in Drupal 7, we said, all right, they want flexibility. Let's give them render arrays to love that. And theme developers said, would you stop that? For Drupal 8, core developers went, all right, all right. Themers, what do you actually want? And themers came back and said, we want Twig. And so our developer said, all right, Twig it is. We actually listened for a change. And great things happen. The team working on Twig, moving Twig into Drupal 8, was the largest team of any of the subgroups working on Drupal. Many of them were themers working on core for the very first time. It's the only code I'm showing. Drupal 8 from Drupal 7, mostly. And if you don't know PHP, you're lost. If you don't know what a render array is, you're lost. If you don't know how a particular render array is structured, you're lost. This sucks. This is now the syntax for Drupal 8. It's the same format used by a dozen other projects. Great documentation available. Great capabilities. Oh, yeah. You can actually get your classes the way you want them to be, and it doesn't require writing 50 lines of PHP. You can do translation directly in your template without calling PHP functions and hoping it all works out in the end. You don't need to think about whether something is an array or not. This is great. Want more information on this? There's a session later today, I believe. Oh, yeah, and one other detail. Compared to the previous leading Drupal, actual divs may vary by custom theme. Offer void on IE6. Drupal 7. Probably heard a lot about the changes under the hood in Drupal 8. The biggest one. We're now requiring a modern, reasonably version of PHP, but not just requiring that version. We envisioned how Drupal works to use modern language. Drupal 7 started requiring PHP 5, but didn't really make use of it. The biggest changes in Drupal 8 are, we're actually using modern PHP. That architecture is built around interfaces. It's built around loose coupling, reusable components, testability. It's built around the idea that you can now hack core without hacking core. Save the kittens. The loose coupling we've done means you can modify Drupal itself without just piling onto it. You can actually swap out pieces of core without hacking core. That's amazing. A lot fewer Drupalisms. A lot less custom Drupal-specific concepts, which means it's a lot easier for developers to pick up. A lot of this comes from the adoption of symphony, not the entire framework, just pieces of it, just components out of this other PHP framework that we're using. It means that we have gotten rid of this not invented here concept. This kind of faulty mindset that if we write something, it's guaranteed to be better than anything else out there. And instead, we've adopted the idea of proudly invented elsewhere. Because who doesn't love Pi? We've got stuff from symphony that we pulled in. We have components from symphonyCMF. The routing system that we're using was a collaboration between Drupal and symphonyCMF. We co-authored this system, and it's now being used by Drupal8, symphonyCMF, and EasyPublish. Drupal developers and our EasyPublish developers. That's pretty cool. ZenFeed, this is for a parsing RSS and AtomFeeds. By the way, Atom, we get that for free now. Drupal7 could only handle RSS and kind of badly. We wanted to replace that. So we said, alright, what's the top RSS and AtomFeed parser in PHP? It's the one from Zen Framework. It has nine dependencies that we don't want. We can't do that. So I went and talked to the leads for the Zen project and said, can you help us out? They said, give us a weekend. We came back after the weekend that had two small dependencies instead of nine. And we said, great! Now we've got AtomSupport just sitting there in Drupal waiting for you to do something with it. Have fun. Using Doctrine for our annotations. We're using Guzzle to replace any HTTP client. So we're making outgoing requests. We're using the best HTTP client in all of PHP right now instead of the mess we wrote in 2003. EasyRDF, twig, you mentioned that. This is all stuff that we are using, that we are benefiting from, that we didn't have to spend time writing. It's not just stuff that we've adopted from elsewhere. Probably the biggest Drupal-specific innovation is the new plug-in system. Who used SQL's plug-ins before? Same concept, but good. And applies all over the place. Learn once, apply everywhere. I love this line. D-Rollins is one of the top core developers. It's all driven on interfaces, which makes it self-documenting. It means if you learn how to use any one of these systems in Drupal 8, it'll take you five minutes to pick up any of the others. You don't need to learn 12 different ways of extending something. They all follow the same pattern. Actions, blocks, text formatters, everything in fields, entity reference, the migration system, rest, everything is using the same model. Entities. We actually have an entity API now in core instead of just half of one. It actually makes sense. It's easier to use. They're actual classed objects. If you're using an IDE, it will help you. It will actually teach you about the system. We can unit test things now, hold this decoupling, which means we can verify our code is correct before it goes to the client and breaks in production, which is kind of important. What are we using for that? We're using PHP unit, the standard tool for unit testing in PHP, which means it's way easier to learn. There's lots of great documentation, and if you're working on another project, it's the exact same tool chain, less for you to learn. We now have a restful pipeline, so we can do non-HDML pages as first-class citizens. We can serve out rest responses and do web services from the beginning. HTML is really just a form of rest. This is not just mobile. People look at this and say, oh, great, now I can build mobile apps to talk to my Drupal site. You can, but don't do that. If you want something on a phone like that, don't build an app, just make a responsive site. What is this useful for? Think content syndication. Think content staging and deployment. There are tools being built for that that work off of this system. Think data archival. Think server-to-server logic. Think client-side customization. Imagine serving a static page and then having a little JavaScript do a callback to customize just one little piece of the page for a user based on a rest request rather than having to have them log in and blow out your cache for the entire page. Huge, huge performance benefits here. Huge personalization benefits here. Huge user tracking benefits here to gather the data you need to build a better site. This is the kind of stuff Rest enables. We have gotten off of our Drupal Island. I remember a couple of years ago I was speaking at Drupal Camp Costa Rica and I was talking to some local shop owners who were telling me that they can't hire experienced PHP developers because they don't want to use Drupal 7. That meant he had to hire only junior developers who were fresh out of school and then train them on Drupal to hire anyone else. Now he can. Now he can hire experienced developers, junior developers, developers who have experience in other projects. Now developers who learn Drupal 8 can work in other projects too. This is good for both the companies and the individuals. This broadens your skill set. This means skills you learn in Drupal 8 will transfer to Symphony, to Sylex, to Zen, to Cake, to Easy Publish. It makes it a lot easier to work on multiple platforms. At Palantir.net where I work, we've started building with Drupal, Symphony, Sylex and Sculpin, all of which are modern PHP projects, all of which use Twig. Three of them use the same core pipeline, the same routing system, the same core logic for how the system works. That means the overhead, for me to switch from a Drupal project to a Symphony project is a lot smaller. It's there, but it's a lot easier. I've talked to a lot of Drupal shops that are saying they're going to be working on Drupal and Symphony. I've also talked to a lot of Symphony shops that have said they've started working on Drupal. They want to become not just a Symphony shop, but a Symphony and Drupal shop. That's great. That's how we solve the labor shortage in Drupal, is make it easier to work with Drupal. This takes a lot of changes. We've talked about a lot of changes under the hood. There's a lot more I could go into. And to be fair, a lot of people are kind of scared about it. Drupal events, there have to be cats on screen. A lot of people are nervous about it. They're very scared about all these changes. But you know what? Almost everyone I've talked to who has started off here afraid of the new stuff from Drupal 8 who has then actually tried to build something with Drupal 8 has actually tried to build a module or port a module with Drupal 8. They love it. They don't want to go back. Drupal 8 is much more pleasant to work with, both from a user standpoint and from a developer standpoint. Before I came here, I was at Sunshine PHP. It's a PHP conference in Miami. And I gave a talk on developing for Drupal 8. And after my talk, Ryan Weaver, who is the documentation lead for Symphony, he's hardcore Symphony guy, came up to me and said, you know what? This sounds so good. I want to try using Drupal as a straight-up framework. This is a Symphony developer who wants to try using Drupal as a framework instead of Symphony. What this means? That's how far we've come. We've got things like the Drupal console. There was a session yesterday. Who was at that session? Yeah. There's amazing new opportunities here. This is built on the Symphony console. Which is, again, third-party components that do a job well better than we could do ourselves. There's co-generation to help ease module development. It can let you introspect your own system. It now ties in, as of about two weeks ago, to the Symphony profiler. So you can get a lot more information about your Drupal site and debug it just from the command line. What made this possible? Well, there's something like 20, 25 people who have written code for this system at some point. But who's the top developers on it? All from Latin America. We're not quite done. We've got a great deal. I want to see every one of you at the sprints on Thursday. You've got mentors on hand that can point you in the direction where you'd be most helpful in getting this out. I also want to see every single person in this room download and test Drupal 8 within the next week. Everyone in here, no matter what your technical level, you can download and test Drupal 8. Find bugs. Or prove that you can't find bugs. I doubt that's going to happen. Find bugs. Give feedback. This is what we want right now. Download Drupal and test it. Get involved. This is what we have built. This is what we have created. This is what we have done for us. Which we do I mean? Who is this we I'm talking about that has made Drupal 8 possible? This is the top core contributors from Latin America. Can we have a round of applause for them? Who is we? We are Drupal Con Bogota. We are Drupal Pichu. We are Drupal Camp Costa Rica. My first Latin American event. Gracias, Ticos. We are Drupal Camp Mumbai in India. Drupal South Wellington, New Zealand. Drupal Con Amsterdam. Drupal Con Austin. And even random PHP conference. Because a lot of the people on this slide, these are speakers from Sunshine PHP, a lot of people on this slide work on symphony, work on guzzle, work on zen, work on tools we're using. These people are Drupal developers and they have never talked to a Drupaler before. That's what collaboration is. That's what source empowers. This is what open source is about. Because now the entire PHP world is our development team. The 80% of the web that runs PHP is our development team and it's our market. How many just code contributors have we had to Drupal 8? Still going? Still going? 2,600. And it may have gone up in the last few days since I last grabbed this number. We are those who are working together. The people in those slides, those are our colleagues. Those are our development team. I haven't met most of them, but they are my colleagues. They are your colleagues. They are our colleagues. They are the community that is building this independent future. In fact, let me ask you. Who in this room has written at least one core patch for Drupal 8 at any point? Stand up. Stand up. Who has reviewed at least one core patch for Drupal 8? Same people, okay. Who has at some point in their career, say standing, posted a module or a patch for a module or reviewed a patch for a module? There we go. Who has at some point worked on documentation, even a small edit? Who has helped someone out in IRC on Stack Overflow, on Stack Exchange, in the Drupal forum? Stand up. Who has answered someone's question in person at any point in their career? Who has built something with Drupal for yourself or for anyone else? This is the Drupal community. Now you can applaud. Drupal is a platform for the independent. Drupal is our answer to the future of the web that we refuse to let be owned by large corporations. We refuse to let be centralized out of our hands. Drupal and Drupal 8 are us saying we will own our future. We will build the best tools we can and they will be available for everyone. All 7 billion people in the world have the right to own their own future on the web. This is what Drupal is about. By all of us saying this belongs to everybody. Drupal 8 is going to kick ass because we are building it together. Gracias. I'm not sure if we have time for questions, I hope so. There's a microphone somewhere I think. Anybody? Come grab it and pass it around. Okay. So you talked about accessibility and is there any API so we can contribute to that access or we can work on that accessibility advantages that Drupal give us? Yes, a lot of it is automatic. A lot of it is just using good semantic markup and adding in additional attributes. A lot of that is just in default templates or in the default logic builds templates. The audio support, a lot of that is automatic but there is a JavaScript API so you can, if you're in a browser that supports it in your JavaScript say this string and the browser will just start saying that string. What do you want to do with that? This guy is the limit. It's not up here today. It's not up here today. Okay. Live translation folks. I would like to know what is the responsive theme based on bootstrap and if it's based on bootstrap when we develop the themes for our customers what labels or what classes we would use CSS, sorry, we would use to customize the themes for our customers. Well, the question is if we use bootstrap or any framework for the responsive part of Drupal 8 and if so there is some kind of framework what kind of tag or classes can we use to make it responsive? Whatever you want. If we use bootstrap I would be integrated in our theme. The responsiveness of an overall theme is the responsibility of the theme and if you're using bootstrap for your theme then that would be controlled by bootstrap. What Drupal 8 has done is all the individual components the form elements, the menu and so forth those are built in a responsive fashion. So making the whole page responsive that's your job and your theme making all the bits and pieces inside it responsive Drupal has already done that for you and I don't think bootstrap would get in the way. I have a question about the multilingual system because which system? Multilanguage management system because questions rise when I was seeing the presentation for example in Europe the European law about a bad tax system has changed so we not only need different language management but we will probably need different bad taxes and everything else rules for different countries and in the European Union only different countries with 20 different tax system. So Drupal Court itself doesn't deal with currency and taxes however Ryan are you here? Ryan's Rama? He's here somewhere Commerce guys who build the Drupal Commerce suites they are working on their Drupal 8 court and they are doing it by spinning off pieces of their system so tax is a good example they are building a standalone tax law library that any PHP project can use they are collaborating with some symphony e-commerce teams on that so when you build sites with Drupal Commerce it will use that library that has all of the crazy, crazy tax law that you need to deal with and that means that's a collaboration with other projects so it's more likely to be up to date it's more likely to be accurate because more eyes are working on it and so forth open source benefits in general so court only deals with the length of the cells, not with the law but that is being worked on for contrib because that's where commerce lives That was my worry that in the European Union we will need not only different languages but different behaviors for country I think you can detect the language of the user but when you need to do different legal things that's totally different from all the wax contrib is going to handle that can you send a bit of the REST API is it being used from the front end in Drupal like the nice inline editing so the REST API in Drupal is any entity you can by setting the right configuration expose that as JSON and then put posts, get and so forth to it I actually I believe the inline editing is using it but I'm not certain of that I know it changed a couple of times during developments I'm not quite sure where it landed at the moment I think so but I'm not going to promise that but I think it's using no it's not because REST is a separate module so it's doing something parallel to it which is fine because the system can support that so I'm not quite sure the details under the hood for it is that easy to add like OAuth or something like that to the REST API OAuth is already being worked on in contrib and I think the module is there already I haven't tried it but yes OAuth is absolutely something we want to exist it's going to be in contrib but work is already mostly there I'm kind of new in Drupal welcome I'm a developer I'm trying Drupal 7 now the hardest part is the module dependency for example when I try to install a module I have to look in the local side and it's a little bit hard I was expecting something like we have the maven that you declare a dependency in the module automatically the build can download the dependency for you do you have something like that if you use Drush to install modules from the command line I believe it does that for you already and it will do that in Drupal 7 and it will still do that in Drupal 8 hello now we have beta 6 we can start with clients with new projects it's time or not time there are people building production sites in Drupal 6 into Drupal 8 hope not Drupal 6 but with Drupal 8 my recommendation wait for beta to beta upgrade support Dries was talking about that yesterday that's not quite there yet I would wait for that and then if you want to be aggressive you want to be experimental start building stuff with betas but be aware something maybe a bit bumpy as you try and upgrade it release candidate is when I really start looking at it in earnest once the release candidate is out or is about to come out if you have a smaller site that's not going to be as dependent on contrib try it see what happens you probably can pull it off then this is a small site I think this is a we tell to the client this is a new one system and advertise to the client I'm sorry we need to tell to the client that we are using a beta be honest with your clients absolutely at Palantir we built a few Drupal 7 sites in beta and release candidates and there were some bumpy pieces to it some contrib that wasn't there or contrib that had api breaks after that because they were alpha contribs but it worked and we were very honest with the client about that so when in doubt be honest good advice ok