 Okay, so today we're going to talk a little bit about front end conundrums, how to decide how to implement something in the front end with Drupal. And I don't know if I'm the only one who comes across these conundrums, but there's often many ways to do things in Drupal, and often as a front end developer it's a question of whether to do something with theming or whether to do something with configuration site building. So I'm going to go through some examples in this in this session, and if you have thoughts or if you have additional conundrums that you face that you want to talk about there'll be lots of time I think at the end, so we'll have lots of time for questions and we can discuss other examples. Sorry? I don't have a mic. Can you hear me okay? Can you hear me? I like this. Is this better? Yeah? Sorry? Oh, it's being recorded here. Just red things. Everything we're saying is being recorded. You can hear me in the back. Is it okay? You can also come closer to the mic. Okay. Great. So just as an introduction for those of you who I haven't met yet, my name is Suzanne Degacheva. I work at Evolving Web where I Drupal Development Shop based in Montreal, and I do a lot of Drupal trains that I have to work on Drupal projects. So I do some sub-theming, some site building, and sometimes some module development. And my Twitter handle is Suzanne underscore Kennedy if you want to follow me and keep track of what I'm up to. So at Evolving Web we do projects for all kinds of clients, some government, some university, some nonprofit for profit. So quite a variety. And just as a quick pitch to you if you are interested in Drupal training, or if you know anyone who is, we have some training coming up in Ottawa in September. And so if you are all interested in learning more about Drupal 18, module development, site building, come talk to me, or you can sign more on our website. Okay, so to get to the content of the session, so we're going to be talking about approaches to Drupal front end. And so just to start off, to get us all on the same page, I want to talk about what that means, like what approaches are available. Well, someone really doesn't like front end. Well, approaches to front end, front end techniques, whether this comes into play is usually that moment when you get the design for the project, or maybe you're just starting off with the wire brings, or maybe you just have some very rough mock-ups that you're using to implement the site. Or maybe the client or the designer just says, oh, just make it look like this other website. So it's that moment when you get that design, whatever it is, and you have to take that and start seeing the site building, start seeing the feed. So how many of you here are specific learners? Okay, I'm going to go over them. And how many of you are site builders? What do the rest of you do? So maybe some of you are aware all of that. You're like, site builder, a seamer, you do the modules about where you keep the lights on. Yeah, so in any other case, sometimes, gamers tend to like more doing things in beams, actually, like writing templates and things. And sometimes site builders are looking more for the site building approach to something. But a lot of times when you're implementing the front end of the site, there's this breakdown between things that you're doing in a theme, things that you're writing in code, and then things that you're doing through configuration. So building views, making content types, image styles, site blocks, all of those things. But it tends to be the same person who does both of these things in conjunction. So anyone who calls himself a seamer typically also does a lot of configuration because in truthful, even if you like to keep these things separate, you still have a lot of interplay between the two. So theming techniques tend to be more on the side of writing templates, maybe adding through process functions, setting up background images, actually creating regions, and of course writing CMS and JavaScript. So usually you're doing both of them at the same time. So the question is more not about like, are you doing configuration or theming? You're probably doing both. The question is like, are you trying to do what fits more into the theme side or are you trying to do things strictly with configuration when you can? So I'm going to walk through specific examples, but this tends to be kind of the question that I'm asking. So part of planning your first end approach, part of deciding what to do in the theme and what to do through configuration, it depends on your situation. So are you going to be maintaining this site yourself or is it a whole team of people who's going to be meeting you? Or are you building it and then passing it on to a client? So who's doing the maintenance? Do they make a big difference? Maybe you feel very comfortable with the theme, where you template, so are you the effect? So maybe the person maintaining the site is going to have a hard time with that. The configuration management workflow. So who here is familiar with configuration management? Half of people. The idea is that in Drupal 8, when you're building through or you're configuring your site, you're adding your views, you're adding your content types, you're setting up deals, every time you do that, those changes go into the database, right? So Drupal is the content management system that the content goes into the database, but also all of these configurations. But when you're actually in the launcher site and the site is up and running, it's possible to export all that configuration and so put it into the code and then let's say move that from your development site to your production site. So in Drupal 8, this configuration piece is really easy to separate out from your client. And that means that you can set up a workflow so that when you're running your site, you can have a configuration that you take from development put it into production really easily. So if you have a good workflow for that setup, it's going to be easy for you to move configuration around. But if it turns out that there's a lot of people out of the configuration on the live site, it then might be harder for you to manage. So it's important when you're actually having your front-end approach to know where the configuration is going to be happening when the site is launched and if you're going to need a configuration Another thing to consider is whether you expect the visual design to change and evolve. This is a hard question to answer usually. You get the design and you say, oh yeah, the design is, it's final, right? Final design, like the PDF. The PDF says final. But sometimes final isn't really final. So if you expect things to change, this might mean that you want to make the site more flexible. So you might be looking for a more configurable approach rather than hard coding things into code. And then another question to ask is if you need to make something to study. So if you're going to be using the same kind of look and feel for multiple sites and you need to make something into a study, that means that it's got to be really easy to switch on an officer now. So for example, if you have some brand new colors that you're using throughout your theme and that needs to be a setting of the changes inside the site, that's an important thing to know what you're implementing in front of the design. So that's just another thing to keep in mind. So these are questions we're going to be asking ourselves as we go through and actually look at the different scenarios that we face. So the types of things that I'm going to be talking about and what I'm talking about is just some examples, but there's lots more examples that fall into all these categories. So when you're implementing, let's say the layer of content, there's content for certain content types, how does the site know where the fields actually go on that page. You have to deal with HTML so if you know, or if your SEO friend tells you you have to make a certain element in H2, how do you do that? You do it with a template, you do it with a face. Images, so often designs are full of visual images and we have to figure out if they should be backline images or inline images or if they should be added through a view just how do you get those images to show up on the page. Blocks places, so where blocks are, how blocks know where they're here on the page, adding JavaScript to our site and then also setting up web forms. So if you have a lot of forms on your site you might be doing a lot of form styling where they go back. I'm going to be showing a bunch of screenshots with little snippets of design and then we're going to talk about how we could implement this. So it's kind of taken a bit out of context, so this is the header of a page so imagine a little page and this is just the header and a lot of the pages on the site have a main, well obviously a page title, but they also have a video that needs to go up into the header. So the question is how do we build this site? So we've got a page title, we've got our video and then we've got some kind of breadcrumbs here as well. Another example of something really similar, so I'm sure you've all seen design that has big content headers like this. So this is another kind of banner at the top of a page where it's a page with school board content type and here we've got an address there and we're going to go to a website and we've got a whole bunch of content about this page that's up along with the page title. So if you really wanted to do this the theme way, one approach would be to create a template for the page title and add some content to it. So that second example that had the school address and the link to the website and the background image those are all things that are being added kind of around the page title. And in verse 8 the page title is already a block. It's something that we can see. It's got a template file just for the page title itself as well as for the whole page title block. So it would be possible to go in and modify that template and add some extra components like that background image and like the extra yield. A more configuration way to do it would be to create a view to display these things. So let's say we have the page title as a block already but maybe we don't want to use that block. We can leave that block disabled for this particular page and instead we can create a view to display all these elements. So if you're going with a view approach you would go ahead and create a view with a contextual filter that says take the title of this page take the address for the content, the link and the background image and print those all out as fields and then they can be styled like this and displayed as a block on the page. So the view approach is probably a lot simpler but it means walking out that page title block with this view version on these pages and it just means that you have a different way of creating page titles on schoolwork pages than all the other pages at the site. So typically which approach do you choose? Again it kind of depends on the site there's also some planning ahead that you'd want to do. You want to look at other pages on the site and see if they fall into the same kind of pattern. If other pages also have extra data that are added in the page title but typically I would find that the views approach would be a lot simpler because if you were to create a template file out of this the template file would be quite complicated and maybe hard for other people to manage. The advantage of doing it with a template file is that then any time you go and apply the same theme to other sites you kind of get the same functionality. But in this case because the template file would have so much content logic in it it might not be worth that trade off. So in this case I'd say that the views approach, the configuration approach would win out in most cases. So my next example is looking at a node layout. So this is an example from a site that has a lot of articles on it and each article has the image of the article at the top and then on the left there's some fields and on the right there's some fields and and so there's kind of a layout for each of these articles there. Another example here is for a product content type this isn't a product that you can buy. It's a product that the company will see and there's a guy named at the top you've got a title of the category, you've got some overview information and then some supporting data on the right. So again sort of like a layout within the node. So each node of this type is going to follow this same layout. So for creating a layout for a node and here I'm talking about creating a layout for all the nodes of a particular content type. So it's not necessarily something like as flexible as a a panelizer approach where you have a different layout for every single piece of content. With this requirement you can take a pretty aesthetic approach and create a node template for the content type. So for the product, just for the article you could say okay here's a a node template that places the fields where they need to be. So within that template file you could create the markup to create your two column layout that was maybe a header and then in there you can print out the different fields. And in Drupal 8, if you're using Drupal 8 the way to do this would be to pick the content render array which is what I was actually going to contain all the fields for the node and maybe split that up into a couple parts. So maybe you're going to print out most of the fields in one spot and then you take the rest of the fields and print them out where they need to go on the page. So that's the approach creating the node template. Another approach would be to define a layout in your scene. So there's a new exciting thing in Drupal 8, the Layouts initiative. And this allows any gamer modules to define Layout. And you might have done this already if you're a Drupal 8 friend and developer and you had maybe made some layouts with panels or you were looking at display seats in Layout. So in Drupal 8 there's one new system for creating Layouts that you can define. And then you can use the modules. These are two core experimental modules, Layout Discovery and Field Layout. And these allow you to place fields into a layout. So in that manage display tab that you normally use to pick four matters for your fields and put your fields into like a two-column layout or three-column layout or whatever kind of custom layout you create. So that would be definitely a more configuration style approach because you're setting up configuration on the site so that someone who uses a site builder can use those fields around. So it's probably going to be an approach that's a bit more easy for someone to change if they're not looking at. So if you expect additional fields to be added in the future that would be a much more sustainable approach than having somebody like that go in and update the template plan. So if we look again at the screenshot here like right now these are going to be link fields and right now there's just four of them. But in the future maybe there'll be another field over there in the second column. So making this a easy configuration to manage the layout would be a more sustainable approach. That being said the configuration approach this involves adding two modules and as I mentioned they're still experimental so take this approach with a grain of salt you would want to wait for these modules to be full four modules in order to use them on a production site but that being said it does still require an additional two additional modules and then actually coming up with the code for the layout. So it's not just this completely configuration approach there's still some work involved in your theme because you'd be defining that layout in your theme. Typically you want to define layouts in your theme instead of using the default Drupal layouts because that's going to allow you to control the responsiveness of the layout and make sure it's following the patterns of all the other layouts on your site. Content grids so often on your site often within the content of a page you'll have some kind of grid of content so for example this is from a home page content type and here we have three data points and they're placed into a three column grid so you've probably all seen designs that include this especially landing pages tend to have these kind of content that's displayed in three columns sometimes they're calls to action sometimes they're just text sometimes they're like selling points for a product they tend to be on marketing type pages but basically it's content that you're trying to put into a grid so the question is if you had these set up as deals how would you go about putting that into this kind of layout into this kind of grid so in either case one nice technique to start with would be using the paragraphs module if you haven't heard of the paragraphs module it's a way of studying out compound fields so just representing this content like having a three fields with a label the city number and that's a supporting text that's something that paragraphs manages really well because you can have a field that has three sub fields on it and so that's how I would recommend starting off in either case if you want to go and do a more configuration approach you can create a view to actually place the three columns on the page and a view is kind of a nice way to do this an easy way to do this because in Drupal 8 views come with a grid format so you can actually tell Drupal yeah make a view of this data and then just put the content of that view into a three column grid and you can tell views what classes to use so just taking a completely configuration approach you can come up with this three column grid of course you'd still have to write some CSS to get the different sizes and the typography and everything but you could do the layout part just with configuration a more theme style approach would involve placing the contents in a grid using a template so in Drupal 8 you have templates available for all kinds of fields that you're adding including paragraphs and so for this kind of content you have a template file that you could use for the paragraphs fields for all the data points and then you would also have a template file that you could use for each individual item and so if you wanted to put these into a grid you could add classes at either levels to do the grid and if you're using a CSS framework like Bootstrap you're going to have classes just apply to the template file or if you're writing the CSS from scratch you would add the classes and then write the CSS to float the items or to use a flexbox approach so in this case I really like the theming option a lot better because having a whole extra view just to display a field that's attached to the node that you're looking at is a little bit overkill to me but if you set this up as a view it would be easier for someone to come along and add maybe another field to the data points and then to integrate that easily into the view without touching the theme so for sure the configuration options are a bit more flexible the other advantage of the configuration option is that as soon as something's a view it means that you can display it as a block on the page so if you've got this landing page where you have these data points and you might eventually need to move it up the page or down the page just having it available as a block means that you have that flexibility whereas it's something to feel it can only be displayed within the node itself so you can't intermingle it with other blocks so it's just a slightly different way of displaying the data that suits your site's needs better so for example if you have this on a landing page and you have another block on the landing page that you've placed and you want to choose a below that block that would be really easy to do with the configuration approach and a bit harder to do with the view okay also on the topic of outputting your content outputting your node you want to change the html output of specific fields so this is an example from a book content type which has a lot of fields I kind of just truncated this this is the first part of the book page and this just shows a few of the fields that are attached to the book so this is a website for a publishing company so each book has a lot of data associated with it like number of pages the IDN number the link to buy the book at this point an external link and then different attributes of whatever the part to cover available in the book so there's really a lot of data data associated with the books and if you just create the content type for a book and you have the normal managed display setting so each field is just displayed one after the other but in actual fact the way that we want the book data to be displayed is a lot more sophisticated than that so some of the fields for example further down the page are collapsed some of them have to be transformed into links some of them have different formatting that has to be applied to them and even just in a simple example from the top there's a whole bunch of fields that have to be like inline, some of them bold some of them are these pipes between the fields and so this will be impossible to do just with simple configuration of fields through managed display like you have to place some other approach to get the fields to show up like this so two approaches we can look at so if you create a node template for the book obviously you can create a template that would take those fields and make them inline and add the pipe there's quite a bit of code you'd actually have to include because a lot of the fields for this book are optional and so if there's a field missing you'd have to make sure that it's still rendered correctly on the configuration side you could create a view of the contextual filter and use that to trace the fields for the current node on the page so it might seem a little bit overkill to create views to display the fields for the current node but it does make it quite flexible because as you might know with views you can really override each Tima output of each field so if you were creating this with a view you would just be using the fields option in views to show show fields instead of showing a teaser or a full node and then for each field you would have control over changing HTML making the fields inline and using different formatters that are available for the fields in the first place also for Drupal 8 if you're using views to add these types of fields you can use twig, so twig is the template language for Drupal 8 you can use the twig syntax right inside the views configuration so you can actually build a template file within the configuration for this content so that might beg the question are you doing theming or are you doing configuration, you're kind of doing both at the same time but you're doing it within the Drupal admin UI so it does make it more flexible again for someone else to come along and make those changes so in this case what approach would I take I find this one particularly tricky because I think the node template approach would be to a very complex template but the views approach would also lead to fairly complicated views and then our actual implementation for this my colleague created a whole set of views for the book page and so all the blocks were placed on the page and I had a bit of trouble figuring out what he had done so it's hard to pick the best approach in this case I'd say either case the key would be documentation so if you have a really complex content type and you're trying to display the fields in a very specific way you want to make sure that in your node template you add documentation and in your views you're also able to add documentation so in your view where you're combining a lot of fields together and you're manipulating the output you can change the label of fields that you're adding and that would allow you to actually build some documentation right into the configuration so if anyone else who comes along to edit the view is going to see oh yeah there's a field here that's called combined addition info and that would at least give me some indication that this field of the other case all the addition info are put together taking that extra time to document your approach in this case I think would be essential the other thing to consider is whether any of this work that you're doing could be reused so if you're doing a lot of work overwriting the output of the content type you want to make sure you know is this the only content type that you're doing this for or could this apply to multiple content types so if you're doing a node template you'd want to consider that maybe consider pointing to content types towards the same node template so you could reuse your work if needed and in the same way for the view you'd want to make sure that you were making the views components reusable if there was say like an e-book content type as well as a hardcover or a physical book content another topic that I come across all the time and I've often struggled with is the question of whether to use view modes when you're displaying a list of content or whether you're using fields and that's in your view so who here is familiar with view modes anyone created view modes before like custom view modes that I cite no okay so whenever I talk about view modes I think about like a media website like think of I don't know your favorite newspaper website you go to the front page and they might have many many lists of news and a lot of times those news items are displayed in different ways to make the site more exciting so you have maybe sometimes like a thumbnail of each one or sometimes there's a bit of text in the author's name or the column name sometimes there's maybe a bigger image or a smaller image and so one way to implement this if you're using Drupal is to have different view modes for each of those types of display so every time you're displaying the content you can say I want to show not just a teaser but like a mini teaser or I want to show a two line or I want to show the title and byline version so you might have different names for these and these will be the view modes you could use for your news the other way to print out a list of content in Drupal like if you're using View is to use fields so you can just go ahead and create your view with news and you can configure within that view that you want to display the title and the byline or you want to display the title and the image so it's basically the difference between using a teaser version of each node and using just whatever fields you feel like using so the nice thing about using view modes is that if you create a view mode once a view mode is something that you can reuse throughout your site so if you have a list of news on the homepage where you're using the thumbnail and a title then you could go ahead and use that on other landing pages throughout the site and you wouldn't have to reconfigure those fields so it just makes it into a more reusable but typically you can achieve the same thing with fields where you're just saying I want to print the title I want to print the summary text and I want to print the image this is another example of the same thing this uses view mode so these are kind of like events upcoming events in a view and so there's a view mode that prints out the image and prints out these fields and this can be also reused throughout the site so both of these methods include configuration but it's just a matter of which configuration approach you're taking and the configuration approach that uses view modes does allow you to I don't think I wrote this slide correctly but this does allow you to combine using like the view mode approach would allow you to have a template file for each of these to set up but then the view mode itself when you're using it you wouldn't be figuring it so the nice thing about view modes is if you're planning to add additional views in the future it would mean that you could just reuse those view modes and then the person setting up the view wouldn't have to do any kind of themes to make the fields look the way they should because the view mode is already going to be taking care of that so it would be to have a more consistent display of content in the context of adding views in the future and the advantage of doing the fields approach is that it's just more flexible, easier to set up to begin with and you don't have to worry about creating the view modes so one of them is easier kind of in the site build and one of them is going to be maybe easier to maintain Next we can talk a little bit about images so often on your site we kind of already looked at some examples of banners often on your site you don't have images but you want to manipulate and you can do this obviously with image styles so everyone here would probably know that you can change the size of an image before you display it by creating an image style but sometimes what you want to do with an image is to change the actual more like the not just the proportions but the actual display is used for a background image maybe you need to add an overlay up top so this I'm a green overlay, this is something that you could do with an image style there's a module called image style effects that allows you to add things like this completely and you can also do this with CFS so the configuration approach would be to use the module to generate a new image style with a green overlay and the more theming approach would be to do it with CFS and again the advantage of doing it with configuration is that you would then have an image style that you could reuse so if you had maybe use for green overlay for lots of different images on your site and you don't know yet where you want to use that it's really easy with an image style just to reuse an effect or reuse the image style itself in multiple places whereas with the CFS approach you'd have to create that overlay and then make sure that the overlay could be added to the other images so you have to work to do every time you add an image with the same styling to make sure that that works properly so the image style effects easier to reapply but a little bit more overhead because you have to have this extra module installed block placement is another category of conundrum situations that you might face so this is something that you typically run into even just looking at the wireframes for a site often learning pages or in the header of a splitter of a site you have to place blocks to get things showing up where you want so one of the things we run into as tumors is figuring out what you should use regions for so in this case in this footer area it's possible that we just have one region for the whole footer so we could in our theme just define the one footer region and then throw all the blocks into that region but you notice that in the footer there's the site back of the site that's made here on the left and then there's the contact information on the right so it would be a little bit more flexible if we had three regions so we have a region for the footer top a region for the footer left footer right and then footer bottom so we end up actually creating four regions for these four different blocks because even though they all have this flat background they're all at the bottom of the page they're placed in a bit of a different way so that's the question and then just float this block back or you can change the time to set up the four regions and this might happen in other places on your site you might have blocks that need to be placed into a grid and you wonder should I create six different regions for this or do I just create one region and then the blocks in that region just get floated or I use flex blocks in my CSS to put them into this grid so the configuration approach well it allows for more configuration I guess it also involves theming but it means that you can create a region for every part of the land and then you just place the block in the right region and it shows up in the right place this approach doesn't mean that you might have a bunch of regions on your site that only ever has a block so it might seem a little bit those regions might be a little bit useless the more being a heavy approach I guess is that you just configure the blocks and you get a region to behave in a certain way so you could say create a certain template file specifically for the blocks in a region or you could just use the CSS to do that floating and in that case you would just have to have good documentation to tell the site builder that when you put the blocks in this region they're going to behave like this they're going to go into a grid in the case of the footer example you would actually have to use specific block a block class or a block ID to say that this block needs to be pulled left and that needs to be pulled right so it might be a little bit more brittle because when someone comes along maybe they'll add a block but you need to try them and then your styling is going to get a bit messed up so it's maybe a less robust approach to do it that way tabs within your content so this maybe goes even beyond theming so you might have content on your site where you want to be breaking up the content into multiple pages so in this case there's pieces and constants are quite complex there's actually a separate page for each one, a separate tab and so there's different approaches you could use a module to accomplish this something like QuickTabs there's other modules that use JavaScript to accomplish something like this or you could actually create separate pages programmatically and this would mean blocks on each page just with configuration so the second approach is doesn't involve adding any extra modules so it's a bit more lightweight but it does mean that if you ever wanted to add a new tab you'd have to go back to your code and update that so again pros and cons probably more stable approach would be to do it programmatically but it wouldn't allow for flexibility in the future another example so menu icons so you might have a menu or even a view on your site where you're printing out icons and you see this often with more fancy menus like mega menus or with views that are trying to be a bit more visual and in this case there's an icon associated with each one so when you're building this out you're probably asking are these icons a fixed, is there a fixed set of icons are the icons always going to be the same are they going to be more items added do I need to add anyone in the future so you're trying to figure out how flexible does this need to be and I'm always really hesitant about adding icons to a theme because inevitably someone wants to change them or someone wants to add a new one or wants to go back and figure out how do I actually create these icon images how do I make sure they're consistent someone actually has to design a new one so it tends to be a little more brittle so if possible I tend to try and use some kind of existing icon set or something like font awesome which allows you to just use an existing font set to create the icon so super flexible so for the configuration approach if these were menu items you could set up a module that would allow you to configure a class for each item that would include the icon or if you wanted to do a more theming approach you could create a template file for each one but as soon as you create a template file for a menu item you're kind of setting yourself up for a disaster because menu items are actually content in Drupal and that means that there might be a new one added tomorrow so I would I would highly advise against any approach actually in theming that involves creating a template for a piece of content so that means like if you ever create a template file and it has a node ID in it or a taxonomy term ID or a menu item ID think twice like stop what you're doing and reassess if it's the only way to do it last thing I want to talk about is webform styling so how many of you have used webforms for Drupal 8 yeah so webforms is a great module webforms for Drupal 8 is like a a new thing like there's a lot of new stuff in there that's really awesome like I think you'll be really excited to try it out and one of the things about webforms if you haven't used them before webforms is just a way of generating forms of content on your site so each form is sort of like a piece of content because it's something you can easily create and manage but it also obviously is like configuration because you're configuring fields and in Drupal 8 webforms are more like configuration than ever before so it's a bit of a tricky thing to figure out whether to treat them as content or treat them as configuration and one issue I've run into with webforms is that often in the design of webform you want to treat certain elements specifically like in this case you're picking the subject of the form or sorry so you're saying like who are you are you just a general person are you a participant or are you a researcher so it's treating that differently it's putting it into an inline inline like the three radio buttons and so the question is how do you set this up because if you just hard code that in your CSS it's going to work great today but then what if someone comes along to the webform and adds another option and then there's no room for it there or what if someone replaces this field with something else and they want it to behave the same way they want it to be in the all in a row so it brings into question like should you be putting this CSS for this form into your theme or should you be trying to fit it into the configuration of the webform because the webform itself has this configuration and the design is sort of linked with the configuration itself so if someone's going to come along and change this tomorrow they should be able to change the design as well so the webform configuration for Drupal 8 actually allows you to add a lot of styling and so it would be possible to do it there and for me as a like adding styling in configuration always feels wrong but if you're treating your webform more as content more as something that might evolve and change that might be a more flexible approach and then the theming approach would be more to put this CSS into the theme itself and that would just mean you have to make sure that you're adding new forms or changing the fields okay I lied there's one last thing JavaScript so there's lots of modules for Drupal that add JavaScript libraries so this example here is like an FAQ page and it uses views accordion to display the FAQ item so you can open and close each one and alternative would be to actually add the JavaScript library or some custom JavaScript to yourself and to do that in your theme so configuration approach is to add a module, the theming approach is to add the JavaScript to yourself and either way is perfectly acceptable in Drupal but the first approach might mean that you end up with a lot of modules on your site and you might be able to do something a bit cleaner if you add the JavaScript to yourself one thing I just want to point out is that for Drupal 8 it's really easy to manage libraries in your theme so you can set up a library for accordion JavaScript and you could say that is only going to load on this set of pages so you have a lot of control over how that JavaScript is used so you don't have to worry about kind of bloating your site like you might have worried about previously in Drupal 7 you could do kind of the same thing with Drupal add JS but in Drupal 8 it's just much more integrated with the whole theme system so I find it's a bit easier to do so one last note before I close in Drupal 8 when you create a configuration you are managing it as code so typically if you're setting up a configuration workflow like I mentioned at the beginning like every time that you edit a view or every time that you edit a node or it's not no no a content type the ideal workflow is for you to take that and export it and put it into your version control so this distinction that I'm making between theming and configuration it's important because there's people who are comfortable with beaming and configuration and configuration is a more you know it's a more accessible thing for a lot of people but at the same time in an ideal world you would actually be taking that configuration exporting it to these YAML files and committing it which you know it sounds a lot to me like a developer task so it's not necessarily like putting something into configuration just means that anyone can do it and it's easy to do in Drupal 8 typically anything that's configuration is part of this configuration management workflow and so it's something that it's managed more like code so I just want to point that out because it's kind of a new thing for Drupal 8 and it's it's going to change how you work, how you do these types of changes after your site is launched so I I covered a few examples today that lots of other things like this but what I hope that you'll take away from this is just this sense of like making a decision so when you're implementing the front end of your site when you're deciding whether you're going to do something with beaming you're going to do something with configuration that you ask yourself these questions like what you expect on the site what you did, do you expect it to change who's going to maintain it thinking through these things when you start to build is going to help you build something that's more maintainable in the long run and even if you make all the same decisions I think you'll maybe have a better sort of just mindset of like looking at the theme and knowing what's in there tracking what you're doing and making sense of the decisions that you're making might make the decisions more confident I guess is what I'm trying to so thanks so much for attending if you are interested I'll just put these dates back up on the board and I don't know how much time I have left but if you have any questions I'd love to or ideas I'd love to give I have 5 minutes so apparently 3 3 minutes oh yeah so I guess a lot of the decisions come down to sometimes preference one thing I like to do related things together I mean the web form that you talked about has a CSS theme or the CSS is able to convey and I guess I'm leaning towards having the CSS convey the web form because it's to get from the CSS of the theme to go and modify the web form and it feels like you have to know where to find it exactly yeah and that's a similar workflow with the content types like if you're adding a field to a content type ideally that field would go some more logical and if you have the layout right there in the content type convey that someone can see oh I added this field and it was placed here that's why it's showing here so it kind of puts things more together so yeah it's a great one any other thoughts? if you have any questions or any feedback about the talk please come find me after while you wandering around and thank you so much for your time