 All right, let's get started. Does everyone understand me? Should I talk louder? Okay, all right. So, welcome. This is the Drupal 8 for site builder session, first session of DrupalCon after the keynote, of course. A little bit about me. My name is Christof. If you want to pronounce that in Dutch, it's Christof de Jaag, but I'm fine with Christof. I'm also fine with Swento, which is my handle on Twitter, also on Drupal.org. I'm a Drupal Android developer and the things that I do within the Drupal projects, I'm a Drupal core co-maintainer for a field API, and I'm also an elite maintainer for this PlaySuite and various other modules. Currently, I'm in between jobs. I'm trying to make a record. I have no idea when the record will be released. I guess it's the same like we say with Drupal. It will be released when it is ready. So, I'm going to talk about Drees's dream and of course all the big improvements that we have done in Drupal 8. Some little gems, those little things that really make site building really awesome. Also, talk a little bit how Contrip is doing and then some time for questions and answers at the end. So, let's start with Drees's dream. So, what is Drees's dream? Drees's dream is, if my pointer is working, to eliminate the middle man. So, what is he saying? There is no reason open source software should be limited to technical users. When was the last time you hired a webmaster to handcraft your website and content using XHTML and CSS? So, I highlighted content. If I think about my own career, I mean like 12 years ago, clients used to just send me some word documents and I just copy pasted content into HTML files and then I just maintain a lot of HTML files, put them on a server and that was it. At some point, CMSs came up and clients were able to manage their own content, which is kind of interesting. So, he also wants to get rid of the developer, which is kind of scary because I'm a developer and I want to actually keep my job. And the way that he envisions that is he wants to change the developer's role. Maybe eliminating is a bit too strong, but at least try to redefine the role. And the way that we accomplish that within Drupal is actually the way that we have been doing for the last 10 years, actually. We create modules and with those modules, everyone is actually able to create websites without any programming language, which is what it's all about. And this is not something recent. Jesus has been talking about this for a very long time. This is from an interview that has been done in 2009. So, after the developer, he also wants to get rid of the designer, which is kind of weird, I think. We have something in core that might get rid of the designer, which is, it doesn't work. Sorry about that. Okay, the caller module. I'm not sure whether that will replace the designer. I'm pretty sure it won't. So, after we eliminate everyone, who is left? Robert Douglas had a really interesting answer on that. Eliminate the webmaster, programmers and designer who is left to the core maintainers. This is actually Jesus' plan. He wants to get everyone involved working on the project so that we actually keep our job in some ways. And that's actually what we have been doing with every release of Drupal. We add more power. There is new technology. We use that new technology. We move a lot of country modules to core because we see that they are popular or they fulfill some kind of need, like, say, for instance, views. Country developers become core developers and eventually some become core maintainers, which is kind of cool. So, just to make sure, if you're a developer, don't worry. We have done a lot. So, let's do a little quiz. How many lines of code do we have in Drupal 1.0? I would say, shout something, 3,000. Higher, lower, 5,000. So, actually, not that far away. It's 4,092. So, that's Drupal 1.0, which is not a lot. If you would open up, I think, bootstrap.inc file in Drupal 8 right now, that's more than 4,000 lines. So, fast forward to Drupal 8. How many lines of code do we have in Drupal 8 at this very moment? Shout something. 400? More? A little bit more, or? It's 500,000 lines of code, which is pretty much. I use some kind of tool to identify all the languages that we use. I don't think the tool is actually completely right, because it's also finding some Pascal in Drupal. I'm pretty sure we don't use Pascal. But even though there's a lot of code, this also includes all the libraries that we have been pulling in in Drupal 8 right now, things like Symphony, Guzzle, PHP unit, things like that. But that's it. We use a lot of code, and the developer will not die like designers won't die either, but we need a lot of more people to get involved. So, let's talk about the big improvements in Drupal 8. So, the biggest one, obviously, is views. And there's an interesting thing about views. This is a graph, and the blue line is the Drupal 6 report and installations. The brown line is the report and installations of Drupal 7. So, there's some dates on there. In January 2011, we released Drupal 7. And basically, for six months, nothing happened. So, we bust our ass for three years, and nobody is using Drupal 7, which is kind of annoying, in a way. And we see that around February 2012, we finally passed the report and installations. So, it takes a year for every release to become, like, more or less popular. There are two more important dates that are missing at this point. That is the release candidate of views 1.1 in November 2011. Now, you might say this doesn't really matter. There's another date that is really important, and it is June 17, 2011, which marks views release candidate number 1. At that point, we see that Drupal 7 is starting to be used. Why views is such a popular model, it's such powerful, and everyone basically uses it. So, within the Drupal 7 cycle, views was not ready when we released. So, people didn't really started using Drupal 7. So, we had to wait. So, in terms of adoption rate, moving views into core was a really interesting decision, because we see that everyone uses it. So, let's put it in core. So, when we release Drupal 8, hopefully, adoption rate will start faster. There's a really nice quote from Daniel Wiener, who says, Ladies and gentlemen, you can now use Drupal 7, and that is effectively at the release, views 1.0 release. That's effectively true. And a year later, he actually said, you can now start to use Drupal 8. That's a year later after views was moved into core. I would say, one side thing, do not start using Drupal 8 in production. It's not ready yet. But that's a general feeling. People are waiting for country modules or things to be ready to start using Drupal core. Now, there's another thing that is really important in terms of Drupal. We don't maintain backwards compatibility. So, if you would wait to port modules when Drupal core is released, then especially in the case of views, they would probably be busy for at least another year and a half, maybe two years, maybe that's an understatement, because views is so huge, it's so complex, and we've been doing so much changes in Drupal core that basically nobody would be using it. And also, it's a fantastic battle tester. We have so much new stuff, things like configuration management, plugins, annotations, dependency injection, routing system. Basically, everything that is new, especially technically in Drupal 8, views is using that. And if views works, we more or less can say, okay, Drupal 8 is not necessarily stable, but it does its jobs pretty much fine. So, fantastic battle tester. Every time something goes wrong in Drupal 8, we usually fix it somewhere within views and then we're done. Well, done is a great word, but that's it. So, does anyone remember views one? This is during the Drupal 5 area. It was kind of interesting, there were a lot of field sets. It did a job fine, actually. One of my favorite ones was if you had to reorder fields, you had to push on those little arrows, it worked. So, we didn't put that into Drupal 8 core, don't worry. We've moved something much nicer, which is basically the views tree with some modifications, of course. So, few ships with some things in core. We shipped with the default front page, which means that, for instance, the node callback, that doesn't exist anymore. So, if you want a front page, you can go to views, enable it, which is also interesting because usually when there is a new Drupal release, the first thing that I usually do is go to the website, go to slash node and see whether people have protected it or to see what they have done with it, or sometimes nothing, it depends. So, front page, it's now shipped with Drupal 8. We now also use views for content management. It's the default view, you can add new columns, you can also add new operations. So, the basic concept of views bulk operations has been moved into core, really great stuff. We finally have an overview of all the files that are used in core, which is kind of, yeah, I mean, normal to have that. I mean, you finally have an overview which file is used in what place. So, uses in core, that's really great. We can say goodbye to a lot of stuff in Contrip. We can say goodbye to views as a Contrip module, of course. Views bulk operations is partly in core. The API is a little bit different. I actually need to talk to Boyan Zivanovich how much different it is, but still is there other stuff like views, watchdog, admin views. So, basically the content overview, the user overview are now views. I think we are also in the process of changing the comment overview. So, basically everything is handled by views. And also, large parts of Ctools have been moved into core, things like plugins, things like exportables, drop buttons, dialogue, everything from the Ctools module, which is kind of popular because every module in triple seven more or less requires it, that's in core right now. So, really, really great stuff. So, besides views, another great thing is field API. And I have to say, our idea about the triple eight cycle for field API was actually to go on vacation. Well, we were happy. I mean, field API is in core. You can attach fields to your entities. We have basic fields like images, files, things like that. So, we were like, okay, you guys can all do your stuff. We will fix some bugs here and there. But our core, my colleague core developers basically did something else. They rewrote all the things. And that's kind of annoying. There's so much new stuff in triple eight. There is dependency injection. There's constraints, plugins. What else do we have? We have a new entity API. And my thing is working, sorry. We use object oriented code all over the place. We use namespaces, which is kind of cool. We have this thing called configuration management initiative. And we also wanted to move away from field storage to entity based storage. So, we had to do a lot of stuff. And also, which is really interesting. It's the third time that we have been rewriting Field API. A little bit of history. During Drupal 47 and Drupal 5, there was a new module called cck. And actually, before that, we had a module called FlexiNode, which also allowed you to create new content types and attach fields. For some reason, cck became more popular. And during the Drupal 6 cycle, when Dries makes his new wish list, he was like, okay, let's put cck into core. So, it was renamed to Field API. So, that was the second time. And now we basically had to rewrite it again. But a lot of exciting stuff have happened there. We've added a lot of new field types, things like entity reference, which allows you to reference basically everything in your website. We have a date field. You can finally create event websites, for instance. There's a link field. Email, what the stuff? We have a telephone field. If you watched the keynote from Dries, powerful stuff that we can do right now. We have a picture field, which is kind of a weird one. The picture field uses the picture element, which is actually not validated yet, but we are Drupal. So, we do stuff that doesn't, yeah. Well, it exists, but it's still not valid yet. What it does, it allows you to select different image styles depending on the viewport. So, if you're looking on a, let's say, mobile phone, the picture element will select, like say, the small image style. If you look at on a desktop, it will use the large image style. So, we have responsive images in core, basically. Really great thing. And user picture is finally a field. User picture, before that, was just a annoying thing, which was horrible. It was useless. You couldn't do anything useful with that. It's a field. It can have four matters. It can be fantastic. So, a lot of new field types. We've done a lot on field UI as well. We finally have a UI in core that allows us to create new view modes, and also four modes, which is completely new, which I will talk about in a couple of minutes. We have placeholders, which allows you to put a little text, let's say, in a text field, for some guidance. So, let's say, please enter your name here. If you click on it, that will disappear and you just can start typing. We have custom cardinality, which was a pain for a lot of people. In Philips, you were only allowed to either select unlimited items or from one to 10. You can now finally have, let's say, 45 items if you want to. Doesn't really matter. Field prefix can be renamed. And one thing that is important regarding to field UI and the way that you are using or reusing fields, fields cannot be used anymore across entity types, which means that if you have a body field, or let's say an image field, you can still reuse that on different content types, but you cannot reuse that same field on, let's say, comments or taxonomy, which means you will have to create them at twice. So you can have a field called image on, let's say, your content types and also the same name on vocabularies. This is for entity-based storage. It's a really technical thing, but it's for the best, trust me. So we have view and form modes. We have now a UI in core to create new view modes. It only took us three issues and a lot of bike shedding. If you look at UI, it's just a label and a machine name. I still don't understand why we've used three issues for that, but it ingrates perfectly with views and it also works on the form side. And what it means, if you look at field UI, you have a region on manage display which allows you to hide fields. We basically mimic that for forms as well. So on forms, you used to have manage fields and in that place you would add new fields, reuse new fields and also change the order. You have a new tab which is called manage form display which just allows you to hide some fields. There's a really interesting use case for that. That's user register. So in Drupal Core we ship with two form modes for the user. It's default and register, which means that you can now finally stop doing form alters in code if you want to move out some fields or add some fields and things like that. And I wanted to show you that in a little video. So how, is it, oh, sorry, does it start? Okay, so this is the user registration page. There's a couple of fields that have been added there and my video stopped for some opening. Okay, I can see it. Okay, I'll have to do it like this a little. So you have manage display, you have manage form display. So what you can do on manage form display, it's basically the same as manage display and you see all the fields. So this is default and then we can go to register. I'm also going to quickly show you the interface. You can create new form modes but the only use case for core at this point is the user registration page. So at this point we'll go to register and remove some. I should have made my videos a little bit faster, I think. Sorry about that. But it's just so fun to play around with it. So we just move stuff around, which is really fantastic. You click on save and then if we're going to go back to our user registration page and reload, those fields will be gone. So that's the basic concept. Let me go back here. I'll probably have to do this again after with another video, I might take a mic over there. So really interesting and powerful stuff. In Contrip probably a module, for instance, like inline entity form will make much use of this because if you use inline entity form, you get the same complete node form inside another node form, which is kind of a pain. That will be much smoother right now. So we can say goodbye in Contrip to a lot of modules, all the field type modules that I've listed, entity reference, link, email, whatever, they're all in core. Some parts might still be in Contrip, for instance, the date module. Not everything from the date module has been moved into core, so things like recurring dates will still be handled in a Contrip module. References module is also a module which was basically the successor of entity, oh, sorry, of user reference and node reference from CCK, which was already replaced by entity reference basically. The views modes module, which allowed you to create new view modes and form modes. Parts of the space suite, which also allowed you to create new view modes. And basically all hidden field widget modules. I think there are around seven or eight modules in Contrip land that try to allow you to have hidden widgets. You don't need that anymore. You can just move it out of the form. So with use and with field API, we can finally come back to a concept called Snowman. Snowman is a taught experiment by Jeff Eaton. And basically what he tried to do two years ago was try and figure out whether you could create a distribution or an install profile with Drupal Core alone. So only Drupal Core and no Contrip modules. Turned out at that time we were still working on Drupal 7, none of the stuff that I've talked about until now wasn't not in core. So he basically couldn't do anything. But now it's finally useful. Jeff Eaton is really happy today, finally. He's talking about that. If you're interested, he's talking together with Roy Scolton from the user experience team. He talks about it tomorrow. It's a core conversation. Don't be scared, core conversations are actually pretty nice. And Jeff Eaton and Roy are really nice people. So if you're interested in that, they're going to talk about Drupal 8 and the power of Drupal 8 even more than I'm trying to explain to you guys. So blocks and layouts. So if you were in Dries' keynote, Dries also mentioned it's basically only blocks. The layouts part of what we were trying to do didn't really make it into Drupal Core. But we've done some nice things. We can finally have multiple instances of a block. It was impossible until now. You need to use a module like, say, Context or use Page Manager and Panels to have multiple versions of one block. That's finally possible. We have an improved UI and we also have fieldable blocks. So you could create a custom block in Drupal 7 which only allowed you to add a title and a body. In Drupal 8, you can add new fields to them and you can actually have multiple custom block types. So, great stuff. I think I'm going to show a video and I'll probably have to do it like this again. So, okay. Are blocks entities? Hmm? Are blocks entities? Blocks are entities. Okay, so the UI has been improved. One good thing is it only lists the blocks that you are actually using because if you would have a lot of blocks, it would actually, sometimes JavaScript would stop. You have a little search bar on the right and then you just select a block that you want and just save it and then reload it, of course. So, this is an example of adding to whose online block and just to show you that we can actually use multiple instances of one block, I'm going to add the search form and I'm going to put it in the right sidebar. And then, you now can have finally multiple instances of a block, which is really, really fantastic stuff. You can do goofy things as well if you want to. The main page content is actually a block. You can do stupid stuff like this, but fantastic. So, we can say goodbye in Contrip to feelable panels paints and the Beans module. It's in core. We don't need Contrip anymore basically for Drupal 8 which is kind of cool. There's a fantastic session about blocks. Tomorrow also by Frédéric Marant. He's talking about the history of blocks from Drupal 1.0 to 8.0, basically today. It's really fantastic to look at how the UI of blocks has been changed over the course of time. So, if you're interested in that, really go watch it. So, let's see what next. Multilingual. I could talk for hours about multilingual because I'm from Belgium. Every time I need to create a website, it's usually two languages. It's usually Dutch and French, and then usually we also need to add English and then sometimes German as well. It's painful and it's really an understatement. In Drupal 7, you basically need to enable at least five or six extra modules from the internationalization module that is all in core right now. Basically, more or less. But for pillars of change, basically the first pillar is language. It means that everything in Drupal core has a language. Whether it's a stupid string, like say your site information, it has a language. That was the basis to make sure that we could add more multilingual support to Drupal core. The interface has been changed a lot. It's a little bit more friendly. A really important change is we moved entity translation module into core and we deprecated the content translation module. It means that if you have, for instance, five or six languages and you want to translate one node, you would still have one node. So it doesn't create new nodes. So that's the way that entity translation module works. Fantastic, it works on every entity. So not only your content is translatable, but also your taxonomy terms and your comments are translatable. Basically, every entity that is in core or if you have your own custom entities, they will be translatable out of the box. You don't have to do anything to make them translatable, which is great news. Another great thing is configuration can now also be translated. For the first time in Drupal history, you can translate your site slogan or your site name to a different language. You need it to enable or you need to enable four modules for that in Drupal 7, which is ridiculous in my opinion. Great news. One nice thing also about the translation, the configuration translation is the fact that that translation is written to files, so you can actually also deploy it really nicely. It's not stored into the database, fantastic news. There's one module that we still need to pull into core, which is called config translation. It will allow us to translate dynamic configuration. What I mean by that is when you have, let's say a block, which is shipped within core, core will be able to translate that. If you create a new block, core cannot translate that by default, so we need an additional module. But basically in Drupal 8, you will only need to enable three modules and they are in core, fantastic news. We can ditch internationalization, finally. Gabor is talking about that today at one o'clock. If you're interested in multilingual and I think everyone from Europe should be interested in that, you should really watch the session and then just play around with Drupal 8 with all the translation stuff. There's a lot of things still to do for translation in Drupal core. If you're interested in that, help out. Go to Gabor or go to Kathy. They will be really glad if you help them out. Something revolutionary as well in Drupal, we have a WYSIWYG editor in core. It ships with core. At some point during the release cycle, we were trying to figure out whether we were going to use Aloha. We went for a CK Editor for several reasons. It has tight integration with text formats and it also has inline image uploads. And the only way that I can show you that nicely is with a fantastic video. So let me show you that. So we are on the note article screen and we ship with a editor and you see the buttons over there. If you switch from text format, then you will have different buttons. So there's tight integration with the text formats. If you configure your text formats, you can actually just configure the buttons or the things that you want to allow. You just drag and drop them in. It will also update the allowed HTML. Thanks immediately for you. You don't have to think about that anymore. So you just save and then you have your new buttons. And it actually works. So I'm going to edit title because you cannot save a note without a title. And then you just start creating your content. One nice thing and this is relatively new as well. You can also now upload images in line within the editor. So you don't have to have a URL or something like that. You can also add captions and things like that. So you select an image and then you just basically save it, right? You can add a caption. So if you go down, you can add and change that if you want to. Really nice stuff in my opinion and it ships with core. Another nice thing, it also knows or integrates with the breakpoints module which means that if I would start, if I would look at this note on a mobile device, the image will actually also resize as well. So integration is really tight there as well. So really great stuff from the WYSIWYG team. So we can say goodbye in contrib again through a lot of modules. We can say goodbye to the WYSIWYG module. The insert module more or less. And there were also a lot of various standalone WYSIWYG modules. We don't need contrib anymore to have markup. We also have inline editing because content, if you can have a really nice site which has a nice configuration, if you don't have content, your site is useless. So, and editing that content can be quite tedious sometimes. So the edit module integrates with field API and it means that every field that you create will be automatically inline editable on the front end of your website. It also integrates with other properties, things like title. Basically at this point, it doesn't work yet but we cannot ship Drupal 8, don't laugh. Yes, I know. But we cannot ship Drupal 8 if you cannot edit the title on your front end. We have been discussing that for a whole weekend and we finally have a plan to make that work, hopefully. But it works basically also on any page. For that I also made a little video because it's so freaking cool to show that. So, we're on a node page and you just have to click on a contextual link and then you can go to, where I'm going at actually, I don't see it. Okay, we go to the body. What's also nice is that you now see the buttons from your editor as well. So, you don't have to think about adding your own markup or things like that. Works perfectly fine. You can also change the image if you want to. So, again, go to Quick Edit. Click on the image and remove it and then you can actually just upload a new one. So, it's really, really easy just to browse around in your website now and just change content everywhere. So, this is on the node page. If you would look at the front page, it works there as well. We are looking at a teaser. We don't have to care or think what kind of content this is. You don't have to go to the admin content screen or you don't have to go to the edit screen of the node. You can directly edit it on the front page which is fantastically great. So, that's the inline editing module. Great stuff. Now, something completely different, configuration management. I've talked about Dries's dream, eliminating the developer, designer, things like that. I can add something to that. I maybe should tell him that he can add something new. Let's try and get rid of the system administrator, more or less. But basically in Drupal 8, all your configuration is now stored in files. So, when you are configuring your website, all of that configuration is written into files and we have a UI in Drupal Core to export your configuration and then go to a different version and then import it again. The only way to show you that is again with video. So, what we are doing is we are going, when it starts, we're basically going, I have two versions. So, I have a dev and a prediction, for instance. I'm going to change the site, name to something completely different. And I'm also going to create a content type. So, basically everything in Drupal Core is now deployable. You don't need features or things like that, all variables, things like that. You can just basically import and export them by yourself, which means that if you don't want to, you don't need to commit your configuration or things like that. You should, because it's interesting to have everything in VCS somewhere. So, what you have to do is, you go to configuration, there's a config module, which is basically a UI, which allows you to import and export. So, it's, let me see, okay. Let's go to configuration. Underneath, nested underneath development, you have configuration, export, import and synchronize. So, what we now just have to do is configuration, export. There's just an export button there. You click on it and what you get is the complete configuration of your website. If you would open up the downloaded file, you would see all the files that are in there, which is kind of great. It used to be, all this stuff used to be in a database somewhere, which is horrible to figure out where something is stored. There's some serializable crap and things like that. It's now nicely in a file. Okay. So, we have downloaded, we go to our production website, we go to configuration and then basically the only thing that you need to do is go to import and upload that file. So, what will happen at this point, Drupal will show us a screen with all the either new things, things that have been changed or deleted. And you can also look at changes, actually. We have a diff in core. So, if we click on the site, we will see that the site name has actually been changed. And then the only thing that you now have to do is click on import all. And now Drupal will install that configuration for you, which is kind of great. So, we can kill the deploy guy or something like that. We don't, hopefully there are no system administrators here. I don't know. Could we do questions later? All right. One really good advice from Alex Pott, our core committer, don't hack your active config. I mean by that, it's really tempting nowadays to go into your files directory because your configuration is in files. It's extremely tempting to open it up and then just start changing something and then magically hope that everything will be okay. It will not be okay. It might be okay for site information and things like that, but especially for stuff like fields and instances, views as well, there needs to be some additional processing happening. So, either use import and export, there will also be additional tools that will come out that will create kits and stuff like that, but don't hack your active config because otherwise you will get into a lot of trouble. So, we can say goodbye in contrast to a lot of stuff again. We can say goodbye to features module. Everybody cheer. Actually, the role of the features module will change a little in Drupal 8. It will still exist, but it will actually do what it was intended for being a package manager. Everyone abuses features in core just to move over the complete configuration. That doesn't need anymore. Cetus exportables, again from the Cetus module. Upgrade code and you can also say goodbye to napkins. I mean, everyone has just written down stuff on a paper somewhere and then, okay, remember this, go to production. Ah, I've forgotten that and whatever. It happens. I've done that, everyone does that. Don't worry. So, some little gems. Things that make life especially easier. We have services in core, which sounds weird, but it allows us to move contrib modules again out of the way. It has fantastic view support, which means that you as a side builder, you can expose your content as a service so that someone else can access it. For instance, for Android or whatever platform. Really great stuff. We have multiple upload for the first time in Drupal history. Yay. And we remove the upload button. It's Ajax, but so basically if you just choose a file, select a picture or whatever, it will start uploading it for you automatically. You don't need to click. Less clicks, great. As Ries also mentioned in his keynote, we have a tour module, which is basically more or less a replacement for the help module. Nobody reads help, basically no one, because also the help in core modules or even contrib modules is extremely outdated. The tour module allows us to give a visual interpretation and help us give a nicer overview. We also have a responsive toolbar. Might sound weird from the side builder perspective, but if you would do side building on your iPad and things like that, it is actually pretty nice. You can also search modules. It's quite a pain in the ass if you... I should have started with this, apparently. Fantastic. I don't know the name of the module that is in contrib that also gives us the functionality, but it's now in core. For the developers, if you are doing tests, you can also search for tests on a simple test page, which is also really great. So we also always say goodbye to core modules within every release for various reasons, because either they're outdated or maybe nobody is interested in maintaining them. So modules like Paul Trigger, OpenID, Block, the PHP filter is gone from core. No, okay. Maybe you use that. Don't use PHP, really. Especially in your, like, say, visibility of blocks or things like that. And also the profile module has been removed. People advise to use profile two. Of course, it doesn't exist yet at this point for Triple 8, so if someone's interested to give more power to user profiles, please help along. So how is contrib doing? We try to advise people to start playing around with the API and start porting their modules to Triple 8 so we can actually figure out whether our APIs are working or not. So I know a couple of them. I'm biased, of course. This play suite is working for Triple 8 with some bumps now and then, but we follow really, really closely. We know there's a port underway for field group as well. I know that Google Analytics, for instance, is working. One of the unknown things at this point is that I have no idea what is going to happen, for instance, to page manager and panels for people who are using that. We were promised to have more or less layouts and the notion of page manager in Triple 8 Core that's obviously not really going to happen. So someone will need to step up and then basically port page manager, which will be a really large task. So the sooner we start, so if you're interested in that, if you're using that, either help out or talk to the people that maintain a module, try to figure out whether you can help them or not in any way. Token UI and Path Auto are also one of those modules that I usually use. I'm not sure about the status at this point. But basically, Triple 8 is really going to rock. We've moved so much stuff into Triple Core in terms of site building. It's amazing. I think that you can do really basic websites at this point. So Triple 8, it will be out when it's ready, but it's going to be fantastic for every site builder out there. So if you have any questions, you can go over to the mic over there and then I'll try to answer your question. When you were showing the WYSIWYG, Dries had mentioned in his speech that there was a way to simplify that and wouldn't show the text formats, but your example had the text formats. Is there a way to hide that somewhere or what is... Good question. I actually haven't tested it. I'm not sure. So this was a standard installation, of course, which comes with three or four text formats by default. I think if you would remove them, I'm not sure what's going to happen. So I should test it myself. I think the only way to get rid of it is probably a form alter, sadly enough, or hide it or whatever. I don't know, but I actually don't know. So, sorry. What happens to file entity and file management? Yes. Good question. Files are still not fieldable. I know that Dave Reed has been trying to get file management forward in Drupal Core. Not much happened there. So that will still be a solution within Comtrip, sadly enough. But I think that it's going to be something for Drupal 9, but of course we're waiting for Drupal 8 at this point. But yeah, file management has been modernized in terms of API, but UI-wise, there's not much. Of course, you can use file uploads within the editor, of course, and we actually also know if you upload a file there. We know it's tracked and things like that, but that's basically it. Thank you. Any other questions? Okay. Sing my question. You can. Do you know anything about the status of Drush yet for Drupal 8? Well, Drush has been moved to GitHub. So if you actually want to try Drush with Drupal 8, you have to check out the master branch and then it works perfectly fine. I know Drush at this point has some commands, for instance, to run the import from configuration management. It also has a command to edit your configuration from command line and it opens up your favorite command line editor and then does all the processing of saving and stuff like that. So Drush works with Drupal 8, again, with some bumps sometimes, because for instance, maybe that's also a really big change at this point, which I didn't include in my slide. Since three or four days ago, you cannot disable modules anymore in Drupal 8, which is kind of weird. There's a really technical reason for that. So the only thing that you can do is install modules and uninstall. We are still discussing to bring some kind of disabled state back. So in that sense, Drush at that point was broken because module enable function didn't exist anymore, for instance, but they follow up closely, so. You showed that you can export the configuration, but only the whole configuration is there any way to select which part of the configuration you can export? And then use from features? Yes, yeah, so the model in Drupal Core you cannot do partial imports, which means that if I would move, let's say, one configuration file from, you have two directories, basically. You have an active directory and a staging directory. You put the files that you want to deploy in your staging directory. If you would only put one in there, then the synchronized configuration page will tell you, okay, I have something new or something changed and it will delete the rest. So Drupal Core only supports partial imports at this point. Everything is pluggable. So I know that someone will work on this in Contrib somewhere and make it happen that you can select individual files on that. But the model in Core is, you have to deploy everything at once, so. I'm glad you mentioned that in Drupal 8 it's not possible to disable modules. So could you tell us some more about it while we manage our modules and what does it mean for side builders? Well, it means, for one, that you cannot disable modules anymore. It means that if you uninstall a module, what happens at this point, the configuration system in case there is configuration will delete the complete configuration, which is kind of annoying, of course. But there are a lot of technical reasons, especially for the configuration management to remove that feature. Now, again, don't worry, we have criticals actually in the queue to bring some kind of state back so that actually if something goes wrong with the Contrib module or whatever that you can disable and figure out whether it's that Contrib module that breaks something. So I don't know at this point. So I think we'll have something back, but it won't be like a permanent state or things like that. At this point, actually enabling or disabling modules is still broken in that sense for configuration, import and export. If I would enable a module in my Dev environment and then move that configuration to production, it doesn't work at this point. So one of those critical things was the actual enable, disable, and there's a lot of other reasons why we had to remove that. But we're still discussing it. And it's been a painful issue. With Fusing Core, is there a possibility to the admin pages already in views? So we can add filters and stuff to it. Yes, core ships with admin content. Tim, does views also already take over the user page? Yeah, okay. So they're defaulting views. Regarding the multiple blocks, how does that play with form IDs? Like for instance, if you put the search form form on the page twice, is the ID made unique or not? Good question. It should be. If I remember correctly, when in the API somewhere, Drupal Core will make sure that it will generate a unique ID. I'm pretty sure of that. It will work. I should test it, but I'm pretty sure of it. Hello. Oh, sorry. Is there anything in Drupal 8 to automate content backups? Something like the backup in migrate module? No. No. Maybe one interesting thing is that every piece of content in core now has a unique ID, but there is no UI, for instance, to move content from one site to another. That will be something for a contract, but there's no backup solution. Dries in his keynote mentioned that the number one goal for D8 is working on the performance. That kind of suggests that it's maybe a little heavier than D7, could you comment on that? Well, I think moving all the contract modules to core doesn't really affect performance in that sense. If you enable a lot of modules, of course, in your installation, then you get into trouble, obviously. By moving contract modules to core, then we can also integrate it more tightly with core. For instance, especially like language, for instance, you have to enable internationalization. You usually have to enable at least maybe 12 to 15 modules, which affect your performance. In Drupal core 8, you only need to enable three modules. So in that sense, we try to make sure that with a less amount of modules, you can do more stuff, which is great. In terms of performance that we need to fix for Drupal, is not related to all the site building stuff that we have done. More really API related and things like bringing symphony and things like that and using OOP. OOP is always a penalty, gives you a penalty in terms of performance, but using it is a really good thing. So yes, Drupal 8 might be a little bit slower, but in terms of scalability, Drupal 8 will be fantastic. So I'm looking forward to using production as well. Any other questions? Okay, thank you for coming and have a nice Drupal come.