 All right, Ola, Bondia, but it's not morning, so it's Bono Tarda? That's about all the cattle, and I know, so sorry. So hopefully you're here to learn about features for Drupal 8, and I hope we don't all fall asleep after lunch, so I hope to keep you entertained in the next hour or so. I'm Mike Potter, and I'm the Prime Maintainer of the Features module, and the Features Override module. I'm also the Architect for the Open atrium distribution, if anybody has used that. I'm just curious, so raise your hand if you were at Matt Cheney's session this morning on CMI deployment. Okay, so we're gonna overlap a little bit with that, and then go into some new stuff. Is anyone here who's already heard me talk about this at maybe DrupalCon LA, or we got a brand new audience? All right. And how many people here want to be brave and raise their hand to admit that they don't even know what Features is, or they don't use Features, and they're just brand new here to learn something new? Okay, good. So we're gonna have a little bit of intro, and then we'll get into, so then presumably the rest of you use Features and probably wanna throw tomatoes or something, right? So in Drupal 8, about a year ago, a famous core developer said that they asked who has wasted more than 100 hours with the Features module, and that in Drupal 8 that was gone, problem solved. So therefore this can be a really short talk, because if we don't need Features in D8, why are we here? All right, so why are we still talking about Features, especially if you're at the earlier talk, like we have CMI, woo, Drupal 8 is great, who needs Features? So to review a little bit about what we're talking about here, and the problem we're trying to solve, and this overlaps a little bit with Matt's session this morning, when you build a Drupal site you have this database, and in the database you put a lot of stuff. You put all of your content pages, all of your articles, your blogs, your comments, your users, your user profiles, and we call all of this collectively the content of the site. It's what your end users are creating, it's what your content creators are creating, the content of the site, but in that same database we have things like custom content types, and fields, and views, and just random check boxes that you select in your configuration, we call that all configuration, and having that stored in the same database can be a problem when you're trying to deploy things to different sites, or just when you're trying to control that config. What Features does is it takes that config part of the database, and it writes it to code, and so now you can manage it as code. So why is that a good thing? So it's a good thing because if you can get your configuration into code, you can version control it. You know, let's say someone goes in your site and changes the name of a view, how do you know? You know, if you can get it into code and put it in version control, you can see when it was changed, who changed it, you can revert your changes, all that good stuff. So it allows you to then deploy your configuration, like your new views and your new content types, from your development environment to your testing, staging system, and then on to production, because it's in code, so it's treated just like the rest of the code of your site. It allows you to create reusable modules, so you can put all that code into a custom module, put that a module on another site, turn it on, and have that same functionality. So Features was never intended to be a configuration management system. It was never intended to be CMI in Drupal 6, where it was first invented. The reason Features was invented was to bundle functionality into reusable modules. It was actually invented by Development Seed in Drupal 6 as part of the OpenHRM1 distribution, and the idea was they wanted to put package functionality, like a blog in a photo gallery. They wanted to put that together. So what it was meant to do to use photo galleries, an example, is for a photo gallery, you've got a custom content type. So you take that content type, you have some fields on it, like to store your image asset, then you've got the instance of the field, you've got a view to display those fields in a nice kind of gallery grid. Maybe you have an image style to size those images appropriately. Maybe you have some other miscellaneous config variables. All that stuff gets packaged together and written to a module called my photo gallery module. And now once you have that module, you can move it from site to site. And Freelancers, developers, use this all the time to gain efficiency. If you build some functionality for a client, you don't want to redo that over and over and over again. You want to make it reusable and then deploy it on your other client sites. That's why Features was invented. But because it could write config to code and nothing else in 777 could, it got abused. So why was Features bad? And why do we sometimes, including myself, curse Features? So one of the problems with Features is there's no consistency. How do you put this stuff in code? It's not code, it's data. It's like a view, a view in code, like a view is an object. Some things are objects, some things are arrays. I was just in the issue queue dealing with this issue of arrays versus objects. How do you write that to code? There's no consistent way to do that. Code is just not good for data. Like I say, we're trying to write objects with properties or arrays with keys or string values or things like that. And trying to write it out as PHP code is just not very good. PHP is not a very good data language. And then you have things like now you've exported it to code. Someone goes and changes your view name in the system and now it's marked as overridden. Or you install some new module and something's marked as overridden. Or it's Tuesday and something gets marked as overridden. And it's like, who overwrote it? What do you do? All that good stuff. But Features is all we had. And it's a very complex, hard problem to solve as anybody on the CMI team in Drupal 8 will attest to. But now in Drupal 8 we have CMI. CMI stands for the Configuration Management Initiative. The idea in D8 was to separate configuration from content, do it nice and clean. And we can thank a bunch of people. The original initiative head was Hey Rocker, Greg. He's now passed the torch to Alex Pot. And then of course a whole bunch of people. I mean the whole community contributed. And Angie and Dries were committing patches from people across the whole community to CMI. In my opinion I think it's one of the most successful initiatives in Drupal 8. It was started early. It had a very clear focus, very clear purpose on what it tried to do. They did it. It's done. It's in there. We can all use it and be happy. So let's talk about CMI a little bit. Why is CMI so awesome? And Matt talked a little bit about this this morning. So first of all in CMI configuration, instead of trying to write this into PHP code, we're going to write your data into these things called YAML files dot YML. And YAML is a standard format. It exists outside of Drupal. We didn't invent our own format for a change. We adopted something community wide. And it's a great format. It's meant to store data. We have in CMI a built-in import and export. And that was demoed this morning. You can go into the UI and core Drupal. You can import your configuration. You can export individual things like a single view, like you could in D7. But now you can do that for any entity or any system that has config. So we don't have to worry about implementing any of these hooks anymore. The hooks are all gone in D8 as far as configuration goes. There's no magic. If your config in your YAML file says that your site name is my Drupal site, nobody's going to change that. That is your site name. There's no magic way for some module to do an override hook or an alter hook and change it on the fly. And that was done on purpose. And it just works. If you've used Drupal 8, CMI is just there. It works and we can be happy. So again, if CMI is so awesome, why are we still talking about features? Why am I still up here? So features, exports config to code. CMI exports config to YAML data files. That allows version control for both. That allows us to deploy from development staging to production for both. And in features, you can reuse bundled functionality. And in D8 CMI, you can't. There's no mechanism for doing what features was designed for. So there's some issues with CMI, as great as it is. Everything's got issues. We can't have a perfect world with no bugs and no issues. So one of the things is, what if you do want to put... What if you want to make that photo gallery module that we talked about? And you can store YAML files as part of your module. There's a directory structure. You stick your YAML files in there. And now your module can have a view or anything else. So what they want you to do in D8 is to go find that content type for your photo gallery and copy and paste that YAML file into your module directory. Go find the fields. Go find your view. Go find that image style. And what else am I supposed to put in here? Like what else is Drupal's storing configuration in for my photo gallery? I don't really know because I'm not a developer. I'm just a site builder. And I just want to make a photo gallery module. So it's a little hard to do that. Even though CMI allows you to import and export individual things, it's hard to pull that out as a separate piece of functionality. The other fun thing is when you put a YAML file in a module in Drupal 8, it's in a directory called config slash install, that YAML file is read into Drupal when you install the module. So it provides the initial default configuration for that, whatever it is that's in your module. If you then go change that file in your module, nothing happens. That's only the initial value. If you want to change it, you need to do that through writing update hooks. So you can say, okay, I release a new version of my module. If you change that YAML file and you put it on a site that already has that module, it's going to ignore your change. You've got to go into an update hook and say, change this value. And so that's how you deal with site-specific changes. The other thing that's interesting is if you uninstall a module, it doesn't necessarily remove all the configuration associated with that module. So for example, if a module defines a view and you uninstall the module, the view is not necessarily gone. Depends on your dependency chains. In the newest versions of Drupal, you can actually end up with a system where you have some configuration dependencies that will prevent you from even uninstalling that module because maybe it's defining a field and you have data in that field and you don't want that field to go away. So this is good. We don't want you to remove configuration when you uninstall a module. I don't want to remove a field because I might have data in that field. And features did the same thing in D7. And some people sometimes think this is a bug where you have a feature that has a field. You turn the feature on, the field pops up. You turn the feature off, the field is still there. And people expect it to clean up after itself. But you don't want to do that because people might have already put data into that field. So CMI did the same thing, and that's good. But the tricky part with CMI is if you try to enable a module and the configuration of that module already exists on your site, Drupal 8 will refuse to install that module. It will actually give you a nasty little exception violation saying pre-existing configuration. So for example, if your module has a view and that view already exists on your site, you can't turn on that module. So that's a problem for developers trying to make one of these pieces of like photo gallery functionality, right? And my photo gallery has a view. Maybe there's a bug in that view and I need to release a new version of it. There's no way for you to install that new module because it already exists. So you get this wonderful little catch 22 where if it lets you disable the module with config, you then can't re-enable the module. So some fun issues. So we still need features to create bundles of functionality. And that's what we finally get to go back to our roots in D8 and do with features. So what is features going to do? And I'm going to demo features for you today. It lets you do the same things you could in D7. You can import and export configuration much like CMI. In fact, it uses CMI. You can detect changes. If somebody changes something like a view, you still can see those changes. But there are some new features as well. In D7, features was kind of this black box. You sometimes didn't know what to put in a feature. How do you know to make a photo gallery to add all those things to it? When you go into features in D7, you just kind of have this blank page. In D8, we have this concept called assignment plugins, which will automatically package your configuration into suggested features. So when you first go into features in D8, you don't have a blank page. You have a whole bunch of suggestions for saying, hey, do you want to export this, or export this, or export this? And it's a very pluggable, configurable system that we'll show you. In D8, we now have namespaces, which we call bundles, which I know is a little confusing because there's bundles and content type in entities as well. But basically, a bundle in D8, it's kind of like in D7, where you had categories on those tabs on the left where you could categorize your features into different categories. Same concept. Except here in D8, it's going to help you enforce namespacing. So you're not going to pick a name for your module that might conflict with somebody else. So if you're working on open atrium modules, you'll be in the OA name space, and every one of your features will have OA underscore as part of the name. We have support for the latest Drush, actually Drush 8 support as well, but we also support Drush 7. And features is very modular in D8. In fact, the UI is a separate module. So if you no longer want your end user clients messing with your features, you can turn off the UI, and so they can't do that. But even better, you don't even need features on production. Features is now a development module used to create bundles of functionality. You then deploy those pieces of functionality as normal modules, and you work with them on production as normal modules, and you don't need features anymore. So in some sense, features did go away in D8 just on production. Now I have to put a slide and a shout out here. This was a really fun collaboration. When I first started getting into doing features for D8 this past year, I surveyed the landscape, and I found this module called Config Packager that was written by Nejo. If any of you know Nejo, he's a really prolific contributor to Drupal, great guy. And Config Packager, that sounded like what we wanted to do with features. We want to take configuration and package it up into things like photo galleries. And so I looked at it, and I'm like, this looks like a lot of the base of what we want features to be. Contacted Nejo, I said, hey, do you want this to be features, or do you want to maintain your own module? And he's like, I'd love to have this be part of features. So Nejo is now a co-maintainer on features, and we built features D8 around his Config Packager module. And it was really an example of how Drupal Contrib is supposed to work, because he had ideas, I had ideas, I had experience from the D7 features. He has things he's wanted to put in features for years. We're able to kind of put that all together and end up with the result being better than the some of the two parts for how that goes. So if you see Nejo, shout out to him, thank him for his work on this. So let's jump into a demo here. So here I am on my local D8 site. So features is located with CMI. So you go into your site configuration, you go down under development, because this is a development module, and you go to your configuration management page. And this is where CMI lives. It's just that we've added some feature or a tab to it. But this is where your full import and export for CMI is that Matt showed this morning. This is where your single import-export is, again part of core where you can go export a single view if you want and do that. But now you can go to the features tab and look at your features. And you'll see that by default it has auto-picked or auto-packaged several things together. You can click on this to expand it. And it will show you that in this article feature that it's suggesting, it has all these different things that are part of that. And it says that it is currently not exported. So if you want to export something, you can just essentially click on it and export it and be done. So that's what features looks like at a glance. Now in order to make a feature, let's make that photo gallery that we talked about, that we've talked about for a long time. So in order to make a feature, we first need to create the photo gallery. We need to do all those things that I mentioned earlier. So let's go back to our local site and let's go create some stuff. So we have a content type. We need to add an image field to it. And now we're going to go create our image style. If only it was this fast in real life, right? Now we're going to create our grid view. So the grid is a view of our image content type. And we're going to show all of them. We're going to add the image field to the view so that it shows the images. We're going to select our image style. We're going to give it a menu link called gallery. So now we need to make some content to display. And so of course I love my cats. So we're going to upload a bunch of cat pictures into our gallery and click gallery and there's our photo gallery. All right. So we've created a photo gallery. All right. So now let's take all that work and we don't want to do that again, even though it was really fast. We don't want to do that again. Imagine you spent weeks on this photo gallery. It's like the world's best photo gallery. Now we want to featureize it and move it to a new site. So with features, how do we go create the feature? So we go back to where features lives, which as I said is in the development configuration management area. And now we will see that our gallery is listed as a new feature we can export. So right at the top there is my image. And if we click on that to go look at it, you can see it's got a name. And here's all the things that are added to the feature. We've got our content type. We've got our field and our field storage. We've got our view. Now it doesn't auto detect the image style yet because there's actually a bug in views. It does not have a dependency on its field formatters. So we add that manually. And we can come down here and just like in features one, we can click right, which is equivalent to generate and poof. We just made a module. Now if you want, you can also click download archive and it will download a tar ball of that. If you want to move it to your site manually that way, you can do that just like in D7. Okay, so now we've made a module. The features page does not allow you to enable the module. You'll notice it says uninstalled, but this is a normal everyday module. We go to our Drupal extend page, which is where the new module page lives in D8. And we go find our new module and we enable it. And now we have our image gallery enabled on our site. And now if we go back over to the features page, just go back in the browser to where we were and refresh the page, you'll see that where it says uninstalled, it now switches and now it says enabled. So it shows us that that module is now enabled on the site. So there was a trick there, right, because when we were doing the fun thing with the music, we created the content type and the view. But now we just enabled a module that had that same content type and view. So we just bypassed that Drupal 8 thing I told you about where it doesn't allow you to enable a module that has existing configuration. And that's one of the tricks of having features on your site will do for you. We extended the core config installer class and we said in this extension, oh, you're installing a feature, we will let you do that. And we will bypass this config exception. So that is one reason why you might still want features on production is if you have a situation where you're trying to install modules that have pre-existing config, if it's marked as a feature, it will allow you to install that. Okay, so we've now made the feature. We exported it to a tar ball to this module, so now let's go to another site. So actually, this is pretty trivial, but we're just going to copy this tar ball. So we go into our modules directory and we're going to copy that tar ball that I downloaded into this directory and we're going to unarchive it. And there's our module. Okay, so now we're going to go to our new D8 site. We go to the modules page, the extend page. And now there is no features module on this site. And so I'm going to type in features and see, look, no magic. There's no features module. But we're going to find our My Image module that we just installed. There it is. So we now enable it. Save. And now when we go to our main site, we'll see a gallery link. But of course, we have a gallery, but we don't have content. So yes, once again, we have to upload more cat video or more cat images. So we'll do this really quick. I'm just going to put two of them in here. Add our second one. And now when we go to our gallery page, we see our gallery. Okay, so we just created our gallery on a brand new site without creating the view or anything else. So features works. Everyone's like, wow, we've been doing this in D7 for a long time. And now you can do it in D8. So let's talk about some of the more nitty-gritty details. So what happens when somebody changes your site? So in this case, we're going to use the in-place editor. We're going to go edit this view. And our CEO hates that it says My Gallery. They really want it to say My Cat Gallery because that's what this really is. So they go and they change the view. And we save the change. And now we go over to our feature. We're just going to go back and look at our feature and we're going to refresh the page. And where it says enabled, it now says that it's now changed. And we can click the change button. And actually if we expand it, it will show us that what's actually changing is the view. And if we click on where it says change, that's a link. And that will take us to a diff page so that will show us that what has changed is the name. So in the active configuration in yellow, it says My Cat Gallery. In the code configuration, it has just gallery. So if we want to undo this, we want to import the code back to the site. We just check the box, click import. And now it's going to be back to just saying My Gallery. So if we actually go look at it and see it says My Gallery. Let's do that same change again. Let's change it back to My Cat Gallery. And let's say this is no. We really, really, really want it called My Cat Gallery. We want to put that back into the code. So we change the view. We save that. We go back over to features. And we refresh the page. And now from the front page, we can just click the box and say write. And it will now export that feature again. And now our change is in code. So in fact, if we go look at it in code, so it says My Cat Gallery is still on the site, if we switch over to our code editor, we're going to go into the YAML file for this view. So this is for the real techie geeks here. Here's the view in YAML. We go down and look for title. And we can see in code it says My Cat Gallery. So that's how you handle both import and export. So you can see the names have changed a little bit. This would be in D7 the equivalent of doing either a revert, which is now import, or an update, which is now export. So we've changed the terminology to be consistent with CMI, so we're used to using the same import-export. Because that was a problem in D7, right? Revert, update, like it was generate, like what do you call it? It was all very confusing. So we fixed all that. So let's look at something new. Let's look at this new bundle functionality. So as I mentioned, bundles are kind of a way to group together your different features. And so there's this little drop-down called bundles. We can go to a config bundle tab to create a new one. What a bundle is, is both a namespace, but also, and I'm going to try to... Is it control? Okay. Try to pause this a little bit here, because I like to talk about this page a little bit more. So a bundle is not just a namespace. It's also all of the settings for how you want your features to be auto-packaged. So when we saw, when we went into features the first time, it was, you know, it had things like article pre-selected as a feature. How did it do that? It did that through these things called assignment plugins. And there's lots of different assignment plugins that you can see listed here, and they run in a specific order. So for example, that first one called packages, it goes out and it looks for existing feature modules, and it brings those in as lines in our features listings. The existing one then takes those modules and figures out what config goes into it, and so on and so forth. The really important one is the one kind of midway down called base type. Base type controls how you want your features organized, and by default it's organized by content type. So article is a content type, so you get a suggested feature. Page is a content type, you get a suggested feature. But as you'll see, there's options in the config for that, where you can bundle your features however you want. Maybe you want a feature for every view on your site. So you go change it from content type to view, and now it's going to suggest features for every one of your views. So really powerful functionality for controlling how features are displayed. And all of these settings get saved as a bundle, and you can have more than one bundle on your site, and you can switch between them. So you can have the content type view of your site, or you can have the views view of your site, or the fields view of your site, and so on. And these are plugins that you can write, you can write your own, you can reorder them, you can turn them on and off. So for example, if you don't want features to ever show you these auto-detected dependencies, you just unclick the dependency plugin, and now it won't show you those anymore. If you don't want it to do namespaces, you can actually turn off the namespaces. Okay, let's proceed here. So what we're going to do now is we're going to go show you the configuration page for this base type, and you'll see all of the things that you can organize your features by. And there is content type selected. You can select more than one, you can select views if you want. Honestly, you can get really weird looking stuff by checking all sorts of different boxes there, so it's not something you're probably going to typically do most of the time. Your bundle has a name. In this case, let's say we're going to work on open atrium features. You give it a name, you give it a machine name. In this case, we want OA to be the prefix. Now, all of our feature modules are going to get namespaced with OA underscore. So we'll go ahead and we'll create this bundle. And now back on our main page, when we list our features, it's going to show us all the features within the atrium bundle, and then it's going to show us down below all the stuff that's not yet exported. So if we want to put article and page into our atrium bundle, we can just select them, click the right button, and now you can see we've created two new modules. We have OA underscore article and OA underscore page. We can go look at all bundles by selecting none here, and now we'll see those two plus our original My Image. Now let's say we want to put My Image into this bundle. We just click on My Image, we go down to the bundle field, we select open atrium, and then notice it tells you it's going to prefix this with OA underscore, and we can just write this out, and now we'll have a new copy of the module called OA underscore My Image. So if we go back now to our features page, you can see it says that this conflicts. So we're currently looking at the atrium bundle. If we expand this to look at all the features on our site, we can see that we actually have two copies of the My Image module. Now we have the My Image and we have the OA My Image. So that's why it conflicts. You've got two modules with the same config. So let's just remove the old one. Just remove My Image, refresh the page, and now our conflict is gone. Now it knows that stuff is in the OA bundle just because of the prefix on it as well. So let's talk about this for just a second. What it just did there is actually kind of interesting if you used D7. How many people have tried to make a copy of a feature module in D7? How many renames do you have to do to do that? You have to change the file names, but then you have to actually edit every file because there's all these hooks and these module names and you have to go edit all the module names. It's a huge pain. Here we just made a copy with a couple clicks. So features lets you make copies of modules with conflicting configuration. Again, not something CMI is normally going to let you do. Features lets you do it because it knows that that's just a temporary thing. You want to do it as a developer. You don't want it to get in your way. You're going to remove the duplicates, hopefully when you're done, but it's going to let you in the meantime have that conflict. So really easy to copy stuff now between namespaces and move things around. So what makes a module a feature? Like let's look at this My Image. Let's go look at the code. So in the My Image module, there's this YAML file and you can see it wrote features into that. If I just remove that Features key and then refresh the page, it's gone. It's still on the site. It's still a module on your site. It's no longer considered a feature. It's just a regular old module. If I go back and I just say Features true, that marks this module as a feature. That's all you have to do. So you can take an existing module if you want and mark it as a feature. There's no magic there. It's just a key in your YAML file. Now it actually knows this is in the Atrium bundle because it sees the OA prefix. So if you wanted to actually be more correct instead of just saying true, you would actually specify what your bundle is. So you would say bundle OA and then that ensures that things don't get confused in the future. But that's all there is to it for the difference between a module and a feature now. It's that one key. No longer, like in D7 again, if you look at your .info file, there's a bunch of stuff in there. It has to tell you all the things that get exported. In D8, we don't have to do that anymore because all that stuff is in the CMI YAML file directory. Let's briefly look at Drush. We've tried to maintain some compatibility. All your favorite Drush commands still exist. Drush.fl shows you your feature list. It shows you that things are changed. So it doesn't say overridden anymore. It just says changed. It's a little bit less geeky. We can look at a specific feature there and we can see all the config that's in it. We can look at the difference. So FD is feature difference. And just like in D7, it shows us that our title is different. So if we want to import the code, we can say FIM for feature import. And that would overwrite the view change. Or if we want to export, we can do FEX. And that would export the change back to code. So just like the UI. So again, going back to our feature difference, I've maintained compatibility with the old command. So if your fingers are used to typing feature revert, FR is still there because of course we had to keep FU. So FU is still there and of course FU wall is still there. We also have FC still there. So FC is feature component. This shows you all the components that you can export. So here I've shown all the views I can export. And then feature add is DrushFA. So I can say feature add. Give it the name of a feature. Give it a component. So here I just added a new view to my feature. And if I list that feature, there's the who's online view that's been added. If I go look at the directory, there's the who's online YAML file that's part of my feature. And if I want to remove it from the feature, I just delete the YAML file. It's as simple as that. And if I now do a feature list, you can see that who's online view is gone from the feature. So there's not a lot of magic going on in D8. Configuration is in the YAML files being controlled by CMI and features is really just manipulating those YAML files for you. But you can also go delete them and create them yourself, edit them yourself if you want to do that. So that's the demo part. Let's talk a little bit about some future stuff. So overriding. So you can see, as I said, we've changed it from saying overrides to changed, which again is consistent with what CMI is doing. You still need to be able to save overrides. We're still going to have the problem in D8 that we have in D7 right now, of let's say we've got open atrium in D8 and you want to change something that open atrium does. It's in a feature. Now your feature is marked as changed. And when you upgrade open atrium, your change is going to get lost. You have to save that change somewhere. How do you save that? So that's the features override module in D7. So we don't have that yet in D8. There's a variety of ways to work around that. There's a module, which is one of Nejo's modules actually called config synchronizer. What that one does is it kind of monitors your config in the background. And whenever somebody changes it, it kind of marks that feature as unsafe to revert. And it will help stop you from overriding a client change basically. So with this module turned on, you could actually write an auto update that every time you install a new version of the module, it could automatically import it if it's safe. And it would know if things have changed or not. That's one way around it. You can implement, if you want, in your module, if you're a developer geek, you can implement the config factory override interface. What your kind of recommended solution is is the same as it was in D7 without features override, which is to do all of your changes in update hooks. But update hooks that require is developer knowledge and so forth. So I think there's still a problem to be solved here. It's something I'm still very interested in because I'm working on things like Atrium where this is going to be an issue. What we're going to try to do and feel free to talk to me after or at the con if you have some ideas around this, what we're looking at is doing something of merging partial YAML files. Something, for example, where in the update process it could look in a certain update directory, find a partial YAML file with, for example, just the title of a view, merge that in with the active configuration to make that one change so that you can save these things where you're just changing one little thing as overrides. So that's something coming. Something that happened this summer, some brand new functionality got added to D8 called optional configuration. And this is fairly interesting. In normal Drupal, if you have a module that, say, adds a view, in order to enable that module, you have to first enable the views module because otherwise you have a dependency that's not met. What if you want to make that optional? Like maybe the view is just a little side feature of your module. You want it to be there if they're using views, but your module provides some other functionality and you don't want to be blocked by that dependency. So now in D8 you can mark something as optional config. You put the YAML file into the config slash optional directory. And so let's say you have a view. If views is not installed, which of course doesn't make a whole lot of sense in D8 because it's part of core, but let's just, for example, say that it's not, it will still let you enable your module. And then when views is enabled, it will magically go back and say, hey, this module over here has a view. I just enabled views. Let's enable this module. So it lets you kind of do stuff in any order now for dependencies. So there's some really cool stuff you can do with that. What we want to do is add that functionality to features where there's a user interface that allows you to mark configuration as optional. Excuse me. So right now everything goes in as a normal dependency. We'd like some way to be able to change that. So that's coming soon. I wanted to segue just for a couple of slides on D8 actually. And now that we've heard from Dries, as it's coming like in two weeks, I think this is very exciting. This was my really first dip into the D8 pool. I worked on this back in April, phase two, the company I worked for was actually very generous and they essentially donated a month of my time to work on features because I told our CEO Jeff, yeah, I'll take about a month. And so he said, okay, go do it for a month. What I found was D8 was actually really fun. It was really refreshing compared to D7. Now I've got a background in object-oriented programming, so I know what MVC frameworks and stuff are, but I'd never looked at any of the D8 core code before. I didn't get involved in core. It took about a week to really kind of get the lay of the land and figure out where configuration was stored and how things worked. Reading a lot of stuff online went to one of Larry Garfield's sessions on D8 development, which I highly recommend. So about a week of learning and then a total of three more weeks later, so four weeks total and features alpha one was done. And it was pretty much from scratch. So for a module like Features, which is really, if you've looked at it in D7, it's not an easy module. That was pretty good, I thought. So if you've been out there waiting, especially if you've got a module in D7, this is a really good time to start looking at porting that module to D8. And don't just look at it as a line by line port or a function by function port. Take a look at some of the new stuff in there. A lot of stuff is different, but it will make your code a lot easier to maintain. These are some stats for people that love little pie charts and graphs. So in the top one, in blue is the Drupal 8 version and red is the Drupal 7 version. So yes, you can see in red there's this huge spike on the right, which is essentially implementing CMI in D7, which is what Features had to do. And that's gone. There's no blue line for that because it's built into Drupal now. What we replaced all that work with in blue is some of the new stuff, like the new plugin stuff and the new assignments and the new bundles. So we basically ended up with the same number of lines when we were done, but all the stuff we got rid of, we replaced by new functionality. What was interesting is we were able to reuse almost verbatim the user interface. So you'll notice in D8, the user interface looks really familiar. It works just like in D7. It's because we were able to reuse all the JavaScript and all the form API stuff came over with very little change. So if you've got a module that's more UI-based and more of a form-space module, you're going to have a pretty easy time at it. And then, of course, we had the Config Packager providing a lot of the core code, and then I wrote a bunch of new code to make it all work together. So it was a very fun project. Highly recommend getting involved in D8. So we talked about, let's just summarize. So D8 or Features, we're violating a couple CMI rules in Features. If you have Features turned on, and I mentioned if you have a module marked as a Feature, it's going to let you enable that even if it has existing config. It allows you to have duplicate config across multiple modules so you can make copies, but that's only temporary. So those are the two things that are kind of CMI rules that Features needed to work around. And then, of course, you can import. Your module config is no longer just your initial config. You've got that import function now so you can overwrite with new changes. So we're now using Features. The way it was intended to bundle functionality into reusable modules, it's a development module. You don't need it on production. It has some new functionality that's kind of cool for suggesting features and auto-creating features and kind of like CMI, it just works. So if you want to get involved, we're currently in Alpha 3. I pushed this about a week ago for Beta 15 of D8. I expect a new, are they going to do a new Beta before I see one? Probably, who knows. If there's a new version, we'll keep this updated. There have been some changes going on in Core and 3s referred to them as kind of the single big issue that's left in terms of some of the, for the developer guys in the room, some of the safe markup stuff. I've had to kind of update features to keep up with that. So there will be updates. What we're waiting on, so I review the code, make suggestions. If you really want to help, help us with testing. There is an issue that I posted here which is kind of the meta issue for the automated testing of features. That's a Beta blocker. I'm not going to release a Beta version without automated testing. I'm not the greatest guy when it comes to automated tests, so I would love for some help on that. That will get us pushed to Beta status. Once we're in Beta status, then we'll be able to preserve any kind of compatibility as we move forward in the Drupal chain, which is also what RC is going to give us in D8, by the way. What, the reason why RC1 is so important is it's going to give us upgrade paths from RC1 to RC2 and RC3. If you've been playing in the Beta world of D8, every time a Beta comes out, you're kind of on your own for doing updates. So help if you can, and now we can finally stop hating features and start loving Drupal 8. If you want to learn more, Alex, who's the current lead of the CMI team, he's going to go into a deep dot of configuration management on Wednesday. There was a great talk on configuration deployment. That's already happened, but I didn't know that until I updated the slides this morning. But you'll be able to find that video online if you want to go see deployment. So that talks about really how you deploy. If you're really interested in how do you go from dev to stage to prod, now that we're not using features for that, we're using CMI for that, that's the talk you want. And go to D8 sessions. Learn about D8, start using D8. It's time for D8. So with that, open it up for questions. And for questions, there's a mic back there, or I can repeat things. Thanks for your introduction into features, because to be honest, I was always asking myself, why do we still need features for Drupal 8? Now I know more, and I see why it might be better than just having CMI purely. My question is, first of all, I want to invite you to join my session on Thursday, where I talk about the experiences we made while developing distributions. And I will tell you why we think feature... I only talk about Drupal 7, and I will tell you mainly that building a distribution that should be a base for somebody else to start his project on, you should not use features because then the other person has a really hard time overriding. I know there's stuff like F-Tools Unlink and there's features overrides, but they, in very complex projects, they don't work out so nice. So I suggest some solution that we have on Thursday, and I was hoping that when I visit your session today, I could give an outlook on how it would be on Drupal 8, but now I don't feel it would solve that problem that when there is a feature, you cannot override much. Yeah, so yeah, just to respond, I mean, I do the open atrium distribution, which is one of the largest distributions of Drupal, and I think you can use features. Actually, we use them all the time because features override, as a module, does mostly work. It's got similar caveats to features in that it depends upon a lot of modules to support it properly, and there's some that don't, like Panelizer doesn't really support it very well. What you just have to be careful of in your distribution is your distribution can use features. Your distribution can't use features overriding. In atrium, that's particularly an issue because atrium is built on Panopoly, and Panopoly has features, and so in atrium, we want to override the Panopoly feature, but then people can't override our atrium features. So, you know, it can get complicated, but it can work. It does take effort to make it work. I think it's going to be a lot easier in D8. We're looking forward to porting atrium to D8 here in the coming months, and I think, you know, features was a blocker, actually, if you talk to the Panopoly people as well, they couldn't release Panopoly on D8 without the new features. Atrium is the same way. So distributions are still going to use features even in D8. I think having a cleaner way to do overrides is going to be super important, and I kind of alluded to how I think we're looking at doing that with doing layered merging of these YAML files and much more of kind of a get merge method. So I think the future is going to be a little better. But yeah, I'll come to the session Thursday and take a listen. Then I'm excited what you have to say about what we did in the design. Cool. See, there was a question over here that I can repeat. Oh, same question. Wow, a miracle. Yes. I missed the last part. Is features ready for translated configuration? That's a really good question, especially here in Barcelona. So the translation stuff in D8, if there's a session, I think right after this on the translation that I highly encourage you to go to, because that's another core initiative that I think has done a good job and done a lot. Because they worked with CMI on that and they did some things in CMI specifically to support translations, that should automatically work with features because features doesn't need to get into it at that low level anymore. It basically is calling CMI functions. So I think we're okay. I haven't personally tried it yet but personal translation, I'm kind of waiting to get feedback on it. But I'm hoping that's the case. Now they did do some little tricks that essentially are like overrides to do language specific versions of configuration. But they didn't do that in kind of a generic override mechanism that we can reuse for like normal overrides. So kind of pros and cons of that. But I think it should just work. And as far as it's ready, even though it's alpha, it's fully functional. It doesn't get in stuff like that. So it might be, if a new version of Drupal comes out, it might be a week or two before I kind of get in and patch it so there's some potential downtime there. But since it's just a development module, we shouldn't care as much, right? Other questions? Yup, back there. So the question to repeat it is why does CMI give you that exception when you try to install a module that has existing configuration? Like why did they build it that way? As to why they actually made it an exception error, which for non-developers is you kind of worry when you see a general exception error when you type a drush command, right? But you have to understand the CMI guys, I said in the beginning, they had a very specific set of goals and very specific set of rules. One of their rules was in D8 the site owns the configuration. In D7, we're used to the modules owning the configuration, especially when we work with features. So people are getting used to. The site owns the configuration. The configuration that exists in your active directory, in your site's config, wherever you tell it to store your staging, that is the configuration. If you go into one of those files and you change the site name, the site name is changed. And so they didn't want modules to own configuration because they were trying to get away from this problem of not knowing who's in charge. They didn't want to know who's in charge or configuration or any of that kind of stuff. They want you to just have it one place so they can do that import-export. That allowed them to keep CMI really clean, which is really important when you have it in core. You wouldn't want something like features in core because it's not the fundamental piece that's needed there. So back to your question, why they went as far as making it an exception instead of mainly you can read the issue queue about why they did it that way. I personally kind of disagreed with making it that level of an exception. It could have just been informational. But again, they're trying to make it easier for people that aren't developers and aren't doing features to manage their site. Any other questions? Great, well thanks very much for coming. Have a great time in Barcelona. I should remind you to please rate the session. If you go to the session page on the website, there will be an evaluation button. It's really important. It was actually your evaluations from the people that went to Drupalcon LA that got me here as an encore for Barcelona. So thank you very much. But yeah, please go rate. That's how we make Drupalcons better.