 is the talk Agile Drupal 8 builds, doing the most without PHP. This is a talk that David and I sort of have been chatting a lot about Drupal 8 being released and sort of both working at Pantheon and seeing a lot of our customers and partners make and start to develop Drupal 8 sites, sort of trying to think about what kind of development practices and development patterns are gonna make the most sense for this new CMS. That we've both been doing Drupal a very long time and we've seen a lot of different kinds of ways to make sites and I would sort of put forward today that building a Drupal 8 site is going to be a different kind of process for developers and site builders than doing in previous versions of Drupal. So this is a talk, it's not the most advanced talk I think either of us have given, but I think it has a lot of interesting components and it's very much a sort of action oriented example-rated attempt to sort of put out there a sort of philosophy that we feel is appropriate for building Drupal 8 sites and to sort of talk about some of the challenges that we face sort of doing some of their own construction with that. So in terms of introductions, my name is Matt Cheney. I work on the magical platform, this Pantheon, been doing that for about five years, which means I have a lot of experience obviously on the server side, but also actually working with a lot of people here in this room and at this conference who use us to actually build the websites of their dreams and the dreams of their friends, families and followers. I also very much believe in the power of site building, in the power of people who aren't extremely technical, who aren't gonna write a lot of code to leverage open source technologies. That I think that we've been building something very great in the Drupal community over the last 10 years, but I think it needs to be increasing and accessible to other people who aren't technical as sort of coders, that we have the power to build gooey interfaces to do a lot of things that previously you would have to write code. So to that end, I absolutely love the work that Omiles had done both with views and with panels. Huge advocate of panels as a sort of solution for site building and spend a lot of time with David Snowpeck and others building a technology solution called Panopoly that I'll talk about today, which is basically an attempt to bundle a lot of functionality together, provided out of the box, really great drag and drop building experience for sites. And it's the kind of thing that I had seen a lot of folks find success in actually doing. And I think the Drupal 8 will even empower stuff bigger and I'm excited to be here today to share sort of my understanding of working with Drupal 8 site to take some questions and start that conversation. And I'm David Strauss. I worked on the design of Drupal 8's configuration management system. And my real goal with all of this stuff is to harmonize the easy and tough use cases of Drupal, where historically we've had situations where you would either do a completely different method for doing the really complex advanced way, and you would have some sort of basic way that serious site designers would look down on. And I think that we can really harmonize those approaches in ways where you can build professional sites and you can configure them through the GUI. And you can deliver things faster to customers, faster to uses of Drupal. This is how we stay competitive against projects like WordPress. It's also how we stay competitive against everything from up the stack for SaaS products, like Weebly, et cetera, that allow you to configure your way to a site, and down the stack against frameworks that are based entirely on you pulling up a shell and coding. So that this is a talk sort of about getting back to basics with respect to building websites. That Drupal is, at its core, a CMS. It's designed to manage and display content, and it does that increasingly well. That you can use Drupal for other things than just content management, folks do often with great success. But I think that the kinds of problems that I'm interested in solving and interested in helping other people solve are sort of information problems. That before I was in Drupal doing technology work, I was a librarian, and a lot of those kind of problems, I think, are very analogous to problems in tech, that we're better as people if we know more things, if we can access more information, if we can share, and I think that sort of open source tools like Drupal help us to accomplish that. And after sort of 10 plus years of very serious Drupal development, we have some really great tools to use, that there's a lot of genius has been put into this framework, and a lot of people and use cases have been solved in meaningful ways that we can all benefit from today to accomplish our work. And I think that's the job of many of us in the room, that we're building sites for people who have to share information, we're helping them to manage their content and let other people know about it, and that we want to find the best approaches for it, which is probably one of the reasons that you're in this talk today. But one of the crazy things about Drupal is that you can do all this other crazy stuff with it. Like it's not just about simple content creation, that you have all of these tools, like increasing tools at your disposal, and you can make wild sites with Drupal. And I've done a bunch of crazy stuff with Drupal. I've done Drupal 5 Arabic sites on USB keys that get shipped off to do weird stuff, make crazy internets for a bunch of people to share files, even made a website for donuts for my friends just to make crazy maps happen. And I think in each of those cases you had these really complicated use cases that you had to choose in many cases very weird pathways to actually accomplish sort of common tasks. And I think that's one of the really crazy things about Drupal is that because you could do everything, which is awesome, it can sometimes take away from sort of the base functionality. Because while in this room we're all building different kinds of sites for different kinds of people, many of the structures and functionalities of sites are actually very, very similar. We have a blog system, we have a commenting system, like we have some sort of image gallery. Like these are common use cases that as Drupal you can get and build them, but you can build them in a lot of different ways. And I think that is actually and can be very confusing for people. Not only as they start out to build these kinds of systems, but as they actually maintain and support them over the long run, which is a problem sort of in terms of web hosting and web platform work we see a lot. So, it's 2016, I want to build like a basic website with content. Some of this stuff should be easy, should be released right forward. But in many cases I think it's not. That if you look at some of the websites and you've seen a lot of these things, Drupal 6, Drupal 7 sites, we're talking sites that have hundreds of contributed modules from dozens of different developers that have a lot of different crazy releases. And that people sort of start off projects really just like throwing code at the problem. And I think that that contributes to a lot of sort of you know, cruft and difficulty and maintenance going forward. So, an apologies to Emma Goldman for putting her on this slide at a business conference, but I wanted to throw out a radical idea here that when we're talking about development and we're talking about starting a Drupal 8 site to actually build a website for someone that I think that I'd like to propose that you start with and maybe even end with just using the Drupal 8 core module set. That you'll still end up writing some code. You'll use your twig templates to do some HTML, CSS and JavaScript. Some cases to do actually very complicated and custom things. And you do may end up using a contrib project or two as part of your work. But I think that there is a real value in trying to keep the development work that you do as close to a sort of Drupal core solution as possible. I don't actually think this was true and I'll sort of explain that. In previous versions of Drupal, but I do think that in Drupal 8, it's true. Because when we talk about writing custom code, writing custom PHP, I just put to you, I mean, isn't the 237,000 lines of PHP in Drupal 8 enough for your project? Do you need more code? Do you wanna support more code? Do you wanna maintain more code? I mean, in some cases, yes, of course you do. But I think that for the first time in the history of Drupal, I feel we have what is actually a complete content management system that we can actually roll out Drupal 8 and make a real website that looks and feels and does the kinds of stuff that users expect in 2016. It also has the advantage, in the case of Drupal 8 core, that it's the code base, the project, that's actually, that has the highest quality code in the entire ecosystem. Better than any, most, you know, contrib projects and it has the smartest and some of the most dedicated people working on it. And I don't wanna, I mean, I contrib is wonderful and it's an amazing part of the Drupal ecosystem, but there is this sort of magic that happens with Drupal core that it is this unified development process that it has a set of very explicit standards for how things are developed. And you have this very like regular release cycle that like on any given Wednesday you could get a new version of Drupal and it can get better stuff along with that, security, bug fixes, features like that. And with solutions like Pantheon or Drush or other places you just click one button to update your core, you get all of that value as part of just a regular process. And I think that that's actually something that as developers in terms of building we can gain a lot of advantage starting from that point. But as we maintain these sites over the long run we can have a lot of sustainability with that kind of solution. Because this is true in Drupal 8 but it was not something that was true in Drupal 7 or before. Here's some usage statistics just between Drupal core itself and views as a contributed project. And if you look at this sort of 80% of all Drupal 7 websites had to install the views module in order to actually do any of the things that they wanted to or to do things that they wanted to do on their site that you know, and I'd also question of it, 20% that weren't using views sort of what exactly those sites were doing. I mean, maybe awesome stuff for sure but the idea that you needed to have contrib you absolutely had to have contrib to build sites. And this creates a lot of problems honestly in terms of development and maintenance. There's some clear discoverability issues when we're talking about getting new people in the ecosystem to say, hey, you should use Drupal. So they go out and download Drupal and they try to do it and they don't have views so they don't know what really to do. And they'll eventually find it, many do but many also give up and that's frustrating obviously because we put a lot of time and energy in making Drupal great. The same thing is also true in terms of actually maintaining your site. If you have one, two, three or four contrib projects suddenly your development practice is now hinged not only around cores release cycle and cores practices but also this contrib projects as well. And you put some crazy Legos together to try to make sites. You try to make something really cool but up until Drupal 8, it was really hard to get something that was really something awesome out of the box. And I think sort of as software consumers people who are using website technologies, building stuff we want something really awesome out of the box. We want a really good first time user experience for developers, for site builders, for end users, for everybody. That the internet's grown a lot and I think one of the challenges that Drupal faces is that it is a very customized kind of tool set and it's increasingly competing against SaaS sort of web solutions that allow you to log in and have really fantastic user experiences to build Facebook profiles or Yelp pages or these kinds of other kinds of things. And that when you looked at something like Drupal 6, Drupal 7 that sort of first time user experience was very lacking, that you didn't have these core components as part of the solution. You had to find other stuff and that even with inside of the core product like in Drupal 6 and 7, you had these what seemed to be obvious pathways like I want polls, so I have a poll module or I want blogs, so I have a blog module or I want a forum, so I have a forum module that were ultimately inadequate solutions for many cases for those projects that you wanted something like flag module that you could do a lot more stuff with, their blog you wanted to build up your own content type and list it with views. These are things that made people who are first time developers very frustrated and I think part of growing the community in the ecosystem is having solutions that actually get to a point where I can start with it, I can be successful with it and I can deploy a site because I think that's sort of what we all want. So this is something that I tried to do with some other folks in Drupal 7 doing a sort of distribution of Drupal called Panopoli, which I quite love. It started out as a project with the University of California at Berkeley to build a sort of distribution of Drupal for university sites, but it quickly came to be that like, while there was some cool university functionality we had in there, a lot of the sort of generalized starting point technology was actually applicable well beyond that. That the idea with Panopoli was that we could provide a sort of single foundation, a single out of the box product that you could download and install. And it was Drupal, it had a lot of cool stuff in it, but it was one thing and when it came out in a new version, you could update it and get all of those updates. And it was a good foundation for site building. It had a lot of really awesome tools. And it sort of looked like this. We had Drupal 7 as a core sort of core stack. We had some modules on top and then we actually sort of created these different pieces of functionality, like responsive layouts and media integration and administrative dashboard, WYSIWYG and stuff like this. And the important thing was that like, none of these solutions I would say we're like A plus kind of things, but they were all pretty good. And they were all extendable in ways that actually helped developers, but it let them start much higher up the stack. And I think that's one lesson sort of from working in technology for the last decade is that when we're doing development, it's important to try to like, you know, stand on the shoulders of other people who have done stuff before, that you don't need to reinvent the wheel, that you're doing your best work when you're leveraging other people's talents. And I think that's sort of part of what I think is awesome in Drupal 8 and part of what Panopoli is trying to do in Drupal 7. Because things like selecting even modules to start with on a site could be very frustrating. That like, you know, in many cases, you would need to have dozens of modules on a Drupal 6 site to build a lot of the kind of functionality you wanted. And that because different modules, you know, had competitive kind of solutions and that integrating them together was a little bit of a challenge, it was hard. So part of what we did in Panopoli was to actually pick the modules that we thought were really good and actually sort of put them together. And that was important because there are things that you would like do in Drupal, like you would like want to like make like a link or something or you want to make a date field. But you didn't know about link module and you didn't know about date module. So you just make a text field and like just like slap in the information into that field but it wouldn't validate, it wouldn't display right and it would be very frustrating. You know, and then in terms of adding these things, it wasn't just about putting these modules and turning them on, it was about harmonizing them with the permission systems and the roles we had, it was about tracking key patches across the modules for review and it was making sure everything worked well together. It was also important for Panopoli, we wanted to build these like site building features, things that I think in Drupal 8, you know, we're going to have very nice analogies to sort of going forward, that this is a panel's IP, let you do some drag and drop stuff and there was, you know, a lot of other functionality that we did sort of using blocks. With Drupal 8, we have a much better block system, we have a lot of these kind of functionalities already baked in. We also made it in top of an administration system that looks a lot like some of the Drupal 8 stuff as well, as well as the WYSIWYG system, sort of that came out of the box because as a content management system, solving core content management problems, having a WYSIWYG is like a necessary component of that solution and it wasn't until Drupal 8 that we actually had that solution and that I think in my view was a really big gap. So I don't want to go too far down, there's a lot of features that we had like built out as part of this, things like responsive layouts that Drupal 8 does as well that are important to what we're sort of trying to do. But this is the kind of stuff that I think that, you know, I thought about a lot in the Drupal 8 cycle and spent a lot of time trying to build because having that sort of out of the box solution was really important and it got a lot of pickup, people were excited about using it. It wasn't like, you know, everyone using it like views, but we had a lot of people who saw Monopoly as a good starting place because it had that foundation. And I put to you that like that was really awesome and it was good work and there was a lot of nice patterns that came out of it, but making that all happen was really difficult. And I think that like when you sort of talk about developing a site where you're molding a lot of modules together, getting all of that to work together can be really hard. This is the info file from our like WYSIWYG integration where we're talking about like 15 or something different dependency modules that all need to be put together to do things like handling imagery sizing and media integration and security and all this other stuff. And that, you know, that was a lot of work and something that I think, you know, a lot of developers struggle to do. They're reinventing the wheel and not leveraging other stuff by trying to like figure out this recipe. And I think that that's some, you know, not so great. So what I would say is sort of, you know, to wrap this kind of section up, I think there were some lessons I learned for trying to build an out of the box solution in Drupal 7 that I think are very relevant to why Drupal 8 is the right solution to start with as a sort of core product. The first is that, you know, having a big development core team is really important. That at Panopoli, we had about half a dozen people who would help, which was awesome. But, you know, this limited the ability of velocity features and, you know, integrations just because you don't have as many folks. We also had some really serious challenges dealing with actually putting configuration into code and, you know, getting something like that working. That it wasn't just about, you know, making sure we had a feature that bundled the config, but allowing it to be easily overextended and modified as it sort of went on. We also had really interesting challenges dealing with code quality and structure varying across projects. That not all contrib projects were the same. Many of them had different release cycles and they could change based on the release, which could of course come out at any time. There also was a real sort of difficulty in centralizing this work. I think this is actually one of the problems in the Drupal ecosystem is that you have so many modules and so many fiefdoms of development that actually getting people to sort of work and harmonize together can be really tricky. That, you know, you have a bunch of different issue queues you have to deal with, so it's hard to sort of get people together. But sort of to get into Drupal 8, that this there's a lot of hope that Drupal 8 solves these problems. That having, you know, that sort of base solution you can roll with can be really awesome. And that, you know, I think a lot of what Panopoli is trying to do with Drupal 8 already does out of the box and that is fantastic. So what does it do? Of course, you know, instead of having just a small development team, we actually have a, you know, whole core team. Oh. Sorry. People. Or not. Okay, sorry. Let me just blow up for the thing. Do you want to control slides? There we go. All going down. So same thing in Drupal 7. Sorry. That like having a bigger core development team is way better. Having the WYSIWYG supported by a group of much larger people helps everybody sort of contribute and extend to that. Having configuration management in Drupal 8 core makes actually bundling and setting your configuration be really, really easy. That code quality and structure has actually improved greatly in Drupal 8 because you have Drupal core standards that are imposed pretty rigorously on all the code that goes in. And you have that centralized issue queue that actually has all of the different people working together. So you can easily find bugs and track patches and this kind of thing. And that you have this out of the box experience that's really awesome. That, you know, I think, you know, there's a lot of things Drupal 8 can do out of the box. I encourage you to sort of go that way. Because this is sort of the build methodology that we're trying to present here. That, you know, we want, when you're actually doing a site, I'd like you to consider the idea of beginning development with just Drupal 8 core. Build as much as possible. Spend as much time building out your solution in that core solution as possible. Do add a contrib project or two and maybe custom code if you absolutely have to. But think very critically about that because that's code that you're gonna be supporting and maintaining over the course of your project and handing off to anyone who maintains it afterwards. I already see some people noticing this, but this is probably the most important slide in the deck which is that since Drupal 8 is so capable of doing so many of the things for site building out of the box, that it's really worth revisiting to see whether you can do it out of core rather than making your first visit for figuring out Drupal 8 to the contrib repository. Yeah, it actually was sort of chatting with someone prior to this and they had talked about their Drupal 6 site where they had had 166 modules on the site and they moved over to Drupal 8 and I think they ended up with 12 modules on the site. And that's huge because the maintenance kind of burden on that is way less. That I've had plenty of frustrations where I have a site with a ton of modules and I'll do like a drush mass update of all the modules and stuff will break. And I don't even know what breaks. I have to like sort of manually go in and update this. Did it break? Update this. Okay, it didn't break when I did this other one at the same time. It did total disaster. This is a much I think cleaner approach and something that'll create more stable and sustainable code because the Drupal 8 core process, update process is very well tested, well supported. Some of the contrib space may not be as much. So this is sort of where we're going. This is sort of the overview of that kind of philosophy. I think sort of to get into some of the details, I'll throw David in a minute. We sort of actually decided we built a few sort of Drupal 8 projects but we decided to actually build an actual Drupal 8 website to sort of see, could we put this methodology into practice? How do we feel about that? So we're both fans of like doing crazy projects, of course. And so we thought we'd do like a Drupal clone of Kickstarter, which is a crowdfunding kind of website. You post a project and people support it and they get some benefits for it and this kind of thing. And importantly, this allowed us to pick a set of criteria for building a site that wasn't just designed from the beginning to be easily satisfiable with Drupal 8. It meant that we would have to solve some hard use cases. We'd have to run into a few walls and we'd ultimately have to figure out how to solve them either with core or contrib and all given the basis of this presentation all without with avoiding writing any PHP. And so we had some problems and content sort of solutions we had to deal with. We needed to have some user profiles with relatively rich information about each person who was like proposing projects or supporting projects. We had to actually have the projects themselves that were relatively complicated data models. They included some videos for people to talk about the projects they wanted to be fun. There's a blog to talk about stuff. There was categorization of the projects so there was some discoverability. We had perks where if you back something you actually could get some benefit and then we actually need to let people back stuff and pay for that as well, which is sort of part of the Kickstarter kind of tool set. And it's a complicated site. They have a lot of developers working on Kickstarter. And we didn't build an exact phone, but this is a real use case you might actually need to do for somebody. And beyond just the actual content, there actually is this functionality that needs to happen that people actually do need to actually submit a project and there needs to be some sort of review sort of process around it. People need to be able to post a blog with some sort of usability to it. You actually need to be defined to fulfill perks as project owners in a secure way where you're not also adding perks to other projects. People need to be able to sign up, you need to be able to search and you actually do that backing and post a video using like actual secure practices of posting stuff online. But we did build a site. This is our site in question. It had that article blog system, had a project submission workflow of sorts. It had a project characterization system, project to fill up some fulfillment, let people back, let people pay, had user accounts. And we had this twig based theme from Zymphonies that we found that we sort of adapted to make this all work with the blog system, which was really great. So this is the kind of thing I think you could be asked to do for your clients and your customers. And I'll turn it over to David to sort of walk us through that build and some of the issues we faced with it. So this is mostly a success story. And then we'll go into some of the caveats right after where there were some areas where we had to wade through a little bit of mud more than we think is really ideal for the experience. So in the spirit of starting with core, we started with Drugate, just pure Drupal installed it. And getting the installed copies of course the first step to success with Drupal 8. But right after that, wow this copy is a little small for me to actually see so I might have to turn around a little bit. So one of the first things that we did is we created a project content type. The backbone of any kind of Kickstarter clone is that you have projects. So by creating a project content type, we would allow people to do things like posting the description of the project. And one of the things that Kickstarter requires these days is listing the risks associated with the project. Now, Drupal 6 and even Drupal 7 a little bit, this can be a little challenging to do, especially if you want to offer formatting for this stuff. But in Drupal 8, it's as simple as adding a second long text field to allow people to create a risk section. And by default that has a GUI interface, you're able to add bullet points, you're able to add images, all of this is handled as part of core. So we're actually really far along already in allowing people to post projects to the site, format their presentation of it. And we have a few more things that we want to do with this project, like allowing people to post videos, but we'll get into that later. The next thing that really is the backbone of a Kickstarter-style site is offering perks for projects, where if you give $100 or more to this project, you get perk X and Y, if you give $1,000 you get these additional things. We can't quite support people paying for them out of core, but the first thing that we can do is we can start looking at how we allow people to create this. And what we did is we first created a perk content type out of the box that includes a title for it and a body that you can include bullet points of what you get. And at this point, in terms of very simple site building, which is core, we've installed it and we have two content types. The things that we still need to accomplish to get this Kickstarter clone going is we have to be able to link perks to projects. People should only be able to create perks for their own projects. People should be able to buy those perks from a project that they're browsing from the listing of those perks on the project page. And people should be able to post a video that's showing a preview of their project. So we can actually still keep trudging forward with just core at this point. We can create a view to list projects. What this means is we go into the kind of structure of the site, we create a view. Some of the basic options for creating a view are that it's for content types. And in this case, we select just project content types. So out of the box, this view is just gonna list all projects, or sorry, perks. Yeah, perks. So, no, sorry, I'm just getting confused about the relationship. Yes, this view is to list projects so that we can associate them with the perks. So out of the box, this is going to list all projects site-wide. But what we actually wanna do is, if you can quite see it in there, the name of this view is My Projects because you should only be able to create perks for your own projects. So after creating this view, we have to do a couple more things before we can actually make it so that perks can be associated with someone's project. We can create a conditional filter on the view where we filter for only the projects that that person owns. So that means that if you created a project before, you're gonna be able to see that project as one of your options for creating a perk. And then down in validation, there's a validator that you would have to have edit access to that user that owns the project in order to be able to actually add perks to that project. And this prevents someone from possibly changing the parameters of the view and introducing a perk for a project they don't own. This also would mean that admins could create perks for projects that they don't own, but that's okay because they're admins. So we've configured a couple options in here. And then the last thing we have to do is actually make it available as an entity reference view because out of the box when you create a view, you only have a couple options, a page, and a block. But if you want it to be able to be showing as options on something else, then you have to create it as an entity reference. And then that creates, converts this base view into an entity reference. Entity reference in Drupal means a relationship between one node to another. So now what we've done is we've created the foundation for us providing an option on another node to associate that node with one of your own projects. Additionally, if you're doing an entity reference because when Drupal does an entity reference field, it doesn't autocomplete things, so you can type in only a few letters of the name of something and pull it up. So you have to specify what it's searching on. In this case, we're just gonna have it search by title, but we have to actually actively configure that. So what this means now is that we have a view that we can make available as a widget on another node that will list only the projects that the owner owns and allow them to do a little autocomplete to pull up the projects that they own and then associate it with, and then we're gonna be associating it with perks. So the next step is pretty straightforward for this. We add another field to perks that is content. This just creates the basic reference and then we can configure that to use this view that we created as an entity reference. And what this now does for perks is in addition to having a title for the perk and a description of the perk, there's now a field that is an autocomplete that allows you to link that perk to one of your projects. So anyone can now go in and create a perk for one of their existing projects. But this isn't the end. We have the perks in the system now, but we want people to be able to actually see them next to a project, so we have to go through a few more steps. We're gonna create a new view as a block view that is going to list the perks for a specific project. And again, we hop back into this kind of conditional filter and this time, instead of filtering it by the current user, what we do is we filter it by the content ID in that reference field. So what that means is that every perk now that gets created is associated with a project. And we can do this filter in a way, even just through this GUI, in a way where we pull up every single perk that is associated with the project currently being viewed. And once that is completed, once we say that we wanna filter by the actual referenced project, we can go in and set the default to be the current content ID. And when you pull up a node on Drupal, that is the current content ID that you can filter by. So let's say someone pulls up a project page. It's project ID two in the system. And then we wanna find all the perks for project ID two. And here, what we can do is we can set up this filter where we pull up every perk that is associated with a project ID two. And then having done this, we've created a block in the system. This actually used to take an enormous amount of work in earlier versions of Drupal to get this far. You would basically have, we would have already pulled out the PHP at this point. But now we have a block, and we can hop right over to the block system in Drupal 8. Now, this is a bit different than the experience you might have expected on Drupal 7 or earlier, because on those earlier releases, we sort of listed all the blocks, and then there were unused ones at the bottom, and then you could assign them somewhere. But blocks in Drupal 8 that aren't used anywhere are actually hidden, and you have to click place block before they'll pull up the list. So if we click place block, in the case of the default Bartek theme, the sidebar second is the right sidebar on any kind of layout, and by default it has nothing in it, so it kind of collapses, but if you put something in it, it will appear. So we can place a block. We can do the block we just created, which is perks by project, which automatically shows the correct perks for a project. And then we can restrict it so that it only appears on project pages. So now, what we have is a setup where when you view a project, in the right hand bar of that project, it will show a listing of all perks associated with that project. So at this point, it actually took quite a few steps, but it was all possible through core to link perks to projects and list them on the project page. Now, I sort of picked this as a stopping point, because this is where we sort of hit a wall with core, because we wanted to do two things that core doesn't support directly right now, at least in a really good way, which is accepting payment for the perks and supporting videos on projects. You can kind of hack those things in, like maybe you could put something in the template where you hop over to PayPal with a form to pay for something, or you could allow people to just drop it in an arbitrary URL for a YouTube video, but we wanted to provide a better experience. We wanted to validate that data. We wanted to make it where it was responsive, where like when someone pulls up a project on their phone, it's rendering the video the right way for them, and on the desktop, it's rendering the video the right way for them. And the same thing for payments. We wanted a flexible thing where people could pick currency for their payments, and they could pick the actual provider that they were processing the payment through. So we'll start with the easier one, which is supporting for videos. So I show the two modules we pulled down here. You can do this in the GUI on Drupal as well, on Drupal 8, if you have right access to the file system. This, I'm just showing it here doing it with Drush, which is a way that you can do it with a command line. Often this is a really nice and fast way to do it because you don't actually have to download it to your desktop. You can just browse to, you can just connect up to Drush on a local or remote copy and then tell it to pull down the module. And Drush also pulls down the dependencies for you too, which is quite nice. Some of these modules might have two or three other ones that they require as well. So here I've pulled down two modules. I've pulled down Video Embed Field and Payment. Video Embed Field also is showing one of the other great things that's happened. A little bit in Drupal 7 and a lot in Drupal 8, which is better extension points for how modules are actually extending the tools that you have on the site. It used to be in the old era of say Drupal early, a lot of Drupal 7 and especially Drupal 6 and before that if someone wanted to extend a node, like with an edit form or a rendering thing, they would write a module and then they would do this thing called decorator pattern where they would basically have a hook that they would alter the form or the view of it on the fly. And it would be very unreliable for integrating various modules because they might be in an order you can't control. They might have their own individual settings for what node types they're on or other things like that. And now with fields, rather than trying to push it all the way onto the form, something can write a widget like payment form or this video field and they can get added wherever you want in the form to whatever content types you want and with the visualization of it that you want. And so having added the video field, we can now add a video embed to our project content type and then we can configure that. In this case, I've just allowed YouTube videos. It comes out of the box supporting a couple things and it has extensions to support about 15 other video services. But what this means is it'll validate what someone throws in there to make sure that it's actually a YouTube video and it's properly embeddable and it will handle everything from flash to iframe to HTML5 embedding of this video in the proper format for the proper devices without me having to write any code. So that adds the video field. I can go back into the interface and then choose where that video field appears when someone is creating a project or editing a project. I can also drag it up and down for the viewing of a project. If I want the video at the very top, I can have it there. If I want it at the bottom, I can have it there. All configured through the GUI. It got a little more complicated when we started wanting to accept payments on things but we started with the same approach where we looked for something where we could add it to the perks. And in the case of the payment module, it provides something called payment field which allows you to add a payment item to an existing content type in a way that's very lightweight. Payment is also used by the commerce module for more complicated things. But payment module, if you just want someone to be able to buy one thing, that's really all you need. Commerce module adds in things like shopping carts and order tracking and shipping and all sorts of other things that we didn't really necessarily want to track for someone just signing up for a perk. Because a lot of these perks are delivered digitally anyway. And a lot of people come to the site and buy one perk and then they leave. It's not usually the usual that you would go through multiple projects on Kickstarter in a row and sign up for multiple perks at a time. You could on this but it wouldn't be through a shopping cart. So the thing that got challenging here is that payment requires currency for doing conversion rates and supporting the different currencies of the world. And currency requires some composer-based modules. How many of you have worked with Composer? Okay, so like about five to 10% of the people in here. Composer has a complex relationship with Drupal 8 and I think this was one of the weaker spots that we ran into with this build. Because since currency has some composer dependencies neither Drush installing them nor installing them through Drupal's own GUI would handle pulling in the dependencies which meant we had to figure out a way to pull in the composer dependencies. There are various things that have happened in the ecosystem for this but we still see the anti-pattern that we saw before with there being different solutions being offered and contrib at different points in the life cycle of Drupal where for example there's Composer Manager which can do the job but even the author Composer Manager doesn't think it's really the right way to handle composer dependencies. So for at least this build we decided to go pretty lightweight and we basically just pulled up the composer.json file for currency and you can find out that something has composer dependencies by either trying to install it and noticing that it complains that it can't install yet or looking for a composer.json file in the modules directory. In this case so we cat to display that file and it turns out it has two external dependencies which are commerce currency and commerce currency exchange both pinned to the one point X series. So we can take that, I still have the bottom of that file at the top of here just to see that and we can do composer require and then add those dependencies which will add them to the composer.json for the basic project for Drupal. This can complicate some core updates so we're looking for better ways of doing that and this is kind of part of the call to action side of this stuff of figuring out how this should work for Drupal 8 but it does do the right thing it pulls down the dependencies and we added one more option here that might be useful to you especially if you are deploying to servers and working on your desktop which is the ignore platform rex option which basically says to composer even if I can't run these composer projects locally that's okay. Like a lot of composer projects are looking for things like PHP extensions or versions of PHP that you may not have on your desktop and there's no reason you actually have to have them on your desktop to install those dependencies and commit them to something like Git. So we got those, we downloaded them, we committed them to Git, we pushed them back up to the server and then we could install the modules. So from there we added the payment form field to perks. The payment form field allows listing, doing an item listing, a total and having a big button to basically say pay for this and then from there we basically configured it where it would be in the most basic mode possible where it would just provide a single button for payment with no other real options and then in terms of how users actually create their perks what we did is we hid a lot of the fields you would usually use for nodes because perks don't really need their own URLs and in this case we didn't want any of the other fields in terms of authorship, et cetera. Those aren't that important for tracking there. It might be nice to have internally but not for display and then for the payment form importantly we changed it to a drop down selection list versus the normal view which allows you to put as many line items as you want on it because by its very nature a perk is one line item. So this means that users get a pretty simple form for creating them. So here's what we see in terms of the final project form. We have fortunately the resolution of this kind of mingles a little bit but you have the title, you have the preview which is the YouTube link for the video, you have the body and then you have the risks section and we've made the risks section required so that people have to publish some risks of them getting the project done successfully and this is all being delivered in a way where it will render with the video with it has WYSIWYG for editing both the risks and the body content for it and this gets associated with the user in a way where they can add perks to it later and then the final perk form has the title, it has the body to describe what the perks are that come with that package and then down at the bottom you can see that you can select a currency and put an amount. There's a little bit on here that we probably wouldn't we would have liked to have a little simpler but you can put the currency, you can put the amount, you can put the quantity and you can put a description for how that line item appears when someone actually goes to check out and then at the very bottom you actually see the project thing for the reference for that does the auto lookup so all I have to do is start typing in my space and then it pulls up my project, I can select that and then that creates a perk for my project and then the final view of a project view before we actually added in any kind of theming is that you can now pull up a project you can see that it embeds the video properly it shows the description, it shows the risks and then on the right hand side you actually see the first perk that we created which is my new perk and you can see the description that it has and you can see a little bit more cruft than we would have liked for the perk in the sense that you actually see a sort of as if it's an order with one item in it but this is just kind of emphasizing what direction we would see going forward with theming on Drupal 8 because traditionally in Drupal 7 and before the way you would theme things is you would send a sort of kind of node ID or something very lightweight to the theme layer and then the theme layer would often make a bunch of API calls to find all the data that it wanted to actually render and then that meant you had to work with a lot of PHP in the theme area the nice thing about this mode here is that this data that you see going in the perk view is what's getting handed to the theme layer and now all that's required is editing a twig template and removing the information that we don't want to render so before you would send a tiny bit of information to the theme layer and make a bunch of API calls now what we'd recommend for Drupal 8 is send at least what you need in the theme layer and then trim it down from there and that makes a much clearer development path of how the data gets rendered in that twig template it doesn't require you to work with any PHP in the theming layer and it means that you can deliver this sort of functionality without any PHP at all at least it's written by you so with that we will open the floor to questions with just the basic I guess closing statement of like if you're building new projects on Drupal give Drupal 8 a shot and give just the vanilla core a shot to see how far you can get with that before you dive into contrived and then also of course dive into contrived before you start writing your own custom PHP yes sir nodes are entities oh but I mean I don't know if there's a way to do that quite in the GUI the I'm not I wouldn't I would admit that I'm not an expert quite in that area but I will say that one thing about all the steps that we took is that you can export the configuration of all of that with configuration management in Drupal 8 and manage it safely and then also for the nodes you do still have the ability to to alter things in Drupal and provide changed renderings if you need to simplify things beyond what you can do in the GUI awesome other than that thank you so much for attending our talk and we hope everybody have a fantastic DrupalCon New Orleans