 All right, welcome to Limbering Up Drupal 8. First of all, if you are here by any chance for where are my margins and why don't I drive a Tesla, there was a mix up with the rooms and that presentation is taking place in 280 to 281. So we do have to leave, we won't be offended. But if you're here for Limbering Up Drupal 8, today we're going to be talking about making your content admins lives easier with flexible layouts, WYSIWYG templates and more. So this is an update to a session we previously presented in 2015. For Drupal 7. And now that Drupal 8 is out and is pretty stable, we're updating it to talk about how you can accomplish it in Drupal 8 now with the options we have available, as well as how things have changed between Drupal 7 and Drupal 8. So first, I'm a cat cool. I'm the director of technology at a design and development firm in DC, formerly known as Rock Creek and now known as Chief. And I'm Clay Marshall. I'm a senior technical consultant for Chief, but also manage director of a company in Portland, Oregon named Tressel Media. So what we found in our years of doing Drupal development is that the key to winning over your content admins and therefore your clients is finding out what they do often and then making it as easy as possible. We've been doing Drupal since about 2006. We started in the dark ages with Drupal 4 and have been doing it ever since. And what has stayed pretty constant as Drupal has changed is that content admins want to be able to do their job simply and they don't want to have to think about the development. So it's very easy to make this a straightforward experience if you have, for example, just a body field and a few fields. But we're usually working on really complex systems that have diverse content. So you have a need for a featured article to look very different from a regular article, and if you don't offer them flexibility, they're gonna see your system as an hindrance to getting their content online rather than as a tool to help them do it. So in the past, we've needed to handle a lot of layouts. It's really easy to be tempted to do that with a lot of content types. So you have one content type for an article, another for one with a two column header, another content type if you want to throw a video up at the top. And this gets pretty unwieldy pretty quickly. First, it's annoying for content admins to have to figure out what content types to use, and secondly, there's still a lot of rigidity with what you can put where. You're not truly making it flexible, you're just giving a lot of really predefined restricted options. The second way that people often try to make Drupal more flexible is by telling their admins, well, you can always go to the source view and you can control things there. And it should be pretty self-explanatory why this is a terrible idea just by looking at this mess. Even if you are a developer, you have no code hinting to help you out. And telling your content admins they need to know HTML and CSS is a surefire way to make them hate you. So what we want to do is to simplify choosing layouts, adding media to our articles we need to, and adding pre-formatted content snippets so people can be flexible without just being completely visually inconsistent and turning to code per node to accomplish their styling. And finally, we want to talk at the end a little bit about our approach to managing content and how having some empathy for our content admins has sharpened our development process and led us to creating more options for them. The goal of all this is to build a system that lets your content admins be contextual. They are thinking about the content. They are not thinking about the development. So if the development you're doing restricts what they're able to perform, then you're going to be setting yourself up for inherent tension between your system and their goals. Back when we presented this in 2015, this was our only goal for the presentation, but now we have a bonus goal which is making it work in Drupal 8. So within Drupal 7 we had worked for years obviously trying to find an appropriate way to do this and make things easier for content admins. When we said we want to do this talk at this time, of course the great push is we want to do this and show some relevance in Drupal 8 and where we're going with this. That's a lot of challenges. I mean we're working a lot of times as you all have known and seen all week, I'm sure, with modules that haven't quite reached a level of maturity that we need. We're using lots of dev status of modules, even in one case a pre-dev status, something that hasn't been released essentially out of a sandbox to try to accomplish the same things that we did in Drupal 7 in Drupal 8. So our disclaimer here is that this and our approach we believe is straightforward and correct. It's going to continue to evolve how you do this over the next days, weeks, months as it goes along as these individual modules mature and as we have even more defined uses for media in the way we use it in Drupal. So the question is how do we create initially flexible layouts for Drupal when sometimes we need something that's as Kat was saying that's just a regular article and sometimes we need things that are more like a feature-based article and we have some examples here of what we're talking about. So we're going to start out by showing you some examples from the New York Times. I have to tell you, sadly, a chief did not develop NewYorkTimes.com, but we're going to use it as an example anyway because they have a really good use of content here. So this is an example of a regular article on the Times and Sider site. You can see that they're making good use of media. They have these large header images. But the point of this page is to capture you and to propel you not only here but also into other sections of the site. So when you are working on these articles, you don't often want them to be an island. You want them to be an entry point so that you can experience that content elsewhere as well. So here at the top, we've got related content in the right hand sidebar. We've got related content. We've got information about Times and Sider itself, alongside a good use of graphics and, you know, shareability here. If you scroll down even further, you can see that they're even using a video. The video is perfectly usable, perfectly playable, but it's not a very immersive experience. On the other hand, they also have big featured articles that take over the experience completely. So here, that image gets dramatically bigger. And part of the reason why it's able to do that is that we blow away the distractions. Rather than having related content everywhere, as you scroll down, you see that it's just text. Really, you're experiencing this and nothing else. Which is you're thinking about the UX and the design for your site is worth thinking about whether you have areas where this needs to be accomplished. Are you trying to capture them and drive them elsewhere? Or are you trying to retain their information throughout a long featured piece? So here, as we scroll down, we're starting the playback of that video. And then we're continuing to see another really large contextual image in the content. And if our Wi-Fi was working a bit faster, you'd also see a giant ad. So there's that. Here on the right, we do have some related content, but it's very contextual and very intended to bring you along in the series. So in Drupal, we can also recreate this, and we're going to show you an example of it before we start showing you how we did it. So within this case, we have essentially the same approach. We're using them appropriately in Mardi Gras Indian here. For a display of a large feature image, we have the same sort of structured content where we want to have a clear focus of the article we're trying to display here. We're going to be embedding things like audio files, embedding videos inside. I'm giving you some structured, like, separate kind of layouts that we have and give a little more interest in the article. Embedding media in the sidebar. And along with these particular items, also, nested little whizzy-wig HTML templates in the sidebar. So the way that we did this initially is like describing, you know, we obviously want to have a way that we have an article that we can create and have that article exist in a couple different states. We want it to be able to, at times, exist as a regular article with the same way without much work, putting in that sort of blown-out feature display. So the way we're doing that initially is we're handling those layout changes through panels. We're basically defining custom layouts for them in code. We're creating variants that use those layouts and define those layouts. And then we use selection rules about when we want to activate those layouts depending on the content item we're looking in its context of the website. So in Drupal 7, we did this very similar the way we're doing Drupal 8. Obviously, we used panels in the Panels UI that came within that. And we used Page Manager, which is part of SeaTools at the time, to actually use other UI to be able to create panels, panel variants and selection rules for them. Drupal 8, same tools, essentially. They're all a little bit different now. We have panels without a UI, just the Panels API. We have the Layout plugin that helps us instantiate and create code-based forms of layout that then get pulled into the site. We just define them in our theme. And then we use the Page Manager, it's no longer part of SeaTools. It's been pulled out in its own contrib module. And on the first site where we were using panels here, I went in to try and add a panel structure in Drupal 8. And I thought that the UI just had not caught up at all. The reason for that is, as Clay mentioned, before, Page Manager was part of SeaTools and was very universal. And now it's broken out into its own module. So be prepared as you're doing this to go find all three of these independently and then line them up in order to get the experience that you're used to. So what you're seeing here is actually a YAML file that is used within the theme. And this is what's defined in the layouts that we use. And you see here an example of that, an article with a sidebar that has, it belongs in the category of article. Because these layouts will show up whether you're using panels in Page Manager or whether you're using DisplaySuite. They become available throughout the whole system. So when we create something, we give it a category. So when it shows up in that list, you can define that, oh, these are my article ones. And then within those, we can then define, okay, where do they exist? And so we put them in our theme file in a layout slash article and we can attach separate CSS. We define a machine name for this region. It's the same way we always define regions in a theme before. We're just going to say, oh, look, these exist. Here's what they called. And this is what creates and records that layout within the system. If we look at what was that, let me go back one, actually. In this path where we've got the path to the layout slash article, that's where it's going to look for the twig file that's actually going to say, how do we draw this out? When you call me and you want me, this is this actual layout, what does that structure look like? And we look at here what an article sidebar HTML twig file looks like. It's pretty basic. It's a bunch of divs, just wrappers holding things. And we have these nice little twigs, same as just pulling in, okay, I want the content primary here and I want the region for content sidebar here. And that's all we're doing with structuring a twig file for its layout. You'll see in the next one, we've got the article sidebar header and the only difference here is that we're going to put a hero region on top of these two sidebars. So we can have that hero stretch across and have a sidebar in a right column right there underneath of it. And lastly is the feature where we're just setting everything. I just want a hero and I want my content. And everything unique I'm going to do within my content in the WYSIWYG itself. So then we get into the UI part that we do in Drupal. Here under page manager, we have the node view page and this renders every request for a node page as you can see at the path up there. Node slash one, two, three is going to take you here. So because we don't want the same layout for every single node, we define variance. And these variants are based off a field that we're going to use as a background. Article is feature, article is feature with video, image and sidebar and header. So this is defining what our options are and then we define selection conditions that say when each of them are going to be activated. So here you can see that we're activating it any time it's article slash feature and any time the node bundle is article. And back in the day you used to be able to define this based on fields in Drupal 7. So rather than having to say what path you would simply say show this to me any time this field value is article with feature, that hasn't caught up with Drupal 8 yet, but you can do a work around based on path. So we're combining path auto to put a token from that field into the URL and render it that way. It's still very flexible and as long as you have the redirect module, updating those paths later is no big deal. Finally, you're going to say now that this selection rule is active and we're showing this particular page, what do we want to do with it? So here in that header hero image we're rendering a view block to show that big hero outside the content area, and then at the bottom we're still showing the typical entity view content which is what you see everywhere. That is your content area in Drupal 8. It replaces that main system block in Drupal 7. So for our first demo we're going to demo just essentially creating a basic article. I mean I have content already created for that. So if we look at here I've created an article and I'm just going to edit it quickly. You'll see it's constructed as familiar as you're all with Drupal. It has a title. It has in this case the layout type where I decided I wanted an article with a sidebar. I've attached a large image for a top that can be used in either cases whether in the content itself or as a hero image. And then we have just regular text underneath of it. I've given it a category here just because I want a taxonomy term so I can find a relationship so I can have some related items. And when we save this item you'll see that it's layout as you saw before is the image that's in place that we uploaded. So that's still using the regular image field that we have there. We know that we want an image in this article type. It's always going to be in the header there. We've defined that. We have here the main article side and we just have related content that shows in the sidebar. Now the thing is that perhaps this came from an actual use case of a client of ours that actually took content and moved it through its site depending on what it was. So they create the first item and it may be that this is my feature article week so I want to create a feature view of this. But later on it would turn into a regular article and fall into a flow of a display like this. So what we had to do in that case is actually we just edit the layout here. In this particular case I'm going to add an additional image here. And the reason is because in this case I want to simply be able to give admins the ability to create a carousel if they want to. So if you just add more than one we're going to get a carousel from it and he changes the layout to feature and we save it. And we'll see that our experience changes instead to this large feature display where everything is here in the main column with the focus content just like Kat talked about in the New York Times article. We have in here a carousel display that gets put on just from adding an additional image. And this is just our carousel. We're just basically this view if it has multiple images we'll pull an our carousel and we'll give you the carousel controls you need at that time. And then we have just the regular content layout and we have this guy at the bottom. For some reason I don't know, I think that there's one guy at Wikipedia and it looks like that. But as we build this in this demo out we're going to show you we're going to add more items to this. It's going to build it out more like the New York Times article. But that's how we actually are able to switch pretty simply between the different layouts. If I go back and edit it again and I say that, you know, okay this has changed its purpose here. It's actually now going to fall into some sort of medium state where it actually needs to be, I want to have it be prominent but not that prominent. We can do things where we change the sidebar with header and save it again. And we get the header at the top and we get the sidebar on the side. So it's just another option to provide people for layout. These are very simple examples of layout changes. You can do a lot more. You could add anything you wanted in the sidebar blocks if you're but we're trying to give you just clear structured examples of how this could work. The other example we have is when we look at the actual examples of video. We also, if you looked at when I edited this field, actually I'm going to edit because I want to change this back to a feature. I have the option here to add a hero video. In that example can be found not there. Sorry, I lost my titles. Where if we add a video, I just have the view here saying basically show me the carousel view if it's only images. If you have a video you can render this view instead. In this case we have here just a standard background but because it's layout changed it has a class that's been added to it. I can also do things with the H1 and say this is in a class of a different display. I want to show the H1 like this. I have a subhead in this case. I want to show it that way also. So now we've talked a bit about making the layouts more flexible but we want to talk about adding media to it. Step one is making it so it can move around and step two is making it so you can put it in the background. So when you talk to people about adding media and you're talking to a developer you're often going to get the response that you can add a simple image field at the top of the content type. I would be lying if I said I hadn't said this before back when I was a developer. So here we have that image field but the trouble is that that image field can only render above the body. If you're telling your content admins that this is the only way they can work with images eventually they're going to have to explain to them that you didn't think about or care about that particular use case. So talking to them up front about the kind of media they want to use and the way they want to use it will go a long way. Whether they need to embed images in the body that's a legitimate question to pose but we believe you should assume that they do because we are doing content management systems after all and images are content. So what we talk to them about is do you also need video? Do you also need audio? Do you want to look at the last 20 blog posts and say well you've never used a video or audio in all that time so we have no reason to think that it should be part of our user stories but if you have the conversation early then you can add that to your user stories and make time to test out the audio and video as well. The second thing we found is really important with clients is educating them about retina and why it matters. It's for some clients they're already ahead of the curve and the content admins already know about this and many of them they're redesigning a site that might be quite old and might be from before the time when retina became very popular and this constraint of needing to upload images that are twice as large as they actually are going to display can be very unfamiliar to them. So we can build it so that automatically things become responsive and friendly but in order to do that we have to be uploading a very large image. That's one and a half or two times as big as we need it to be and if you have a big design that is a 1,800 pixel wide image it's a very good idea to explain to them that this means they have to provide you something that's 3,200 pixels and if they can't support that then your design is going to need to be altered but hopefully they can and we're going to talk about how to achieve that. So in Drupal 7 when we gave the talk we recommended just embedding everything audio, video and images through the media module for two reasons. One, embedding images through CK Editor is pretty painful in Drupal 7 and secondly media got into a state where it was really mature media still had some bugs to work out but it was in a pretty good spot and we used a combination of these modules to accomplish our goal we did file uploads through file entity embedding through media obviously and then responsive images through break point and picture finally if we needed video we hooked up media YouTube or media Vimeo or media break code or Ustream or what have you and every one of those modules was a separate module and all of it was contrib. Unfortunately there is no media for Drupal 8 not yet and if you were at the keynote you may have heard Dries talking about some of the initiatives to improve media in Drupal 8 but we're not quite there yet and media is still catching up so for right now we have another cocktail of ways to do it in Drupal 8. First you can embed captioned images through the WYSIWYG which is a huge step forward we'll demonstrate in a moment and that's just out of the box functionality. The drawback is that they are not retina friendly so if you upload something that is 3200 pixels wide you're going to get something that's 3200 pixels wide no matter what kind of device you're viewing it on and if you upload something that's only good for desktop then obviously it's not going to play very nice with retina. Also you can't add any extra fields so if you need to add a caption or a credit you need to make the credit field required for example to encourage the admins to do that you can't do that through the solution in Drupal 8 we're using very similar approaches just some of the things that have changed we're doing we still rely on file entity to make files fieldable we still want to add custom fields to it even though the WYSIWYG does right now with CK editor it allows you to add a caption field and that caption field shows up everywhere we still have the approach and this came from some of our clients we were working with also that had even people that were just and all they did was manage media for the site so they would upload the file it was their job to make sure our credit was attached that it had the proper caption that it had all the proper references to it and it was managed as a separate content item so we have custom fields that we add that way we embed them through the entity embed module at this point we were using media for this before but the entity embed is the way we actually were doing it before media when it was node embed it's the same thing we're taking responsive images luckily and thankfully this is all built into core now and from what I've seen it works really well in core defining the break points within the YAML file works great and the responsive image module it seems a little simpler than it was before using our combination of modules so it's worked pretty well lastly we're embedding videos using the video embed field mainly because this has a video embed WYSIWYG sub module with it that has worked pretty well and it loads them in as responsive video players at the time that it loads that way so we have a link here to discussion on Drupal.org ideally when you took use the built in CK editor functions you would be able to place a WYSIWYG image and it would be responsive and it would know what it needs to do there's a lot of conversation in this thread about how they can do that they talked about earlier on moving into 8.2 to try to do it I didn't look again today but as of yesterday there was comments that were showing up in there a few hours ago that they were still talking about this how to get this done right now you can't do it in the CK editor tool it's not going to load in a responsive image so it may be fine for most use cases but if you know you need to have a responsive image in the WYSIWYG this is not going to do it so we have an example here same one we saw before what we've shown before we have these items placed in here this is an image here that's been uploaded as a file it has it's credit on the bottom caption on the bottom and it's embedded into the site that way along with a video file here and this is an audio embed that's been put in there using a standard audio HTML5 player so the way we're embedding the images as I started to say earlier we're configuring entity embed to place the images we basically entity embed module allows you to create separate embed buttons for what you need so we create one we say the only item we want here is a file of image type and we use that to place the images the break points instead of all been defined in the YAML file within your theme which is an appropriate place for it and it's been a pretty straightforward way to lay out what your break points would be we create image styles the way we always have at least for the past five years for me we define them as we need to not only for the way they are matching the design but also we set one X and two X multipliers for them to make sure we have retina friendly images and lastly to make an image responsive in our example here I had to create a preprocess function basically when an image is inside of an entity embed item we're basically getting in the way in preprocessing and rewriting that image as responsive for us I'll show you a snippet of code that we're using but essentially we're just saying don't render that image the way you want to here preprocessed render is a responsive image so here you can see when you configure entity embed how this renders in the UI it's found under a configuration content authoring text editor embed buttons and as Clay mentioned you can set this up to have as many embed buttons as you want here we have one for audio and one for image embed because video gets its own unique functionality when you go in there you can configure what types of entities it has available to it as well as what content types it can be used on then we're going into this breakpoints yaml file in a big, big divergence from Drupal 7 previously you defined what the breakpoint was in the theme but what multipliers that had and some other configuration got done in the UI and now with yaml handling config and Drupal 8 you don't have to do quite as many steps here and for more information on breakpoints in particular there was already a talk here this week that can be found online once those are posted and there's some documentation here on breakpoint to go a little bit deeper now with the breakpoints defined we go in, we define the image styles and then we define what Drupal 8 calls responsive image styles and what Drupal 7 called picture mapping so here we're saying that for the WYSIWYG large responsive image style we want to render the max 1200 by 600 image style for 1x and then the one that's twice that for the 2x so once this is configured as long as you upload something big enough it will be responsive automatically and here in core the whole reason why responsive images and breakpoints coming into core is so exciting is that for these fields on content types it handles it very well out of the box you just pick your responsive image style and you're done but for the file entity as clay alluded to a moment ago it doesn't have that responsive image option available instead it only has file image so that's why we're having to grab that and render it using this code right here to make that a little bit more adaptive across the screen sizes as I mentioned before the code here essentially is checking it's a valid image essentially we're just using an image build function here to basically make this a responsive image use a responsive theme for it whizzywig float is a responsive image idea I want to use with it and then I'm just using the URI as we're doing a pre-processed field option to actually determine which image needs to be responsive and then it's rendering that way so our demo once again we'll go back to our big article here the first thing I'll show you is just the standard whizzywig functionality so when we're looking here we have the option here the standard whizzywig button we basically are in chooser file it's great that we have alternative text here that's actually required forcing us to do this for accessibility which we often forget about and then we option to say we want a caption when we save this item we get a spotlight and then you just have the option here to edit your caption you can just choose whatever your caption here needs to be so jazz and save it and we have just standard embed it works fine in most cases I think that this would be a great improvement to capture an image before so we're really happy the way this goes I think that if they can expand this and get in the responsive images and find other ways to add other fields to it it'd be ideal because of our requirements for what we had though we had some different options where we want to embed an image instead with all that formatting involved so if we go expand our whizzywig and go a bit further down the page we can embed using our embed button here we're in image and we're going to choose this is all display suite so with image any kind of file we're just adding a display suite option to add the fields we want to have included with that we're choosing a display suite mode of whizzywig float left let's give it another alt text these are fields that continue to appear but we're not rendering them here we're using basically the view mode and the style that's wrapped around it to add our CSS to position it correctly we wanted it, it has the credit where it was it's pretty close to display on the front end it's a little bit different the CK editor it's always been able to use custom CSS in it it's a bit easier I think now you can define it in the theme itself just which CSS you want CK editor to use so in this case I'm loading in saying just use style CSS and then I have another CK editor file that's overriding some of the things that look different to see in the whizzywig and then saving this item here this left has its credit nicely showing now looking a little better with its caption underneath of it if we want to actually add it and add in audio and video I have separate embeds for that so if we add position here where we want to add an audio file in this case we're just going to float it left we're going to use the controls here for this one and that gets positioned and if we want to add a video file we're quite filling this up it's a little bit difficult to get it all to fit sometimes basically same thing with YouTube and media YouTube or media Vimo just using the path to the file itself we don't want to play when you use responsive video see it gets placed it's showing an approximate positioning it has a caption at the bottom that does not render it's sort of just helping you along in the whizzywig showing you what you have there and then if we save this item you'll see that those items rendered as we expected with the video in place and we have the server embedding all those separate items the one thing I will say with media is that these are all one thing with media I was able to define and style and apply display suite options to all these things so essentially you would have just one embed button you just pick what you wanted to do I know that there's some sort of trying to consensus about how we want to handle media in Drupal I think it's going to be really important that as that moves forward but if we can get a consent unified way we want to approach it the same way approach content types I think it will be in much better shape with it so with media coming in and the content templates predefined occasionally there are going to be little chunks of content that are important to show because you want to maintain some visual consistency but you don't want it all to be happening the exact same way every time again we're going to our old friend the New York Times for a few examples of how this can be done well so here we have a really basic text that's thrown onto it but occasionally we make it more complex and here we've got a header coming in as well as some stylized text and a link and then here we're blowing it out because that quote is really important to the context of the article and deserves a lot of extra impact and attention and finally we have my favorite graphic on Trump destroying America with a little graphic and then a link so again people are able to embed small graphics but not able to make that really contextual within it so for all four of these options the essential thing we want to do is make sure that we are in control of what kind of pre-formatted content chunks admins can apply but then we give them the freedom to do that wherever and however they want to do it so we have relied on a module called WYSIWYG API template plugin to achieve this and it's been really handy whenever a client knows for example that they want to have some pre-structured content but they know they need some flexibility within that so for example we had one client who needed a list of publications and rather than doing fields in a field collection we knew that they were sometimes going to have a few lines of the citation there and sometimes not so we gave them a little bit more control over how that rendered and why for Drupal 8 we have a pre-dev version it's pre-release and can't be seen on the project page but you can get into it and because it is using such a light piece of functionality this is one that we're pretty comfortable using but you do need to make sure that you grab this CK editor content templates plugin and upload it to your library's folder first because otherwise you can have some difficulties trying to work with this module and by difficulties I mean it throws a giant error and doesn't do anything so that the links to this will be up afterward and you're welcome to grab the link from that if you ever do need it so once this is done we have this WYSIWYG templates option rendering here you can see that we've added a Google map option a sidebar block and a sidebar block slow load and the slow load in particular adds a little extra bit of style as you're scrolling down the page to make that feel like a more polished experience without having to have the admin actually go in and configure this every time because they're dropping in this pre-defined content that has the fade-in class and has the div already placed for them it takes a little bit off their plate so they don't have to remember how the structure works every time so we have a demonstration here of using some of those templates and we'll find some room to add it into our article here so once again editing the article as we go into the WYSIWYG you're going to see down here that there's this icon right here and that's the WYSIWYG template icon so we can insert a template by clicking that and the first one will insert just a regular sidebar content block so we click that and submit and you see it puts it in line once again picking up the styling that already exists hopefully showing it in a way that looks appropriate for an editor to recognize that the item is there I'm going to add one more item that's going to be that WYSIWYG float right our sidebar content slow load so it's going to be on the right and you well where is it, the thing is it's sitting out here when we have things floating right CKter is accommodating for it when they're floating left it's not helping with that so I let this sit out there because it looks, it's what I more would expect it to look like on the front end so I let it sit out there on the side and then we just save this and again these items can be placed or styled to break out a little bit to give it a little more interest there and you'll see this when this pulls up we've got a slow load on that item there and you can target these and mark them along your story as you're telling a longer feature article create these separate sidebar items sometimes they can be mapped sometimes they can be these little attached PDFs that relate to where you're on the content and just target them along the side and have them load that way and build a pretty nice feature experience it's a lot easier for content admins to understand even just with future training and governance having those pre-formatted reduces the amount of strain that is placed on new people who have to edit content so rather than telling them remember formatted in exactly this way use exactly this class they can train them by saying go use these kind of snippets and then customize the content within that which makes it a lot easier for them to move forward in that way I should show you just one other idea what this looks like when it actually gets embedded and ends yet in which if you're used to embedding media at all you know that it's a little unusual the way it writes in the content there for someone who's not a developer to understand what's happened there this is when these are embedded it's for someone with simple HTML skills even if they have to get in here again it's pretty straightforward I mean what they're getting at in the side here is really just that block and it's just putting it in their form with the appropriate formatting so if not careful and trying to lead it I'm not sure if you're into that if you want to get into the HTML itself in there so the last thing we're going to talk about is making it easier to manage content in general from a macro level what we found with content admins is that creating it is usually the first part of the process but then managing it afterward being able to edit it and interact with it also becomes very critical and it's been a really nice improvement in Drupal 8 in terms of how they can go and sort through content in the content view but right now they're still only allowing title, type and status I mentioned this because again for content admins finding this content afterward and being able to see patterns in it becomes really critical so right now if we wanted to see for example how we're using a taxonomy term you'd have to click into every single article but if you wanted to just find a word in the body of the text it's impossible to do that right now you can find it in the title but you can't find it in the body you had some really varied content administrative needs and they were used to using used to using word docs on their computer a little bit more to sort through it so they were asking us how can we just find the content that we want to be able to so we wound up creating an interface like this where we can search for anywhere that the body is talking about jazz but perhaps anywhere that the body is not talking about Dr. John we can narrow that down very rapidly because these two are exclusionary the level of reaction with content administrators to doing work like this can be a little bit surprising if you haven't experienced it before because it makes their jobs dramatically easier and it's only about five minutes of work for us so similarly you can look for anything that you yourself have edited and it's just exposing more of that data that we know is in the back end and we know how to get out with views but they often aren't very much aware of so here we take it a step farther and we start creating contextual administrative views that are targeted to individual content types we've been talking about the article content type up to this point and we've been talking about some fields that are really important to drive the experience one of them being what the layout type is and the other being what the tags are so here if I want to find every piece of featured content on the site especially if I'm working on a large site that wants a relatively few features this is something that you can drill down to immediately and pull that up and again if you want to find anything tagged with an individual term you can get at that as well so we've had a really strong reaction to doing this work for content admins that has made it easier for them to use the system so it's a technique that we share fairly often we're happy to take questions on that as well so the upshot of everything that we've been trying to do here is really making it easier for people to administer that content it's a technique and intuitive for them as we've seen Drupal 8 has had a lot of improvements but it still has a pretty long way to go so we're promoting the sprints of course that are happening tomorrow first time sprinter the mentored course sprint and the general sprints here on Friday we definitely encourage people who want to be involved with making this a bit more user friendly to go and join in those so thank you all for coming we're happy to take questions up at the microphone and we appreciate your time sure, we can repeat questions, modular data tables you mean entering data within the WYSIWYG and making that a bit easier to work with so we've done a couple different techniques for making them responsive the most common that we've done is adding in a JavaScript library to make it so that that can scroll from left to right I don't remember that off hand but if you want to come up after I can get the name of that for you and the second one we've done is rendering the tables as divs so we prefer that one a little bit less because it's less accessible so typically we do have the scrolling left to right tables and there are some for example with views you can go through and define a view table template and have it fall back to divs while it's rendered as tables for for people who are looking at on a desktop version hey I was wondering if there's any particular reason that you use panels instead of display suite I know they're not exactly the same but there's a lot of overlap and on recent sites I'm always told to use display suite and not use panels at all so probably the biggest disclaimer we could give about this whole presentation is that there are I could tell you three other ways to do this what we liked about the panels and from the way to before was exactly the page manager controls and the way we could set those variants very logically for us and because in the old part we could actually say when you're selecting and you had the appropriate you could select a selection criteria that was literally like I'm going to create any field and if this field has any value switch it to that thing and so it's a little bit immature right now the way it's doing it but that was the purpose of that we are using display suite like every time we render a separate entity item it is a display suite layout that we're using there all we're doing is placing blocks using panels in that structure there but we use them both together cat I think we forgot to mention at one point when you do add an image we're using those fields like wrapping a caption we're using display suite to add custom classes to it when we need to so it's a combination of both I would add to that though display suite is really useful when you're when you're trying to choose what renders where something is positioned when it renders this is making some if if else sort of statements so for example if we choose this then we want to render these fields and if not the other way so you can do that with view modes in display suite but then you should be rendering that using a view and if you want to render it directly on the page with that if logic Figured out a way in 8 to be able to not only insert the image into the content but also be able to reuse that image as in a teaser view or something along those lines where it's templated out I know in 7 I'm able to do this using the insert model where I can upload the image in a field and have all the wonderful things that field to do and then also be able to use that same image upload once at multiple times within the body of the blog post or whatever and I'm wondering if you found an 8 solution yet for that well so the approach we're doing here is trying to use files that way once again we did this all the time in the media module where when you browse for media you could upload a new media in there and create that necessary file entity in this case the approach saying which is exactly one of our clients does they have a media manager that media manager just goes to content slash files and adds a new file adds that file with its fields there and builds the library images that are necessary at that time and then we're embedding them through the WYSIWYG using the entity embed of that file itself I think I know what you're talking about you're talking about uploading the field to it and then having it render in the view but also being able to control where it inserts this solution can also do that if you were to place an image field for example you could call it thumbnail or I think finding the semantic term for it would actually be the most difficult part but once you have that image field you can render on the not to render and manage display but then you would set it to render in a view mode for example and then you'd use entity embed the way that we're demonstrating it here to insert it within the body so it's being uploaded to that field but then actually render using entity embed and then render it elsewhere in view modes in that way that makes sense can you speak to any processes that you had in migrating from Drupal 7 to Drupal 8 that's a big question yeah in this particular case the instance here is not sort of migrating our old demo into that state so we didn't actually do the steps of actually migrating a file from one to the other we have done well I'm going to give a better answer I don't want to cut your answer I'd tend to say that usually not just from going Drupal 7 to Drupal 8 but also 6 to 7 or even an old installation of 7 to a new installation of 7 typically when we're adding new features like this to make it dramatically easier going forward we tend to migrate the old content more as is so saying we're going to pull in the images as they were rendered in the body is a little bit more common but I know with media the whole point is if they're rendered with media then that embed code is not going to be working quite as well so I think that's going to continue to be a challenge for a while until that catches up frankly if I were personally working on a migration and I'll defer to you on this too I'm not sure if I'm going to be able to do that but I'm not sure if I'm going to be able to do that either trying to render a view to find everywhere that either a SQL query or a view to find everywhere that that old media embed code was used and then make it part of my governance process to go back and update that or task that out or trying to write a script at the point of migration to rewrite the old embed code as an actual actionable file but either way that's not all tables still there so if we're talking about files themselves they're going to exist in some format I think the way as in which they're if we're talking about a WYSIWYG the way they're embedded in their media files and yes that's going to be difficult to figure out what to do about this time so we'll take that but they should come across as files still sure you're talking about rendering content dynamic content based on taxonomy associations correct sure I'm going to restate that for the track and then turn it over to Clay to hear but he's asking specifically about if you are you have content you wanted to come in in a related way rather than defining it in a sidebar WYSIWYG template how do you have that view block and embed it in Drupal 8 we have an example whenever we add an article in the case of when we had this article said as a sidebar the content in the side over there is using the relationship of the category taxonomy term there as a dynamic to its place and what we just told in the page so this item of related content is finding these examples because they relate to music and it's just using that taxonomy term as a contextual filter in that view and saying if I've matched this term or any term show me these items and I also am saying but exclude the note I'm on so I don't see a duplicate of it so that placement here this related content is a view that's placed there now when we place it there we're using the panel to say it's there so in this case when we're switching this that's always going to be there if there's no results it won't show it's not as flexible as we're in the WYSIWYG content to be we have to sort of deal with in this case the structure of that I'm sure there are solutions that we could figure out but in this particular case we're placing it by saying the panel in a structure I know I want related content to be and I know I want it to be here and if for example so what we were showing earlier with that panels page is showing what blocks render on what variance so both in our twig template and then in our panel variant we're saying we don't want the second sidebar to display here on the featured article at all we don't want it to display here so if you were to say for example that you wanted a feature experience but you still want that related content you'd want to add another region maybe to the bottom of the page where you could say put my related content down here but still keep that from being distracting on the right sidebar until you've gotten to the bottom yeah so right here we're using a contextual filter of the taxonomy term ID we also have another filter here making sure that we never show a result for the page we're already on saying we only want to show five of them and also when you place these items within the page itself and we look at the page layout and here are our variants and we edit the variant of with sidebar you have an option when these are placed so here's the other sidebar here you have an option when you place these to override that also and say look in this case in this variant I want to set it to 10, 20, or 30 do you have a follow on to that well so and everyone asked that so we have it right now what we try to do and what we try to we want admins not to think all that much if they don't have to so I want to find a relationship that's contextual based on what I just created but in some cases they need to actually say okay I need these three articles to go in that case we would put a separate field on that content type that's like an entity reference field and we would allow them to pick those and possibly use no queue to actually order those or some other way system so the view you would place on the side is curated related content and we would then have to show anything that's tied to that node ID that's been chosen as curated content and to reduce the amount of them having to think like okay we don't want the two competing things we don't want the related taxonomy solution and also the curated solution you could have the condition on that view that's rendering the entity reference thing be only if the entity reference value has been filled out and have the condition on the default taxonomy view be show this only if that has not been filled out so in that way you have two different blocks but they would render the same way and the admin wouldn't have to think about it too much I agree and I think that the one thing that Kat and I always go back and forth about is that I think that's absolutely right we're trying to get the idea of like this is a conceptual approach to how to provide things for admins and there's different solutions for how they do it you know I think that in some cases in the past and we just built say it not too long ago where it just was best to have a content type called image where we let people upload the image and do whatever they want it comes completely controlled by display suite and we're embedding just that content site so while we're trying to limit that we're just trying to make sure that we're thoughtful and it's approachable to that admin as to what they need to do and it fits in their business case and business cases change all the time and that's what's great about Drupal is we can keep adapting and people keep writing new things that help us make that easier but we want to try to get across the approach of what you can do and how to give content admins as much flexibility as possible without overwhelming them with the paragraphs in particular what I've seen with the paragraphs module and admittedly I haven't used it in a while so it may be more mature is that if you're migrating content like if you're structuring your content in a word doc and then migrating it paragraphs is a huge pain but if you are truly building your article in Drupal then it's good so that goes back to that use case doing the right thing for your admins which is not universal but I hear paragraphs has been getting pretty awesome lately I think that so I actually fought for a long time about giving people this much control in a WYSIWYG like if I had my choice I would just have like no WYSIWYG control at all because it would come out exactly as the way I wanted it to but it's just evolved in the time of what people have been asked and I think obviously as these evolve giving them that you're right for portability certainly but it's what they seem to need and as long as we can give it to them a way that's not damaging it's helpful Any other questions? Thank you all very much enjoy the rest of your conference